I’ve been digging around here as of late and seeing all kinds of great ZHA-based Blueprints popping up and can’t help myself but wonder if I’m putting too much work into Deconz when the future seems to be moving over to ZHA with my ConBee II stick.
ZHA certainly seems more flexible in what it will be able to offer (and for example, my Hue Dimmers can support many button sequences, vs just the typical press or hold). Similarly I’m having trouble getting Deconz to work with my Lutron Aurora dimmers, but there seems to be a solution for them in ZHA.
I’m just curious what others are doing about this—as ZHA becomes more robust, what are you doing?
I think for the same reason I’ve just bitten the bullet and bought a CC2652RB, and i’m about to give zigbee2mqtt a go, check its latency and how it survives docker/supervisor reboots and updates, and put it through its paces. Deconz is terrible for this with some items, i’ve been hitting it hard testing, and im not happy with it, which was the whole reason i shelved this originally.
I was ready to throw in the towel and try zha, it seems that maybe 6-10 months ago zha was having its day and rapidly rising, but there is an even bigger wealth of ecosystem with zigbee2mqtt.
Since i have an original Conbee, its not compatible with zigbee2mqtt, but if that fails, i’ll give zha a go. Until i fully commit to any of these i just want, reliability and stability then i’ll go wild with the rest.
I have a zigbee network of more than 50 devices with Z2M and a CC2652. It works perfectly, smooth, reliable, no latency,…
Z2M supervision GUI is also now very good.
I recently tried switching from deconz/conbee2 to ZHA with CC2652P since I got annoyed a bit by some battery-powered devices falling off the networks sometimes. I must say regret it every way.
Stability is way way worse than with deconz. I can rule out a faulty device since I also got a CC2652R which I moved over a couple of devices to before. Now I am not sure if the cause is ZHA or the Z-Stack firmware. I even tried different channels and settings etc. I’m seeing devices randomly turning on again after switching them off and only parts of a ZigBee group turning off with a light.turn_off command.
So now I need to move back all my 60 devices to deCONZ it seems. Anyone have any ideas if ZHA + conbee would be a good thing to try or if I am going to get the worst of both worlds.
Alternatively I could try Z2M with the CC2652P but I am not convinced conceptually about the whole JavaScript / npm stuff also I would need to setup MQTT which I don’t need for anything else so I am a bit reluctant.
I have never used deCONZ or z2m. But using ZHA and Conbee II on an RPi4 for approximately 1 year has been very reliable and easy. Myself, I highly recommend ZHA.
I was using DeCONZ with the addon (HA OS). No issue at all except when the addon started to crash multiple times a day. Moved to ZHA with my conbee2 and I have no issue (30 devices). Conbee2 firmware updated to latest release
I tried zigbee2mqtt with a Conbee II stick yesterday. It was complaming that advanced.adapter_concurrent is not a number. Its configured as described in the docs: adapter_concurrent: null
Whats the right value for that for a Conbee II stick? I know, support is experimental.
Complete newbie… Migrating from hue and Vera to HA following house renovation.
From what I’ve read ZHA uses zigpy-deconz if you use a Conbee II so shouldn’t that mean that most items that work with deConz work with ZHA?
While the compatibility website shared above is a great guide it seems to not be up to date for ZHA as I found a GitHub issue which is closed and confirming IKEA tradfri led driver works now but yet it’s not listed. How actively maintained is this list?
Thanks guys. I took the time this morning to unpair my 60 devices from the CC2652P and back to Conbee2 with ZHA. I noticed that now half of my network is at LQI 255 where with CC2652R and P even the line of sight devices were at 120ish maximum. I wonder why.
Things are much more smooth now. Though I still have some light issues with groups and light.turn_off so that might be a ZHA thing after all. Let’s see if I can find the time to investigate this further.
I am about to start with zigbee and I have to decide between z2m and ZHA. Apparently the first one support more devices but there is no oficial list of supported devices in ZHA so can I assume that everything that works on z2m will work on ZHA?
Which one is better in terms of protection and roadmap.
I have read the entire thread but I can find a strong reason to choose, any advice is welcome.
Coming back to this, I am currently building up a Zigbee environment to provide illumination to my garden. I have a Raspee II module on a Raspberry Pi4, running Home Assistant Core on Docker.
I started with ZHA and I like it, mostly due to the fact, that it is „native“ and you can do basic tasks like pairing new devices, do cluster commands and visualize the network from HA UI. Unfortunately, I had to drop it, as my Innr RB 265 bulbs are not supported.
Switched to deCONZ middleware and the HA add-on and started repairing. All bulbs and switches where recognized and appeared in HA. Changes to the network, especially removing devices or groups in deCONZ are not directly reflected, you have to call services for this. Also, for any change to your network, incl. pairing you have to call deCONZ UI („Phoscon“) directly. Now, all of a sudden all devices are unavailable and I am not home. Either a fuse blow or the adapter locked.
Also gave zigbee2mqtt a try and it did recognize the adapter after explizit configuration. However, since I don‘t use mqtt yet, I disliked the requirement for an additional middleware and the manipulation of configuration files to start pairing.
So, I prefer ZHA due to it‘s native integration, but it does not support all of my devices. deCONZ does the job, but you have a second app to use for network changes. And zigbee2mqtt may support the most devices, but introduces even more complexity.
Hmm. there is no such requirement.
Yes, there is a setting in configuration to permanently disable pairing ability. But you can keep it enabled. then you can decide about pairing using GUI button.
While I understand that for you mqtt is new component therefore you may consider it as added complexity, this model of decoupling processing adds to flexibility, transparency and durability of the system.
HA integrations in contrary are just blackboxes.
Since everything is broken (again), I am giving zigbee2mqtt with mosquitto another try. Thanks to Docker easy going.
Everything seems to be connected correctly and I can see MQTT messages coming from z2m and connections from HA. However - having no device paired yet - not a single entry is present in HA, not even the coordinator. Is that an expected behaviour?
never looked to see coordinator as entity in HA.
devices added to z2m are being added to HA by discovery feature automatically (if discovery is enabled), or manually if you wish.
But great with mqtt is, that you can create HA entity manually from any data found in mqtt. Just by defining them as mqtt sensors, lights switches etc. It’s most flexible tool we have.
So if there is no option to show coordinator in HA as entity, you can always create one(s) on its own
Just quick update: So far zigbee2mqtt has been performing well as all devices I own (OSRAM/Ledvance, Innr and IKEA Trådfri bulbs) incl. a DIY router based on ptvo.info work. After pairing, they are discovered by HA using MQTT discovery.
Only thing that’s missing is mapping Zigbee-groups in zigbee2mqtt to HA groups. I create them groups in zigbee2mqtt first and map them to a (light) group in HA later. It is remarkable how lamps of the same zigbee group switch quasi-simultaneously, compared to the delayed and random reaction of the classic HA groups.
Would love to see this feature, but I think the precondition in HA’s disovery is yet missing.