For every device paired with Homey, a Device class will be instantiated and a device tile will be shown in the interface. Every Device class is associated with a Driver class. All Driver classes of your app will be instantiated when your app is started, even if there are no devices of that type paired with Homey. This allows the driver to be responsible for pairing new devices and defining Flow cards.

You can use the Homey CLI to interactively create a driver, this will create a basic driver manifest and all the required files for your driver:

homey app driver create

This command will ask a number of questions about the driver you want to create, such as what ID the driver should have. Then it will create a new folder in your drivers/ directory which will look like this:

com.athom.example/driver/<driver_id>/
├─ assets/
│ └─ ...
├─ device.js
├─ driver.js
└─ driver.compose.json

The /drivers/<driver_id>/driver.js file contains the Driver class. This class is responsible for pairing devices and describes the functionality for the devices belonging to the driver.

/drivers/<driver_id>/driver.js
const Homey = require("homey");
​
class MyDriver extends Homey.Driver {
  // This method is called when a user is adding a device
  // and the 'list_devices' view is called
  async onPairListDevices() {
    return [
      {
        name: "Foo Device",
        data: {
          id: "abcd1234",
        },
      },
    ];
  }
}
​
module.exports = MyDriver;

The /drivers/<driver_id>/device.js file contains the Device class. This class implements the device's functionality such as its capabilities and Flows.

/drivers/<driver_id>/device.js
const Homey = require("homey");
​
class MyDevice extends Homey.Device {
  // this method is called when the Device is inited
  async onInit() {
    this.log("Device init");
    this.log("Name:", this.getName());
    this.log("Class:", this.getClass());
​
    // register a capability listener
    this.registerCapabilityListener("onoff", this.onCapabilityOnoff.bind(this));
  }
​
  // this method is called when the Device has requested a state change (turned on or off)
  async onCapabilityOnoff(value, opts) {
    // ... set value to real device, e.g.
    // await setMyDeviceState({ on: value });
    // or, throw an error
    // throw new Error('Switching the device failed!');
  }
}
​
module.exports = MyDevice;

Manifest

The /drivers/<driver_id>driver.compose.json file is the driver manifest, when building your app all the driver.compose.json files will be bundled into your App Manifest. A basic driver manifest looks like this:

/drivers/<driver_id>/driver.compose.json
{
  "name": { "en": "My Driver" },
  "class": "socket",
  "capabilities": ["onoff", "dim"],
  "images": {
    "small": "/drivers/my_driver/assets/images/small.png",
    "large": "/drivers/my_driver/assets/images/large.png",
    "xlarge": "/drivers/my_driver/assets/images/xlarge.png"
  },
  "pair": [
    {
      "id": "list_devices",
      "template": "list_devices",
      "navigation": { "next": "add_devices" }
    },
    {
      "id": "add_devices",
      "template": "add_devices"
    }
  ]
}

Device Class

"class": "light"

The device class tells Homey what type of device your driver adds support for. Examples of device classes are socket, light, lock etc. When a specific device is not supported by Homey, you can use the class other.

Find your device's class in the Device Class Reference.

Capabilities

"capabilities": ["onoff", "dim"]

The capabilities of a device describe the states and actions a device supports. For example, a light may have the capability onoff which allows users to toggle the light on or off. It can also support the dim capability which would allow the user to change the lights brightness.

Capabilities all have a data type, for example the onoff capability has the type boolean and can thus be either true or false. The capability dim is of type number and can be any number between 0 - 1, as defined in the capability's definition.

Homey ships with many system capabilities. For other cases, app-specific capabilities can be defined in the App Manifest.

Homey has built-in Flow cards for every system capability.

Read more about Capabilities.

Energy

"energy": {...}

A device can use or generate power. To keep track of the data related to power usage and generation a device can have an energy object. This object contains power usage approximation data and flags to indicate a device generates power or should be omitted from automatic shutdown.

Read more about Energy.

Settings

"settings": [ ... ]

A device can have user-configurable settings, such as the orientation of a curtain or a poll-interval. Settings are shown to the user in the front-end, or can be changed programmatically (see Device#setSettings).

Read more about Settings.

Pairing

"pair": [ ... ]

A device can be added to Homey through pairing. Pairing is started when the user selects the device they want to add from the Homey app. The pair property of the device manifest describes the steps necessary to add the device to Homey.

For most devices a few simple pair steps are enough. For more advanced devices, where more user-steps are required, custom pairing views can be provided.

Read more about Pairing.

Deprecated

"deprecated": true

Sometimes a Driver that has been available in the past should be removed. To not break compatibility for users that were using it, add "deprecated": true to your driver in your App Manifest. It will still work, but won't show up anymore in the 'Add Device' list.

Device identifier

During pairing, you must provide a data property. This property contains a unique identifier for the device. This object cannot be changed after pairing. This data property is an object containing any properties of the types String, Number or Object. Homey uses this object to identify your device, together with the driver's ID.

Any properties that could change over time should be kept in-memory or saved in the device's store.

Store

The device's store is a persistent storage to save device properties. This store can be set during pairing and programmatically read and updated after the device is paired with Homey.

See Device#getStore() and Device#setStoreValue().

Availability

A device can be marked as unavailable using Device#setUnavailable() to prevent the user from interacting with the device. This can for example be useful when a device is offline.

When a device is marked as unavailable, all capabilities and Flow actions will be prevented. When a device is available again, use Device#setAvailable() to mark the device as available.

Assets

Your drivers /assets/ folder contains the icon and images for that driver. These images should be clean marketing pictures of the device that this driver implements, these are shown in the Homey App Store.

Read more about driver images and icons in the Homey App Store guidelines.