ZHA and Philips Hue Firmware

I see a lot of threads about updating firmware with zha and all its complications. Shouldnt there be a more native way to do that out of HomeAssistant? It should be a quite normal use case to pair devices directly via SkyConnect / Sonof or other sticks and it sucks that you don’t receive updates for that devices if you don’t do some “complex” configurations.

This is especially about the Hue updates, there I have 2 questions: I read that you need the bridge to update, but that would mean you have to pair the Bulb with the bridge instead of HA directly, right?
That beeing said, question 2 would be, if I would change from pairing directly with HA, to pair with the Hue bridge, wouldnt that make my zigbee network way smaller? Or do they still connect with other zigbee devices, e.g. aqara motion sensors, etc…?

How do you guys handle the zigbee update topic?

Thanks for the help,
Daniel

1 Like

You do not need Philips Hue Bridge to upgrade firmware on Philips Hue Zigbee devices via OTA update (Zigbee Over-The-Air updates).

ZHA does support the same standard Zigbee OTA that Philips Hue support, the issue is that you need the official Zigbee OTA firmware image from Philips/Signify for each Philips Hue device that you want to upgrade, and there is the challenge as Philips/Signify as a company still does not publish such official Zigbee OTA firmware images via a public repository or in any other way make them available for third-parties to download.

So the problem is that Philips/Signify does not yet share their Zigbee OTA firmware image files to officially enable Zigbee OTA updates of Philips Hue devices via a third-party Zigbee Gateway, as so far they only allow Zigbee OTA updates of their devices via the official Philips Hue Bridge.

Meaning that Philips on purpose aim for vendor lock-in for that feature → Vendor lock-in - Wikipedia Today that is really considered a bad faith practice as access to OTA firmware update files to Zigbee devices that you bought and paid for should be considered as fair use even if you do not use a companies propriatory Zigbee Gateway → Fair use - Wikipedia

Anyway, Home Assistant’s built-in ZHA (Zigbee Home Automation) integration and the zigpy library/framework it depends on does support Zigbee OTA Upgrade using the standard Zigbee OTAU format, but the problem is with the companies making Zigbee devices as most of them are simply not providing Zigbee OTA images third-parties or just making them publicly available. See → https://github.com/zigpy/zigpy/wiki/OTA-Information-for-Manufacturers

This could be a non-issue for third-party Zigbee gateway solutions if all manufacturers of Zigbee devices simply publicly posted URLs to unencrypted Zigbee OTA firmware images for their devices to allow third parties to download them directly from the official source. Philips/Signify and many if not most manufacturers do unfortunately not do so. However, some companies do, which is why you can perform OTA upgrade of those directly in Home Assistant’s built-in ZHA (Zigbee Home Automation) integration, (specifically; IKEA, LEDVANCE/OSRAM, SALUS/Computime, INOVELLI, Sonoff/ITead, THIRDREALITY, and a handful more are among the few companies that provide official unencrypted Zigbee OTA upgrade image files available via public servers), and a there are also a few other which zigpy is missing the download code for, see zigpy feature requests → https://github.com/zigpy/zigpy/issues?q=is%3Aissue+is%3Aopen+ota+AND+request

The workaround some other Zigbee gateway solutions (such as example Zigbee2MQTT) provide for getting the images in unofficial ways is to host collections with copies of official Zigbee OTA firmware images that have been collected in various unofficial ways (e.g. either dump the embedded EEPROM of an already updated Philips Hue device or use PCAP packet capturing traffic sniffing techniques to eavesdrop on the communication to the Philips Hue Bridge when it is downloading OTA firmware images and then reconstruct an OTA image from a series of such PCAP packet captures, non of which methods have legally been tested in a court of law but since the actual firmware images can only be used by owners of those devices to update the original devices there is probably a strong argument for “fair use”), see example → https://github.com/Koenkk/zigbee-OTA

Blame the companies that manufacture devices but do not publicly offer official Zigbee OTA source providers that third parties can use too.

Yes I am sure most users would think that it would be very nice if some similar unofficial workarounds were natively built-in into Home Assistant’s built-in ZHA (Zigbee Home Automation) integration or the zigpy library/framework it depends on, and technically it would not be difficult for developers to add an unofficial source (like a GitHub repository with copies obtained via various unofficial means), but there are also many arguments why not include such unofficial sources, like for example; who the users should blame if the OTA upgrade image break/brick their device(?), and what if doing so in an unofficial way would get Nabu Casa and/or the Home Assistant project on bad side of companies that might someway otherwise want to partner with Nabu Casa and join the Works with Home Assistant” program in the future → https://partner.home-assistant.io/ as easy firmware upgrades is part of the idea behind that partnership → https://www.home-assistant.io/blog/2022/07/12/partner-program/

Responsibilities = "Provide easy firmware updates: Works with Home Assistant partners are expected to provide firmware updates via user-friendly services provided by Home Assistant

FYI, the developers of Home Assistant’s built-in Z-Wave integration which do have a matching GitHub repository with caches OTA images for Z-Wave devices have written this related statement into their Z-Wave JS Firmware Update Service documentation addresses the question about providing firmware definition files from unofficial sourcs:

Warning: We will not accept firmware updates hosted by third parties. All updates must come from the respective device manufacturer. We make an exception for firmwares that are publicly hosted by the manufacturer, but those may still require confirmation the manufacturer’s confirmation before merging.

Again, the best option for all would be if all device companies could be convinced to allow third parties to download official Zigbee OTA image files directly from official sources to be able to simply add download code to zigpy for enabling the ZHA integration to use them (regardless if they choose to partner with Nabu Casa for the “Works with Home Assistant” program or not) → https://github.com/zigpy/zigpy/wiki/OTA-Information-for-Manufacturers

As explained above, until official sources are made available by those companaies, a Do-It-Yourself workaround for Home Assistant’s built-in ZHA (Zigbee Home Automation) integration is to download unofficial Zigbee OTA images manually from example https://github.com/Koenkk/zigbee-OTA (follow https://www.home-assistant.io/integrations/zha#ota-firmware-updates and https://github.com/zigpy/zigpy/wiki/OTA-Device-Firmware-Updates for how to add files manually to ZHA) or download automatically via scripts from unofficial sources. See example zha-toolkit → https://github.com/mdeweerd/zha-toolkit/blob/main/README.md#ota_notify—downloadtrigger-device-fw-update

Zigbee devices can not be connected to two Zigbee Coordiantors / Zigbee gateways, period. If you re-pair a device to the Philips Hue Bridge or any other Zigbee gateway then it will no longer be paird to the ZHA integration, and vice versa. This is a hard limitation / security-feature in the Zigbee protocol specification that can not be worked around.

There is no way to interconnect two or more Zigbee networks and Zigbee devices on two Zigbee networks (.i.e. two different Zigbee gateways) have no knowledge or interaction that any Zigbee devices that are not on the same Zigbee network exist.

Best is therefore to have all Zigbee devices on the same Zigbee network to make use of Zigbee mesh networking technology for extending range and coverage.

8 Likes