Open ebaauw opened 2 years ago
UPDATE AUG 2023 I've bumped Homebridge deCONZ to v1, as I think it's production ready. I concluded my migration to Homebridge deCONZ in May, and have been running Homebridge deCONZ exclusively for three months now, without any issues.
Consequently, Homebridge Hue support for deCONZ gateways has been deprecated, meaning you should start planning a migration to Homebridge deCONZ. For now, Homebridge Hue continues to expose devices connected to a deCONZ gateway, but I won't be adding support for new devices nor implement any feature requests not supported by the Hue bridge.
Note that Homebridge Hue2 is still just a placeholder, so continue to use Homebridge Hue to expose devices connected to a Hue bridge.
@ebaauw I noticed Homebridge-Hue has a migrate feature but I can't find any tutorials or wikis on how to do it. Is there any way to easily jump to Homebridge-Deconz without having to remove all the lights/switches from Homekit, I have so many that it will be a monumental task to set up all the scenes and automations again.
Please don't hijack this issue.
v0.13.67 adds the noDeconz
option, not to discover any deCONZ gateways.
Familiarise yourself with Homebridge deCONZ
- Install Homebridge deCONZ in a child bridge. See Homebridge deCONZ README for details, incl. link how to setup a child bridge;
- Pair Homebridge deCONZ to your deCONZ gateway; by default, it will expose all zigbee devices connected to the deCONZ gateway.
- Temporarily create a new HomeKit Home, and pair the Homebridge deCONZ child bridge to that Home;
- Check that your devices are exposed correctly. Log an issue for devices that aren't exposed correctly or for which you need additional feature requests.
- Play around with the dynamic configuration through the
ui
command-line tool, un-exposing and exposing devices, changing log level, how to expose devices, etc.Move Homebridge deCONZ to production
- Un-expose all devices in Homebridge deCONZ;
- Remove Homebridge deCONZ from your test HomeKit home, and pair it to your real production HomeKit home. Remove the test HomeKit home;
- Expose a device (that passes the checks in step 4) in Homebridge deCONZ. Note the message of the migration resource link in the Homebridge log. You'll now see the accessory twice in HomeKit, once exposed by Homebridge Hue, and once by Homebridge deCONZ.
- Configure the Homebridge deCONZ accessory in HomeKit: assigning it to the HomeKit rooms, groups, scenes, automations like the Homebridge Hue exposed accessory.
- Update the Homebridge Hue config.json setting
homebridgeDeconz
to the ID of the migration resourcelink by Homebridge deCONZ from step 8.- Restart Homebridge Hue to apply the migration resourcelink, blacklisting the devices exposed by Homebridge deCONZ.
- At your convenience, repeat steps 8, 9, 11 for each device connected to the deCONZ gateway.
Cleanup Homebridge Hue
- After all devices have been migrated, remove the deCONZ gateway from the Homebridge Hue configuration. When listing bridges and gateways using
hosts
, remove the IP address and port of the deCONZ gateway from the array. When using automatic discovery, setnoDeconz
.- Uninstall Homebridge Hue once all gateways are migrated (unless you still use it for any Hue bridge).
Thank you very much for those instructions! BTW the BackUp function of the "Controller" App helped a lot
UPDATE DEC 2023 I've removed mention of the deCONZ gateway from the Homebridge Hue documentation and Wiki. Homebridge Hue v0.13.70 is the last version that still supports the deCONZ gateway. In januari, I will publish a v0.14 of Homebridge Hue, that will no longer support the deCONZ gateway.
As of v0.13.70, ph
no longer supports the deCONZ gateway. Use deconz
to interact with the deCONZ API from the command line. This utility is bundled with Homebridge deCONZ, or can be installed standalone from the hb-deconz-tools
package.
In other words: plan your migration to Homebridge deCONZ now. See https://github.com/ebaauw/homebridge-hue/issues/1070#issuecomment-1674780081 for details.
Note that Homebridge Hue2 is still a placeholder, so please continue to use Homebridge Hue for the gen-2 Hue bridge.
Familiarise yourself with Homebridge deCONZ
1. Install Homebridge deCONZ in a child bridge. See Homebridge deCONZ README for details, incl. link how to setup a child bridge; 2. Pair Homebridge deCONZ to your deCONZ gateway; by default, it will expose all zigbee devices connected to the deCONZ gateway. 3. Temporarily create a new HomeKit Home, and pair the Homebridge deCONZ child bridge to that Home; 4. Check that your devices are exposed correctly. Log an issue for devices that aren't exposed correctly or for which you need additional feature requests. 5. Play around with the dynamic configuration through the `ui` command-line tool, un-exposing and exposing devices, changing log level, how to expose devices, etc.
Move Homebridge deCONZ to production
7. Un-expose all devices in Homebridge deCONZ; 8. Remove Homebridge deCONZ from your test HomeKit home, and pair it to your real production HomeKit home. Remove the test HomeKit home; 9. Expose a device (that passes the checks in step 4) in Homebridge deCONZ. Note the message of the migration resource link in the Homebridge log. You'll now see the accessory twice in HomeKit, once exposed by Homebridge Hue, and once by Homebridge deCONZ. 10. Configure the Homebridge deCONZ accessory in HomeKit: assigning it to the HomeKit rooms, groups, scenes, automations like the Homebridge Hue exposed accessory. 11. Update the Homebridge Hue config.json setting `homebridgeDeconz` to the ID of the migration resourcelink by Homebridge deCONZ from step 8. 12. Restart Homebridge Hue to apply the migration resourcelink, blacklisting the devices exposed by Homebridge deCONZ. 13. At your convenience, repeat steps 8, 9, 11 for each device connected to the deCONZ gateway.
Cleanup Homebridge Hue
14. After all devices have been migrated, remove the deCONZ gateway from the Homebridge Hue configuration. When listing bridges and gateways using `hosts`, remove the IP address and port of the deCONZ gateway from the array. When using automatic discovery, set `noDeconz`. 15. Uninstall Homebridge Hue once all gateways are migrated (unless you still use it for any Hue bridge).
What will happen with automatins within Homekit? Will they break when i'll migrate all the devices?
What will happen with automatins within Homekit? Will they break when i'll migrate all the devices?
That's already been answered above.
What will happen with automatins within Homekit? Will they break when i'll migrate all the devices?
That's already been answered above.
Sorry ... totally forgot that i already asked.. my bad. Christmas stress :=)
Sorry if this is considered spam, but I thought maybe my script could help someone else 🙂
I have a lot of devices, to calling the ui
tool to un-expose each device is very tedious, so I created a small script to do it for me.
First get a json file with all of your devices:
ui get /devices > devices.json
Then create a simple script like this (just put this into a file called un-expose-all.sh
or whatever you wanna call it):
#!/bin/bash
# Path to the JSON file
FILE="devices.json"
# Check if the JSON file exists
if [ ! -f "$FILE" ]; then
echo "Error: File $FILE does not exist."
exit 1
fi
# Read and process each device in the JSON file
jq -c 'to_entries[] | {id: .key, expose: false}' $FILE | while IFS= read -r line; do
id=$(echo $line | jq -r '.id')
# Call the 'ui' app with the updated device information
ui put "/devices/$id" "{\"expose\": false}"
done
echo "Devices updated successfully."
Make the file executable:
chmod +x un-expose-all.sh
Then execute it:
./un-expose-all.sh
Once it has completed, all of your devices will be un-exposed.
I am attempting to set up a semi-DIY "smarthome" built around the Apple eco-system. Most of the lights are ZigBee. Different brands but controlled from the Hue v2 bridge for two reasons:
Hue already exposes all the lights to Homekit. However through the Homebridge plugin they respond significantly better / more consistently. However still not perfect.
I see now that you are building 2 separate plugins - and that DeConz seems to support more features.
Q: is there a benefit from transitioning to DeCONZ and the DECONZ plugin now? or vice-versa a benefit to Hue? Alternatively: assuming you had already refactored the plugins and ì did not know Hue yet ... which direction would you advise to go - Hue2 or DeCONZ?
Considering support on Homebridge, but also more generally beyond with Node-Red etc.
See for https://github.com/ebaauw/homebridge-hue/wiki/Features comparison of HomeKit support of Hue bridge's native HomeKit feature vs Hue bridge's native Matter feature vs Hue bridge with Homebridge Hue vs deCONZ with Homebridge deCONZ. It largely depends on the devices you have. Next to HomeKit you might have other considerations like the Hue app, dependence on cloud services, or features like Hue Entertainment.
UPDATE DEC 2023
UPDATE AUG 2023
Homebridge Hue is my oldest plugin. I started working on it in February 2016, and published the first version on GitHub in October 2016. I added support for deCONZ in the summer of 2017, including web socket notifications. In February 2020, I added HTTPS support for the gen-2 Hue bridge, followed by API v2 push notifications in December 2021. Over that period, the number of different devices supported by Homebridge Hue has increased dramatically, fuelled by the consumerisation of Zigbee devices. Starting with (then) Philips Hue, OSRAM Lightify, and IKEA Trådfri, followed by Xiaomi, and many OEM devices, and even devices from Lidl and Aldi. The code base has become increasingly complex over the years, and is due for a refactor. Homebridge Hue still uses Homebridge's traditional static platform accessory model (see #4), where most recent plugins use the dynamic platform accessory model, which offers many benefits. The Hue and deCONZ APIs have been diverging, and their v2 APIs are completely different, making it increasingly hard to combine Hue bridge and deCONZ gateway support in a single plugin.
Homebridge Hue is also my most used plugin. I don't collect any statistics, but the NPM registry mentions up to 8,000 weekly downloads, and GitHub Insights lists over 3,400 unique visitors. Homebridge Hue is also, by far, my largest plugin; I'm exposing over 140 accessories from my deCONZ gateway. I would take me half a day to reconfigure HomeKit if those accessories would be removed from HomeKit and re-exposed. Because of this, I've been hesitant to refactor Homebridge Hue. While I can technically manage to expose my accessories using a dynamic platform plugin, without HomeKit losing them, this is tricky and requires a deep understanding of the internal working of Homebridge and HAP-NodeJS. For me, a big-bang update would be out of the question, as I think for most users.
Going forward, I will create a new plugin for deCONZ, homebridge-deconz, and a new plugin for Hue APIv2, homebridge-hue2, while keeping the current Homebridge Hue plugin. These three plugins can be run in parallel, using different child bridges, connecting to the same Hue bridge(s) and/or deCONZ gateway(s). This allows you to setup a new HomeKit home for testing. By connecting the child bridges for all plugins to the same Home, white- and blacklisting can be used to move accessories over to the new plugins one-by-one. This will also allow me to release work-in-progress versions of the new plugins, not yet supporting all device types. Eventually the current Homebridge Hue plugin will drop support for the gen-2 Hue bridge and the deCONZ gateway. After that, I might release a new version with the dynamic platform accessory model. I don't think there are enough users left using the gen-1 Hue bridge or HA-Bridge or Tasmote to justify the effort needed to provide a gradual migration path.