So today I realized that all my Hue lights (50+ devices) were not working. After some basic troubleshooting, it seems the bridge is dead. I’ve contacted Philips Hue support via Twitter to see if they have any sensible suggestions for resolving this but I have a feeling the hub is dead.
As I have 50+ devices, I’m not looking forward to having to manually reset each and every device and then re-adding them to my system but I’m starting to come to terms with the fact that is what I’ll have to do.
Question then becomes, should I get a new Philips Hue hub or can I move all the devices over to my Tasmota-based Sonoff hub? Any suggestions?
You could use a Tasmota-flashed Sonoff ZBBridge as a remote adapter but it is absolutly not recommend if want a stable setup (because such a bridge will use Wi-Fi to tunnel serial protocol communication that is designed to directly connected so not meant to even be disconnected even temporarly like WiFi does sometimes), instead recommend buy one (or) more CC2652P based Zigbee Coordinator USB adapter like the ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus” (model “ZBDongle-P”) as then you have the option to use either Home Assistant’s own native/built-in “Zigbee Home Automation (ZHA)” integration or the popular third-party Zigbee2MQTT solutions as your Zigbee gateway, or optionally you could even use/test both separately at the same time as long as they have their own Zigbee Coordinator USB adapter (but they will not be aware of each other in any way and each devices can only connect to one of them, however you can use devices from any of those inside Home Assistant and integrate such devices there if needed, still the general recommendation is to only use a single Zigbee solution if possible as consolidatiing all Zigbee devices on one common Zigbee network makes better use of its network mesh capabilities).
Also, since you will be starting from scratch to create a new Zigbee network do make sure that you start by adding all your mains-powered devices before adding any battery-powered devices, (since most mains-powered devices will likely act as Zigbee Router devices).
PS: Personally I use the ZHA integration right not though I have used Zigbee2MQTT to and recommended both, just be aware that they have different pros and cons, so suggest you do some more research or just test both before deciding which
The main reason I would like to go for the Tasmota solution right now is that my HA server is a VM without any connections to physical devices, so therefore it is easier to have a solution where the bridge is just on the network somewhere.
The other piece here is that I have one and the mrs is not happy when basically no lights are working atm. So it is either migrating to the Tasmota or go buy a new Hue bridge but I like the fact (at least from my understanding) that I can back things up with Tasmota which isn’t possible with the Hue bridge.
I am somewhat wondering the same thing. My Hue Bridge has not died (yet), but it’s nearing it’s capacity limit and I want/need to add about 15 or so more lights in the near future. To experiment, I’ve bought a Sonoff-P stick. Is there any current pro/con listing of the “big” ZigBee alternatives?
Here are the items I have been thinking of:
Stay with Hue Bridge (in my case: add a second bridge):
Pro:
All features of Hue devices supported.
First- and third-party apps continue to work.
Works independently of Home Assistant.
All firmware updates for Hue devices available,
Great configuration options for motion sensors with third-party apps (iConnectHue).
Con:
More energy usage (an increase of +5W for two bridges compared to a USB dongle).
Multi-bridge support is meh.
Separate ZigBee networks when using two bridges.
No backup.
Only lights and “light-adjacent” devices supported.
Move to Zigbee2MQTT:
Pro:
Lower energy usage.
Backup possible (for some controllers).
Single ZigBee network.
No limit on device types.
Can use direct binding.
Most newer Hue devices are supported (“Gradient” devices, energy-harvesting/ZGP devices like Friends-of-Hue switches).
Con:
Properly automating motion sensors needs a lot of work in HA (two or more motion sensors capturing different parts of a room - lights should stay on with while either one is active, but only one of the sensors should initially switch on the lights).
Stability issues with certain older Hue devices (notable the first-generation indoor motion sensor SML001).
Can work without HA per se, but does not contain any automation features, so in practice HA or another automation platform is still necessary for everything except direct binding.
UI is meh.
Move to ZHA:
Pro:
Lower energy usage.
Backup possible (for some controllers).
Single ZigBee network.
No limit on device types.
Can use direct binding.
Better integration with HA/better UI.
Con:
Newer Hue devices are still not supported (“Gradient” devices, energy-harvesting/ZGP devices like Friends-of-Hue switches).
Hue firmware upgrades don’t work out of the box.
Is dependent on HA for everything.
Properly automating motion sensors needs a lot of work in HA (two or more motion sensors capturing different parts of a room - lights should stay on with while either one is active, but only one of the sensors should initially switch on the lights).
Stability issues with certain older Hue devices (notable the first-generation indoor motion sensor SML001).
Personally I would recommend using USB-passthrough to the VM using a very long USB-cable (preferably through a powered USB 2.0 hub), but if USB-passthrough to VM is not possible then instead check Ethernet based Zigbee to network bridges such as ZigStar and Tube’s Zigbee Gateways for a wired connected so the communicatiln is wired (as serial tunneling over WIFi will likley cause issues).
There probably are many if you search Reddit or YouTube, (i.e. ex. ”ZHA versus Zigbee2MQTT”), but development of them still moves relativly fast so older reviews will quickly become out pf date.
See if you have a compatible other power supply and try that first. In my experience, 75% of device failures are due to the power supply.
ZHA works perfectly file with Hue, with the added benefit of getting na clearer picture of your mesh, but do realise; the only way to have firmware updates of Hue devices is a Hue hub. As soon as I discover how to do firmware updates in an easy way with ZHA (Or Zigbee2MQTT for that matter), the Hue hub is gone.
By the way, recommend connecting the Zigbee Coordinator USB-dongle using a powered USB 2.0 hub with an external AC adapter power-supply as then you see to it that it both gets enough power and makes sure it is connected via USB 2.0 (and not USB 3.0 which causes interference). Also recommend using a very long USB extension cable. That is also the only solution if your computer/NAS does only have USB 3.x ports as the USB 2.0 hub will in practice convert one of those to USB 2.0 ports without interference:
It is true that Philips Hue OTA firmware images are not downloaded out-of-the-box, but with with zha-toolkit it is not very hard to configure HA so it downloads Philips Hue OTA firmware images for ZHA.
Yeah, I’ve watched several of them. But as you say, they are all outdated (and the videos tend to focus on non-IT people - setting up an MQTT broker is not a relevant criterion for me).
Correct me if I’m wrong, but from what I gathered, the “gradient” feature of the various Hue Gradient * devices is also not supported (i.e. setting more than one color).
Look, I don’t know why you are so defensive here. I am trying to decide for myself what the best way forward is for my “zoo” of Hue devices and to objectively list pro and con arguments for each of the three stacks, I never said it was a bug or defect in ZHA, only that certain Hue devices are not supported yet. Maybe I should have written “fully supported”, but that is the current state.
It will probably change in a few months, but right now, certain devices and/or features only work with Z2M or the Hue Bridge. Personally, I currently don’t care about ZGP because I don’t have any of those, but Gradient support is something to factor into my decision (a bit, other considerations are probably more important).
the fact it died is a worrying thing, especially since the community has asked backup features as a nr 1 priority for a very long time… we all wish Signify would finally figure that out by now, its an unbelievable let down.
having said that, please let me add that I have 3 bridges,(which never gave a blink just yet in all of the 6 years I am using them) and the multi bridge experience in the Hue app is simply very easy.
Only thing to take into account is when you’d want a motion sensor on Bridge 1 to interact with a light on bridge 2 or 3. that cant be done, and one would need HA to integrate those. Just add devices to the bridges with this in mind and your good.
I feel the Hue ecosystem is taken down in the HA community a bit too harshly, and the other Zigbee options are a bit overpraised… have them all and there’s simply no comparison imho as to the ease of use, options and maintenance, Hue wins hands down.
I’ve had more than a few occasions where HA was down or broken, and I was very glad I had my Hue lights on their dedicated system…
Got to love an independent system, and yes love the fact they can be integrated into HA. I just don’t want to rely on Ha alone. It is after all still a beta/volunteer product, where Hue is a huge commercial operations and they cant afford their costumers to have to wait for a dev to finally acknowledge and fix a bug and dont blame a 3d party…
I am only stating the fact as an introduction to both ZHA (and Zigbee2MQTT), and the fact is that while with only a few limitations, most devices will join/pair directly to the ZHA integration regardless of brand and manufacturer, but because the Zigbee specifications allow for manufacturers to add custom non-standard features/functions to new products that are impossible for developers to predict and add support for in advance, thus users of all and any Zigbee solutions need to be aware that not all functionality will always be supported out-of-the-box and devices that use custom “manufacturer-specific extensions” to add functions and features not including in the standard Zigbee specifications will need device-specific code to fully work with ZHA.
So any new device that make use of never before used manufacturer-specific extensions will simply not work just because they are Zigbee 3.0 compliant, not even if they are Zigbee 3.0 certified devices. New Zigbee devices will always need custom device handlers/converters in all Zigbee gateway solutions, that do not only include ZHA and Zigbee2MQTT or other open-source solutions but also commercial Zigbee hubs, also when using the official brand gateway/hub/bridge will need a firmware update that must contain additional custom device handlers/converters if they made use of new manufacturer-specific extensions that have never been uses by any other device before.
If a device that uses custom “manufacturer-specific extensions ” to add new non-standard functions and features is supported in one Zigbee solution but not another then that simply means that an end-user and a developer have not yet collaborated to create a new custom device device handler/converter for that specific device in that Zigbee solution.
Anyway, I do not mean to sound defensive. I am pro both ZHA and Zigbee2MQTT, (I consider myself a contributing member to both those communities and can personally recommend either of those depending on the user’s use cases and. What I am trying to get access to is that you need to help us help you, (you help yourself by helping us). Understand that Zigbee is very complicated under the hood, probably a lot more so than you know today, and both users and developers do unfortunately need to jump through hoops to work around its quirks. If you instead want something that just works then either go with Z-Wave or stay with using proprietary hubs with only the manufacturer’s own brand of devices.
Regardless, please remember that these are free and open-source software applications with development and support being done by unpaid volunteers as a hobby. So please try not to state that something does not work and then say that you are not personally willing to follow recommended actions or troubleshoot and actively put in some effort yourself to sort out why something does not work (such as for example helping developers decode add new device handlers/converters to a Zigbee solution if a device does not fully work out-of-the-box after you joined it).
Many of us use a virtualized installation of HA with USB zigbee coordinator.
It might be harder to set up but if you follow the recommendations for using a USB coordinator, it works just as well.
The only downside compared to a network connected coordinator can be the position of your server in your home.
I don’t see anything that is defensive, he’s trying to help you by providing information of something he has more knowledge of then the average user here.
not entirely sure why you quoted me there, but I feel you are exactly proving my point, why a standalone professional product is to be preferred over any integration in HA.
Of course we all want that integration and even with that in mind, I am not attracted to the Zigbee process you so describe in such detail, on the contrary I must admit. It underlines my personal experience and that is why I still have but a few bulbs/sensors in a test setup (to keep up with developments), and haven’t migrated all, for the sole reason to be Signify independent, or the fear mongering (not your words) that they might cut support in a whim.
I guess it boils down to the ‘to each their own’ mantra
