{"_id":"@c0d3r22/homebridge-zway-plugin","name":"@c0d3r22/homebridge-zway-plugin","dist-tags":{"latest":"1.0.5"},"versions":{"1.0.5":{"name":"@c0d3r22/homebridge-zway-plugin","version":"1.0.5","description":"homebridge-plugin for ZWay Server and RaZBerry","main":"index.js","scripts":{"test":"node tests/js/runner.js"},"repository":{"type":"git","url":"git+https://github.com/c0d3r22/homebridge-zway-plugin.git"},"preferGlobal":true,"keywords":["homebridge-plugin","Z-Way","RaZBerry","Z-Wave","HomeKit"],"engines":{"node":">=0.12.0","homebridge":">=0.2.5"},"dependencies":{"debug":"^2.2.0","nyc":"^15.1.0","q":"1.4.x","request":"2.74.0","tough-cookie":"^2.2.0"},"devDependencies":{"homebridge":">=0.2.5","nyc":"*","qunit":"*"},"author":{"name":"c0d3r22","url":"https://github.com/c0d3r22"},"license":"ISC","bugs":{"url":"https://github.com/c0d3r22/homebridge-zway-plugin/issues"},"homepage":"https://github.com/c0d3r22/homebridge-zway-plugin#readme","directories":{"test":"tests"},"_id":"@c0d3r22/homebridge-zway-plugin@1.0.5","gitHead":"e4758cf21d0443288d7059398c20c0a7c78b8e3a","_nodeVersion":"20.11.0","_npmVersion":"10.2.4","dist":{"integrity":"sha512-sl3AjkGRyo9GxWPgEbKFdhyP2QvRbrSm8c/rLP5eMGp/TAMv3c99/5CIlcHjvADQUktkAvehgQhRrG3fUv3PxQ==","shasum":"d9b5d4af06e849c5e982adb975a224f32a125969","tarball":"https://registry.npmjs.org/@c0d3r22/homebridge-zway-plugin/-/homebridge-zway-plugin-1.0.5.tgz","fileCount":15,"unpackedSize":208220,"signatures":[{"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","sig":"MEQCIBCQLZcfv0HZn73VUiln9SHy+8wxTHTKaUJYXvbUl/KqAiAvM53CSOblZ5fHzLhOd6tBo/SD9RYhZxb6/XmcHJlwsg=="}]},"_npmUser":{"name":"c0d3r22","email":"06circuit.maxi@icloud.com"},"maintainers":[{"name":"c0d3r22","email":"06circuit.maxi@icloud.com"}],"_npmOperationalInternal":{"host":"s3://npm-registry-packages","tmp":"tmp/homebridge-zway-plugin_1.0.5_1707537859276_0.13147179411678178"},"_hasShrinkwrap":false}},"time":{"created":"2024-02-10T04:04:19.207Z","1.0.5":"2024-02-10T04:04:19.415Z","modified":"2024-02-10T04:04:19.705Z"},"maintainers":[{"name":"c0d3r22","email":"06circuit.maxi@icloud.com"}],"description":"homebridge-plugin for ZWay Server and RaZBerry","homepage":"https://github.com/c0d3r22/homebridge-zway-plugin#readme","keywords":["homebridge-plugin","Z-Way","RaZBerry","Z-Wave","HomeKit"],"repository":{"type":"git","url":"git+https://github.com/c0d3r22/homebridge-zway-plugin.git"},"author":{"name":"c0d3r22","url":"https://github.com/c0d3r22"},"bugs":{"url":"https://github.com/c0d3r22/homebridge-zway-plugin/issues"},"license":"ISC","readme":"# homebridge-zway-plugin\n\n\n\n *Since all development appears to be abandoned on any Z-Way repos I intend to try and keep this as up-to-date and working as possible.*\n\n---\n\n...is a Homebridge module for [Z-Way Server](http://razberry.z-wave.me/index.php?id=24).\n\nThis platform lets you bridge a Z-Way Server instance (for example, running on [RaZBerry](http://razberry.z-wave.me) hardware or with a [UZB1](http://www.z-wave.me/index.php?id=28)) to HomeKit using Homebridge.\n\nHomebridge requires Z-Way Server version 2.0.1 or greater. It is currently tested against 2.2 though it is expected to still work with 2.0.1.\n\n\n\n- [homebridge-zway](#homebridge-zway)\n\t- [Quick Start](#quick-start)\n\t- [Supported Devices](#supported-devices)\n\t- [Problems/Troubleshooting](#problemstroubleshooting)\n\t\t- [Getting `/accessories`](#getting-accessories)\n\t\t- [Getting `/ZAutomation/api/v1/devices`](#getting-zautomationapiv1devices)\n- [Configuration](#configuration)\n\t- [Required](#required)\n\t- [Optional](#optional)\n\t- [Tags](#tags)\n\t\t- [Homebridge.Skip](#homebridgeskip)\n\t\t- [Homebridge.Include](#homebridgeinclude)\n\t\t- [Homebridge.IsPrimary](#homebridgeisprimary)\n\t\t- [Homebridge.Accessory.Id:*value*](#homebridgeaccessoryidvalue)\n\t\t- [Homebridge.Characteristic.Description:*value*](#homebridgecharacteristicdescriptionvalue)\n\t\t- [Homebridge.Service.Type:*value*](#homebridgeservicetypevalue)\n\t\t\t- [Make a Switch show as a `Lightbulb`](#make-a-switch-show-as-a-lightbulb)\n\t\t\t- [Change a Dimmer to a Switch](#change-a-dimmer-to-a-switch)\n\t\t\t- [Specify a switch to be an `Outlet`](#specify-a-switch-to-be-an-outlet)\n\t\t\t- [`sensorBinary` as Contact Sensor, Motion sensor, or Leak sensor](#sensorbinary-as-contact-sensor-motion-sensor-or-leak-sensor)\n\t\t\t- [Door/Window Sensor Service](#doorwindow-sensor-service)\n\t\t\t- [Dimmer or other `switchMultilevel` as `WindowCovering`](#dimmer-or-other-switchmultilevel-as-windowcovering)\n\t\t\t- [More](#more)\n\t\t- [Homebridge.Characteristic.Type:*value*](#homebridgecharacteristictypevalue)\n\t\t- [Homebridge.Interlock](#homebridgeinterlock)\n\t\t- [Homebridge.ContactSensorState.Invert](#homebridgecontactsensorstateinvert)\n\t\t- [Homebridge.OutletInUse.Level:*value*](#homebridgeoutletinuselevelvalue)\n- [Technical Detail](#technical-detail)\n\t- [Bridging and Mapping Logic](#bridging-and-mapping-logic)\n\t\t- [Recombination](#recombination)\n\t\t- [Primary Devices](#primary-devices)\n\t\t- [Service Type](#service-type)\n\t\t- [Required and Optional Characteristics](#required-and-optional-characteristics)\n\t\t- [Additional Services](#additional-services)\n\n\n## Quick Start\n\n1. `sudo npm install -g homebridge`, See the [Homebridge](https://github.com/nfarina/homebridge) project site for more information, and to configure Homebridge\n2. `sudo npm install -g homebridge-zway-plugin`\n3. Edit `~/.homebridge/config.json` and add the following:\n\n```\n\"platforms\": [\n {\n \"platform\": \"ZWayServer\",\n \"url\": \"http://your.ip.goes.here:8083/\",\n \"login\": \"[admin]\",\n \"password\": \"[password]\"\n }\n]\n```\n\nThen see the [Configuration](#configuration) and [Tags](#tags) sections below to to customize the bridge for your environment or devices.\n\n## Supported Devices\n\nSupport is currently designed around Z-Wave devices. The bridge uses the `VDev` interface, so other device types (such as EnOcean) should also work, but this has not been tested.\n\nGenerally speaking, the following types of devices will work:\n\n* On/off switches\n* Dimmers\n* RGB bulbs (e.g. Aeon Labs')\n* Thermostats (heating only for now!)\n* Temperature sensors\n* Door/window sensors\n* Contact sensors\n* Light sensors (needs work)\n* Motion sensors\n* Door Locks (e.g. Danalock)\n* Relative Humidity sensors (e.g. Aeon Labs Multisensor 6...needs testing!)\n* Window Coverings\n* Water leak sensors\n* Smoke detectors\n\nAdditional devices in progress:\n\n* Remotes/buttons (Initial implementation available in trunk!)\n\n## Problems/Troubleshooting\n\nIf you have a problem with the Z-Way Server bridge or with a particular device, please create an Issue and attach the contents of `/accessories` from your Homebridge instance, and of `/ZAutomation/api/v1/devices` from your Z-Way Server instance (or at least those parts that pertain to your problem).\n\n### Getting `/accessories`\n\nCurrent versions of homebridge will--by default--only allow communication with encrypted paired devices. To manually retrieve the `accessories` JSON data, you will need to run Homebridge in insecure mode by adding the `-I` switch (e.g. `homebridge -I`). Then, point your browser at your Homebridge IP and port and hit the accessories URL endpoint, e.g. `http://127.0.0.1:51826/accessories`.\n\n### Getting `/ZAutomation/api/v1/devices`\n\nTo retrieve your `devices` JSON from Z-Way, first connect to the Home Automation interface (usually running on port 8083) with your browser and log in with your username and password. After successfully logging in, go to the following address in the same browser window: `http://your.ip.goes.here:8083/ZAutomation/api/v1/devices`, substituting your Z-Way server's IP address and port as appropriate.\n\n# Configuration\n\n## Required\n\nThe minimum configuration includes the following 3 parameters\n\n {\n \"platform\": \"ZWayServer\",\n \"url\": \"http://192.168.1.100:8083/\",\n \"login\": \"[admin]\",\n \"password\": \"[password]\"\n }\n\n| Key | Description |\n| --- | --- |\n| `url` | The base URL of your Z-Way Server installation. For instance, the URL above would be the right pattern if your Z-Way web UI is accessed at `http://192.168.1.100:8083/smarthome/#/elements`. Since the protocol, address, port, and path are all used, you're covered if you change any of them (i.e. if you're running Z-Way Server behind a reverse-proxy). |\n| `login` | A username with permissions in Z-Way. Using `admin` is actually not recommended, but you can to start with it if you want to make sure everything's working. It's best to create another user so you don't have your admin password sitting in the configuration file. |\n| `password` | The password for the user specified in `login`. |\n\n## Optional\n\nThe following additional configuration options are supported\n\n| Key | Default | Description |\n| --- | :---: | --- |\n| `poll_interval` | `2` | The time in seconds between polls to Z-Way Server for updates. 2 seconds is what the Z-Way web UI uses, so this should probably be sufficient for most cases. |\n| `battery_low_level` | `15` | For devices that report a battery percentage, this will be used to set the `BatteryLow` Characteristic to `true`. |\n| `dimmer_off_threshold` | `5` | In some cases (especially older versions of Z-Way) dimmers would never ramp all the way down to zero when switching off. This value determines what threshold to use to consider the dimmer \"off\". At or below this level, the `Switch` will report as \"off\", but the `Brightness` value will remain at the actual reported value. This has become less necessary with newer versions of Z-Way, and in the future the default will be changed to `0`. Set the value to `0` to always only report dimmers as \"off\" when the `Brightness` reaches `0`. |\n| `outlet_in_use_level` | `2` | For `Outlet` devices (currently only available when designated with the tag `Homebridge.Service.Type:Outlet`), sets the level that a Watt meter device must rise above to trigger the `OutletInUse` value to \"true\". |\n| `blink_time` | `0.5` | For some devices and some use cases, a change may occur and be reversed in a device so quickly that the changed value does not get captured in polling. Mainly this happens with button devices, but may also occur with a contact sensor that opens and closes quickly, such as if you are monitoring a mailbox door. Such an event does change the `updateTime` of the Z-Way device however, so Homebridge-ZWay will capture that change and simulate the missed event by flipping the value of the HomeKit device and then flipping it back again. This `blink_time` is the amount of time in seconds the device will stay in the inverted state before flipping back. The default of 0.5 seconds seems to work well, but you can adjust it with this config setting. It is recommended to keep this value below half of the `poll_interval`.\n| `split_services` | `true` (after 0.4.0) | **DEPRECATED** This setting affects how Characteristics are organized within an accessory. If set to \"true\", for instance the `BatteryLevel` and `StatusLowBattery` Characteristics are put into a `BatteryService`, where `false` causes them to be simply added as additional Characteristics on the main Service. This was done mainly to support the Eve app better, which made separate Services appear the same as whole different Accessories. The Eve app now groups services in the same accessory. This has been changed to default to `true` in 0.4.0 and will later be removed entirely. |\n| `opt_in` | `false` | If this is set to `true`, only devices tagged with `Homebridge.Include` will be bridged. This is mainly useful for development or troubleshooting purposes, or if you really only want to include a few accessories from your Z-Way server. |\n\n## Tags\n\nYou can change the default behavior of Homebridge by adding certain tags to your devices in the Z-Way web UI. Sometimes this may be necessary to get certain devices to be bridged properly, as there are a large number of Z-Way devices and sometimes the \"guessing\" that Homebridge does to get one device right may be the wrong answer for a different device.\n\nTags are case sensitive. Some tags allow you to specify a value, and these have the value after a `:` character (everything after the `:` is the value). Tags without a value are boolean, and are tested for presence or absence.\n\n### Homebridge.Skip\n\nAny devices with this tag will not be bridged, and will be excluded from the logic used by Homebridge to try and translate Z-Way devices to HomeKit devices.\n\n### Homebridge.Include\n\nThis tag has two different but related purposes. Essentially, it lets you include a device on the bridge that would have otherwise been excluded.\n\n1. If in the Z-Way GUI you set \"Permanently hide this element\", then it will not be bridged by Homebridge by default. If you want it to be hidden in Z-Way yet visible in Homebridge, you can use the `Homebridge.Include` tag to override this behavior.\n\n2. Used in conjunction with the `opt_in` configuration option above, this marks a device to be included in opt-in mode, while all devices without the tag are skipped.\n\nNote that if both `Homebridge.Skip` and `Homebridge.Include` are specified on the same device that `Homebridge.Skip` wins--_unless_ you have set the `opt_in` configuration option. This is useful for troubleshooting or development: you can have a \"production\" instance of Homebridge running that skips a troublesome device (with `opt_in` false) and a second instance for testing running with `opt_in` true that will pick up the device regardless of the `Skip` tag.\n\n### Homebridge.IsPrimary\n\nThis overrides or supplements Homebridge's logic for figuring out what kind of Accessory or Services to build from your Z-Way devices, and sometimes how to use the multiple devices within an Accessory. This is particularly useful if Homebridge gets it wrong by default, or the components of your device are unusual or ambiguous.\n\nFor instance, if you have a Devolo Door/Window sensor but are primarily using it for a temperature sensor, you could tag the temperature sensor device with `Homebridge.IsPrimary`, which would change the way the device is reported to HomeKit.\n\nFor another example, the Aeon Labs RGB Bulb has three dimmers: one for the color LEDs, one for \"Cold\" white and one for \"Soft\" white. It's not obvious to Homebridge which of the dimmers controls the color LEDs, but it can figure out that it's an RGB bulb. So, you should put `Homebridge.IsPrimary` on the dimmer for the color LEDs, and the other dimmer devices will be treated as extras.\n\n### Homebridge.Accessory.Id:*value*\n\nManually specifies the Accessory identifier to use for this device. This has the effect of allowing you to split or merge devices that would be grouped differently by default by Homebridge's translation logic.\n\nFor instance, many Z-Wave devices include a temperature sensor that has nothing to do with their primary function (such as an outlet switch), so you could give that temperature sensor a different Accessory Id, and it would appear to HomeKit as a separate Accessory. Or, if you have a Danfoss Living Connect thermostat (which does not report the room temperature via Z-Wave) and a temperature monitoring device in the same room, you could give them the same ID and Homebridge would bridge them as a single device on the HomeKit side.\n\n### Homebridge.Characteristic.Description:*value*\n\nThis tag lets you override the description for the Characteristic(s) created from this device. This may affect the way the Characteristic is displayed in your HomeKit app.\n\n### Homebridge.Service.Type:*value*\n\nThis tag allows you to explicitly specify what kind of HomeKit Service to create for an accessory. This is only supported for a specific set of cases, and even then may break your bridge! It will only be effective on the primary device of a Service, so either on the primary device of an Accessory or on a device like the Aeon Labs RGB bulb which has multiple dimmers which have to be split off into their own Services.\n\n#### Make a Switch show as a `Lightbulb`\n\nTagging a device with `Homebridge.Service.Type:Lightbulb` allows you to explicitly report a `switchBinary` as a HomeKit `Lightbulb` (normally only `switchMultilevel`s will be automatically bridged as lights). This means that if you ask Siri to \"turn off the lights\" in a room, the marked device should be included.\n\n#### Change a Dimmer to a Switch\n\nSomewhat the opposite of above, you can specify `Homebridge.Service.Type:Switch` on a dimmer to treat that device as a standard switch instead of a dimmer. Besides doing this just out of preference, this is handy on the aforementioned Aeon Labs RGB bulb's extra \"white\" dimmers, because the primary (color) dimmer actually controls the dimming of the two whites.\n\n#### Specify a switch to be an `Outlet`\n\nTagging a device with `Homebridge.Service.Type:Outlet` makes a `switchBinary` into an `Outlet` service instead of a switch. The main functional reason you would want to do this is when a device also has a Watt meter, it will add an `OutletInUse` Characteristic that will become \"true\" once the wattage consumed rises above a specified level (the default is `2` Watts, see also the tag `Homebridge.OutletInUse.Level:*value*` below). This, for example, would let you put your bedside phone charger on a Watt meter, and when you plug your phone in for the night, a HomeKit trigger could set your \"Good Night\" scene.\n\n#### Button as `StatefulProgrammableSwitch`\n\nBy default, `toggleButton` devices are bridged as `StatelessProgrammableSwitch` services, which is best for triggering scenes. However, if you want to control a single device with a button, it may be easier to specify the `Homebridge.Service.Type:StatefulProgrammableSwitch` tag for your device, which gives the button a state value that you can more easily build automations against.\n\nNote that the switch's state is always set to `0` at Homebridge startup, since it doesn't know what to pull its initial state from. The state value only persists as long as Homebridge is running.\n\n#### `sensorBinary` as Contact Sensor, Motion sensor, or Leak sensor\n\nMany sensor devices will only be reported by Z-Way as a `sensorBinary` or `sensorBinary.general_purpose`, which is too vague to determine its real purpose. In this case you must specify either `Homebridge.Service.Type:MotionSensor`, `Homebridge.Service.Type:ContactSensor` or `Homebridge.Service.Type:LeakSensor` so that the bridge will know how to bridge the device. See also `Homebridge.Characteristic.Type` below—though in many cases, once you specify the Service type the bridge can figure out how to properly report the Characteristic.\n\n#### Door/Window Sensor Service\n\nThere is not really a direct analogue to a `Door/Window` sensor in HomeKit--the possibilities are `GarageDoor`, `Door`, `Window`, and `ContactSensor`. The first three are really designed for door or window *controls* instead of sensors, and then the last one is a very generic type of sensor. Homebridge now lets you choose which of these four to use for your sensor by specifying one of the following values in this tag:\n\n* `GarageDoor`: This is the old default, and may make the most sense if you have an apartment with a single door. It reports the door as \"Open\" or \"Closed\" in most apps, and you get iOS notifications when the door opens or closes. However, if you have an actual garage door opener that is controllable by Siri, when you say \"Open the Garage Door,\" Siri will try to also open your door sensor...which will fail, and she will complain, which can be annoying. It also adds a required \"ObstructionDetected\" sensor, which does nothing.\n* `Door`: This is the new default and avoids the \"multiple\" Garage Door problem above. However it reports position in percent (always 0% for closed or 100% for open), and still generates iOS notifications when the door opens and closes. It will also have a \"PositionState\" characteristic, which is always \"Stopped\".\n* `Window`: This is identical to `Door`, but may be categorized differently by Siri or in apps.\n* `ContactSensor`: This treats the `Door/Window` sensor as a simple contact sensor (on or off). This has two main advantages:\n a. It's the simplest option, and doesn't have any superfluous, non-working characteristics.\n b. You don't get any iOS notifications for state changes, so pick this if you find those annoying.\n But, you won't be able to ask Siri about the state of the \"Door\", and app support for this characteristic has been historically lacking (Eve works great now). Also note that you can invert the value with `Homebridge.ContactSensorState.Invert`, which may result in a more intuitive value being shown.\n\n#### Dimmer or other `switchMultilevel` as `WindowCovering`\n\nIf you have a shutter/drapery control that uses a percentage value for open/closed, but is not automatically recognized as such (for instance it is instead shown as a light dimmer), you can specify `Homebridge.Service.Type:WindowCovering` to force it to be recognized correctly. This should not be necessary in most cases.\n\n#### More\n\nThere will be additional devices and use cases where this will be used. If you think you have a good use case for this that is not supported by the current code, please submit an issue with the guidelines above.\n\n### Homebridge.Characteristic.Type:*value*\n\nLike [`Homebridge.Service.Type`](#homebridgeservicetypevalue), this allows you to explicitly define the type of Characteristic that will be created for a given device. This will override the bridge's own logic for selecting which Characteristic(s) to build from a device, so use it with caution!\n\nThis tag is particularly useful for scenarios where the physical device is reported ambiguously by Z-Way. For instance, the Vision ZP 3012 motion sensor is presented by Z-Way merely as two `sensorBinary` devices (plus a temperature sensor), one of which is the actual motion sensor and the other is a tampering detector. The `sensorBinary` designation (with no accompanying `probeTitle`) is too ambiguous for the bridge to work with, so it will be ignored. To make this device work, you can tag the motion sensor device in Z-Way with `Homebridge.Characteristic.Type:MotionDetected` and (optionally) the tamper detector with `Homebridge.Characteristic.Type:StatusTampered`. (Note that for this device you will also need to tag the motion sensor with `Homebridge.Service.Type:MotionSensor` and `Homebridge.IsPrimary`, otherwise the more recognizable temperature sensor will take precedence.)\n\n### Homebridge.Interlock\n\nAdding the tag `Homebridge.Interlock` to the primary device will add an additional `Switch` service named \"Interlock\", defaulted to \"on\". When this switch is engaged, you will not be able to set the characteristics of any other devices in the accessory! You will be required to turn off the Interlock switch before changing/setting other values. This is a kind of a \"safety\" switch, so that you (or Siri) does not turn something on or off that you did not intend. A use case might be if you had your cable modem or router plugged into a power outlet switch so that you could power cycle it remotely: you would not want to turn this off accidentally, so add an Interlock switch. **Do NOT rely on this capability for health or life safety purposes--it is a convenience and is not designed or intended to be a robust safety feature.**\n\n### Homebridge.ContactSensorState.Invert\n\nIf you have a `ContactSensor`, this will invert the state reported to HomeKit. This is useful if you are using the `ContactSensor` Service type for a `Door/Window` sensor, and you want it to show \"Yes\" when open and \"No\" when closed, which may be more intuitive. The default for a `ContactSensor` is to show \"Yes\" when there is contact (in the case of a door, when it's closed) and \"No\" when there is no contact (which for a door is when it's open).\n\n### Homebridge.OutletInUse.Level:*value*\n\nThis can be used in conjunction with the `Homebridge.Service.Type:Outlet` tag and lets you change the threshold value that changes the `OutletInUse` value to true for a particular device. The main use case is if you have a USB charger or transformer that always consumes a given amount of power, but you want events to trigger when the consumption rises above that level (e.g. when a device is plugged into the USB charger and draws more power). You could also adjust this to trigger only when the higher settings on a 3-way lamp are used, when a fan is turned to high speed, or other creative purposes.\n\n# Technical Detail\n\n## Bridging and Mapping Logic\n\nAs with any bridge, the devices on the The Z-Way Server side do not necessarily map perfectly to the HomeKit device model. So, the Z-Way bridge does a lot of guesswork and generalization to make the devices make sense on the HomeKit side.\n\n### Recombination\n\nA Z-Wave device usually supports multiple Command Classes for different kinds of controls and sensors, and Z-Way splits all of those devices up into separate \"Virtual Devices\". This is the most flexible way to deal with composite devices, but having all those individual components in a HomeKit app as separate Accessories would be very clumsy, and sometimes impossible (for instance, a HomeKit Thermostat requires a temperature sensor device in the same Accessory and Service, so it can't be bridged by itself). So, Homebridge attempts to recombine those Virtual Devices back into a single composite device.\n\n### Primary Devices\n\nAfter combining the sub-devices back into a single composite device, it then tries to make sense of what kind of Accessory that composite device should be in HomeKit. It does this by trying to determine which sub-device should be treated as the \"primary\" device.\n\nThis can be tricky, since devices may contain any combination of sensors and controls. The bridge tries to pick more unusual or specific sub-devices out first. For example, many many devices include a temperature sensor, but a Door/Window sensor is far less common, and if present probably indicates the device's intended main purpose.\n\n### Service Type\n\nOnce Homebridge decides on the primary device, it chooses a Service type that corresponds to that device and attempts to configure that Service. For example, if it finds a thermostat device in Z-Way, it will create a Thermostat Service in HomeKit and look for a temperature sensor device in the same composite device.\n\n### Required and Optional Characteristics\n\nMany Services in HomeKit have a set of Characteristics that must appear in the Service to be in compliance--for example the aforementioned Thermostat, which requires a thermostat device and a temperature sensor. Homebridge will attempt to fill all the requirements from the composite device. If it fails, it will not bridge that Service (and likely nothing else in the device)! You may see messages to this effect at the console on startup.\n\nAfter fulfilling the required Characteristics, the bridge will look at the remaining sub-devices and--if it understands them and knows what Characteristic(s) it can build from them, it will tack those Characteristics onto the primary service. HomeKit seems fairly flexible about this sort of tack-on extras ability, so if you have a device that is an outlet switch with a temperature sensor in it, you'll get a Switch with a TemperatureSensor in HomeKit as well.\n\n### Additional Services\n\nBecause HomeKit does not support more than one of the same Characteristic in the same Service, if the bridge encounters a composite device with this composition (say, multiple dimmers) it will in some cases build additional services to contain the additional Characteristics.\n\n*NOTE: At the moment, the only scenario where this happens is RGBW bulbs.*\n\nIf this happens, you may see ambiguously titled controls in your HomeKit app (multiple Brightness controls, for instance).\n","readmeFilename":"README.md"}