I chose Z2M because it supports some Zigbee devices I have that ZHA does not. Double-check all of your devices at the Blakadder site to see which system(s) they will work with, then make your decision from there.
1 Like
That is not the consensus. Z2M supports more devices than ZHA, but I’m sure you can find a few exceptions.
My general take on the two is here.
I’d recommend getting the dongle, use it to run z2m side by side with ZHA, test a few devices, and then decide where you want to be long term. If you decide to keep z2m, migrate at your leisure - you can move devices one by one. If you stay with ZHA, remove z2m and migrate ZHA to the new stick.
For z2m the ZBDongle-P is recommended. The ZBDongle-E is supported, but is currently labeled as experimental - it is mssing backup/restore functionality.
But… One advantage of the ZBDongle-E is it can be flashed with the multi-pan firmware and be used for both Thread and zigbee2mqtt.
2 Likes
Well… the P has some known hardware QC issues. There’s problems with the NVRAM (which causes the stick to silently crash, but restarting Z2M restores the NVRAM and clears the problem), and another more widespread problem where too many messages can crash it (again, restarting Z2M clears it).
I’d recommend some other CC2652 based coordinator, ideally one of the new CC2652P7 ones (newer more capable chip).
2 Likes
My devices expose only very few entities in ZHA but a lot in Z2M - especially the entities that are the reason why I built the setup. Therefore I have no alternative to use Z2M and never encountered any issues that would be solved in ZHA. Also I have some native MQTT devices that connect to MQTT native.
Do you have more information (or a link) on the Sonoff QC issues with the -P?
I’ve never seen a detailed writeup, just many complaints on multiple forums, Discords, GitHub issues, etc…
They are more stable than the CC253x chips, but that’s a pretty low bar.
After this feedback I ordered a UZG-01
1 Like
Good choice! Been running mine for some days now, very happy with it.
1 Like
I switched from deconz to mqtt and im quite happy with the much better support for devices and also getting more atrributes.
Im running
SONOFF Zigbee Gateway, ZBDongle-E USB Zigbee 3.0 USB Dongle Plus,EFR32MG21 + CH9102F Zigbee USB-Stick EFR32MG21
with Zigbee2MQTT and https://mosquitto.org/ both as container on my QNAP and it works quite smooth. (HA is also a container)
I will convert all my zigbee devices over to ZBMQTT (then i get some time)
still a bit worried about new device names and ids …
I have five installs I’m “tech support” for. All on ZBDongle-P, all solid.
Probably another dozen or so P’s as routers, again, no issues.
AFAIK. the nvram is on the C2652 mcu itself, no separate memory chip specific to the Sonoff. I’d suspect something in the serial chip first.
I have to wonder if the ZBDongle-P problem rate as a percentage is really any worse vs other CC2652 sticks.
I have no way of knowing, but my guess there are more Sonoff sticks in the wild than any other CC2652 stick by an order of magnitude or two.
I switched from Deconz to SkyConnect / Z2M. I choose Z2M because the general consensus seems to be that it supports more devices and is the more mature solution.
In my case this was a bad decision. The Zigbee network is unreliable, devices drop silently out of the network, the communication with the devices sometimes does not take place at all (though the web ui happily claims it), etc. I’m not the only one with this problem if you search github issues, though these bug reports do not get any attention at all.
So at the moment I consider switching to ZHA…
There’s a 99.99999999999% probability that changing to ZHA won’t change that. Almost all problems like this relate to the mesh, which Z2M (and ZHA) has no control over.
I don’t think so, as these problems did not occur with my previous setup (Deconz). I also know the best practices (USB 2.0, extension, away from router…)
And I also think that it should not happen that devices drop out of the network silently (why is it my job to count the number of available Zigbee devices every day, and to find out which is lost if the number is too low?) or that the communication to devices fails while the UI of Zigbee2MQTT pretends that everything is fine.
What also unnerves me is that there is no feedback to bug reports in the Z2M github, while for new device support there is almost instant feedback.
So my experiences with Z2M is rather not so positive at the moment.
EZSP (and thus SkyConnect) support in Z2M is still experimental.
But it won’t get better if problem reports are not even taken into account… I use Zigbee2MQTT for about four weeks now. Because of my problems I closely follow the github issue list, and all those problems - which very often, but not always occur with EZSP dongles - simply get no feedback.
I know that EZSP is experimental, but I had not imagined how alpha this still is.
Zigbee Dongle P + Z-Stack_3.x.0_coordinator_20221226 + ZHA is a rock solid setup.
Tried SkyConnect and other Silicon Labs EFR based dongles and some Zigbee devices would simply go to sleep requiring some sort of manual intervention to wake them up.
I hope next year we finally get a new generation of chips that can handle both Thread and Zigbee without issues…
Well, Koenkk is working regularly Z2M and the related projects. All the reports flood into Z2M even when another project would be more appropriate. TBH, I am surprised that he has not disabled issue tracking by this point. There is a lot of noise there.
Just wondering: What “other project” would be more appropriate in this case for bug reports?
Don’t get me wrong, I appreciate the work being done here (for free), however concerning the original post I just wanted to point out that there are also negative experiences with Z2M.
Take your pick: