Technical Foundation
While not yet exposing any device functionality to HomeKit, this release includes the technical foundation for Homebridge deCONZ.
Please see the README and the Wiki.
There are a lot of changes with respect to Homebridge Hue, see also Future Development of Homebridge Hue:
- Discovery of gateways, using local UPnP or through the Phoscon portal. Check that discovered gateways are in fact reachable before exposing them. Set
hostsin config.json to whitelist gateways, skipping discovery; - Support for multiple gateways, each exposed as a Gateway accessory, with a (custom) Gateway Settings service for the gateway settings, and a Stateless Programmable Switch service, to prevent the accessory from showing as Not Supporteed in Home. The button fires periodically, to enable recurring automations in HomeKit. See the Wiki;
- Each (virtual or Zigbee) device exposed by the gateway is exposed as a separate accessory, for now with only a Stateless Programmable Switch service and custom Device Settings service for the device settings. The switch fires a Short Press when a web socket notification is received for the corresponding device, and a Long Press when the device has been polled (this makes for a cool dashboard in the Home app ;-). See the Wiki
- Dynamic platform accessories: configuration is now persisted across Homebridge restarts. All accessories are restored on restart, even when the gateway is not (yet) reachable. Settings are now persisted between Homebridge restarts. This includes the API key! No need anymore to edit config.json;
- Dynamic accessory management: accessories are added and removed automatically at runtime, as the corresponding devices are added or removed from the gateway. No need anymore to restart Homebridge;
- Dynamic API key management: unset Expose on the Gateway Settings service and the API key is removed from the gateway, removing all accessories for the devices exposed by the gateway. This can be reversed by setting Expose. Effectively, this should reset the configuration. No need anymore to edit
cachedAccessories(through the UI or manually). - Dynamic blacklist management: devices can be blacklisted at runtime, causing the corresponding accessory to be removed from HomeKit. The blacklist is managed (and persisted) by the Gateway accessory, which gains an addition service for each blacklisted device, to un-blacklist it, and re-expose the corresponding accessory. No need anymore for elaborate config.json settings, nor for resourcelinks.
As Eve history will be persisted per device at the device accessory, temporarily blacklisting the device resets the Eve history - no more need to handle history files.
Note that HomeKit doesn't like configuration changes, extensive playing with these settings will cause synchronisation issues between HomeKit on your various devices. - Dynamic log level: change the log level per accessory at runtime, through the Gateway Settings or Device Settings service.
Testers Wanted
I would love to get feedback on how stable this release runs. I did extensive testing, but I'm pretty sure I haven't covered all scenarios.
- Please try adding and removing devices (CLIP sensors) to/from the gateway.
- Please try renaming devices.
- Please try un-exposing and re-exposing the gateway.
- Please try re-starting Homebridge with (un-)exposed gateways and/or devices.
- Please try restarting the gateway.
- Please try changing the gateway name, IP address, port, or websocket port.
Feedback Wanted
This release pretty much applies to deCONZ the vision I have for my Homebridge plugins: self-healing, dynamic settings, and (near) zero configuration. This is, however, still a first implementation; I would love to get feedback on the usability of this release, in particular:
- I'm not sure if managing the configuration from HomeKit is the best approach. These settings are restricted to the owner of the HomeKit home (please verify), and don't show on Home, so they shouldn't sit in your way. An alternative might be to use dynamic forms in the Homebridge UI, but I haven't really looked into these. Yet...
- For larger installations, I'd recommend a separate Homebridge (child bridge) instance per gateway, preferably running on the same host (no network in between). For really large installations (hitting the limit of 149 bridged accessories), I'd use two child bridges on the same gateway, each exposing half the devices (now possible as blacklisting is per device instead of per resource). Alternatively, Homebridge deCONZ could spin up one or more external bridge accessories per gateway. I do have some experience with external accessories in Homebridge ZP, but not with bridges. Yet...