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
Indeed, out-of-the-box support for custom features/functions in new devices + always getting the latest firmware updates from the official source are usually the main benefits of using the manufacturer’s commercial Zigbee gateway/bridge/hub with their own branded devices.
The main downside to that (other than having to maintain different brand hubs in multiple apps) is that manufacturer’s own Zigbee gateways/bridges/hubs normally only support their own brand of devices, and Zigbee heavily relies on mesh networking using indirect routing over Zigbee Router devices in the Zigbee network to achieve better range and coverage, so optimally you want to keep all your Zigbee devices on the same Zigbee network if possible to get good range and coverage.
Zigbee radios have very short range and poor wall penetrating signals to its network mesh technology and Zigbee Router devices is the key to a stable Zigbee network, and that will not work well in practice if you need to use a different Zigbee gateway/bridge/hub for each brand of devices that you buy if you only have a few devices connected to each and spread out those far away. See these tips which apply to all Zigbee solutions (even proprietary Zigbee gateways/bridges/hubs ) → Guide for Zigbee interference avoidance and network range/coverage optimization
well, hope the OP will be able to filter all of this into something useful, it sure feels like we’re being offered some Chat GPT advise here, did you ask it for help by any chance?
