async/awaiteverywhere you want/need to. We hope supporting asynchronous calls everywhere will make it easier to develop and maintain Homey apps.
sdkproperty in your App Manifest from
3. Since SDK v3 is introduced in Homey 5.0.0 the Homey
compatibilityfield in your App Manifest should be changed to
homey-log) are not compatible with SDK v3. Make sure to upgrade these libraries to versions that do support SDK v3. When using
homey-meshdriverfor Zigbee or Z-Wave, please look at the specific sections for Z-Wave and Zigbee.
const Homey = require('homey'). This is a very convenient way to give access to the managers anywhere it is needed however this prevents us from optimizing apps in the future as it pollutes the "global namespace". Therefore, the homey module now only exports the classes you might need such as
Homey.Device. The module also contains your environment variables through
Homey.env, and app manifest through
Homey.manifest. All managers (the API you use to interact with Homey) have moved to
this.homey, a property that is set on your App, Driver and Device instances. You can find the name of your manager in the
api.js. Additionally since you can no longer gain access to the API through require-ing homey it is now passed as an argument to your API handler method. Read more about the Homey App Web API in the Web API guide. Here is an example of the new structure for Homey App Web API's:
Driver#onPair()has been changed. Previously this argument was an
.onmethod that would receive a callback as its last argument. In order to offer better support for promises this was changed to a
PairSessionthat has a
.setHandlermethod where it is possible to return a Promise.
onPairmethod like this:
onPairListDevicesmethod like this:
App#onInit()method would be executed after all managers where ready. Unfortunately this also meant that your Driver and Device
onInitmethods where executed before your
App#onInit(). This ordering was somewhat confusing so we changed the order in which we call the
onInitmethods in SDK v3.
app.jsand two drivers (
driver-twoboth have a single device) the order of
onInitcalls is now:
App#onInit()you cannot access Drivers (
this.homey.drivers.getDriver()will throw an error). Instead of accessing Drivers from your App you can use
App#onInit()to set up any data or classes that you might need in your application, then when your Driver or Device's
onInitmethods are called you are able to access this data directly through
alarm_motionactivated a zone when an alarm is triggered. As of Homey v5.0.0 it is possible to disable this behaviour by using the capability option
zoneActivity. This option accepts a boolean and defaults to
true. This makes it possible to disable zone activity for these capabilities.
zwave.associationGroupsdriver property has changed in Homey v5.0.0 to be more predictable:
associationGroups: will now remove the default association group 1 (Z-Wave Plus lifeline)
associationGroupswill now set the default association group 1 (Z-Wave Plus lifeline)
process.env.TZ) will always be set to
UTC. In SDK v2, the timezone of an app would match the timezone the user set in their settings. This behaviour was confusing and could cause correct apps to have bugs when a user changes their timezone. To have more consistent and predictable behaviour all dates in SDK v3 apps will now default to
this.homey.clearIntervalinstead. These are the same as the native variants, but will take care of clearing the timeouts/intervals themselves when the app gets removed. Alternatively you could use
this.homey.on('unload', () => clearInterval(myInterval)).