Hi I’m currently using ZHA and everything is working great, I’m wondering if I should try Z2M and if any of my devices would work better or expose more options, my devices are
Aqara FP300
Aqara Mini Wireless Switch
Candeo C202
INNR SP242
My recommendation would be unless you have a very good reason to use MQTT, stick with ZHA. I have a very specific reason to switch, and spent many hours trying to set up MQTT, but eventually put it in the too hard basket and went back to ZHA, which just works. From what I could see, MQTT takes not just the effort of setting it up in the first place, but makes everything more difficult in ongoing maintenance of the system. ZHA is well integrated with HA, and makes life easier.
3 Likes
Z2M has a supported devices list at:
So you could look them up and compare them to your current ZHA setup to see if there is anything extra that looks useful to you.
Pros:
- If you only have 4 devices, now might be the time to migrate since it won’t take too long to re-pair them.
- You may buy other stuff in future which may have additional attributes you want to use.
Cons:
- Z2M is significantly more complex to setup than ZHA.
- Some say Z2M has slightly higher latency - After making sure my firmware is up to date its not really bothering me, but others have complained.
- I needed to rework my automations for for battery powered scene switches since the messages were totally different.
I have moved from ZHA to Z2M, but I don’t have any of your devices.
My reasoning was:
- I had occasional failures with ZHA.
- I want the MQTT visibility into all devices.
- I have already done other stuff with MQTT.
- I wanted to be able to change the timeouts on my motion sensors and that is not supported under ZHA.
- It gave me an opportunity to clean up my messy naming conventions.
I also purchased a new coordinator so that I could run both ZHA and Z2M at the same time so I could take my time to migrate.
I use both at the same time. I find Zigbee2MQTT is more powerful & is more likely to connect to new devices than ZHA, though sometimes it seems as though the device chooses it’s protocol.
I might add that I use two identical ZigBee dongles to run the two different protocols.
I only ran both to ease the migration process.
Is there a reason you haven’t dropped ZHA?
I only have 8 devices in ZHA, I have a spare zigbee coordinator so I could try both at the same time
I’ve used ZHA ever since I started with HA around 8 years ago.
I tried Z2M for a short time for a couple of new devices but found no benefit to it so I stuck with ZHA.
I still \don’t think there is any need for Z2m and I have many (50+) devices from many different vendors.
1 Like
I think for most people they will spend a bunch of time trying to setup Zigbee2MQTT.
- With a good tutorial (specific to the coordinator you have) it can be a 10 minute job.
- Without it, you may spend hours and then give up without being able to get it to work.
For those that have a working Z2M setup they probably don’t have a “silver bullet” feature, as a result for them it really doesn’t matter which (ZHA or Z2M) they use - for their needs, both are identical - hence the work to setup Z2M was a waste of time (for them).
Running both (long term) may be an undesirable configuration because you are splitting up your devices so each network only has 1/2 the Zigbee routers of a single network.
There is only really one feature of ZHA which I miss, which is that it did a better job of automatically categorizing device: Lights, Switches, Sockets, …
Out of the box Z2M just gives me a long list of devices, I can improve things by naming things well/tagging them, but I have lost something.
All that said, I am happy I made the switch - for the reasons previously posted.
I have sonoff trv’s, 3 of them on zha and one spare on z2m for testing purposes. I can confirm that z2m is significantly more complex to setup. Yes, there are a few more sensors (in my case), but not used: schedule and some not important ones. I guess that on zha schedule is not shown primarily beacuse whole thing is meant to be used as integrated into HA, not running standalone, so any schedules will be set up inside ha, not on the valve itself.
I’d say that if you don’t miss anything stick with zha.
I’ve set up z2mqtt and the aqara fp300 seems to work better on that than on zha as does the Sonoff SNZB-02P
I think if you already have an MQTT environment as a foundational component, then Z2M would make a lot of sense.
For me, HA is the foundation. The fewer layers in the stack between me and the devices, the better. Yes, latency and the learning curve come into play here. But I consider HA a critical production system. I want the fewest components and the fewest points of failure.
The question is not which is “better.” The question is, which will do the job you need done, while minimizing the risk of failure and the amount of effort needed to implement and maintain it.
I don’t believe you will notice any difference in latency between ZHA and Z2M.
What are seeing for you to say that?
seems to report more frequently and more precise
frequency might (maybe) be controlled by the integration but I would be surprised if the precision was. That should be a function of the end device.
all I know is it’s working better for me
Z2M allows you to set (reduce) the precision on devices. I believe default is 2 dp, which might be more than what ZHA provides by default.
How is that different than what is built into Home Assistant?
I know that a few releases ago HA decided to not mess with the precision on devices. It’s why my ESPHome temperature now reads “72.76565875”. 
But who knows. Maybe that’s an integration that didn’t get changed.
So I’d be surprised if the ZHA integration reports less precision than the end device. And I doubt Z2m can report more precision than the end device reports no matter the default.
HA can only work with the info it receives from the underlying integration and reduce the precision from there. It can’t magically add extra values to those decimal places if the info wasn’t there in the first place.
Assuming the Z2M device sends Temperature as 18.825, you can choose to reduce the value sent to HA as 18.82. You can then choose (inside HA itself) to further reduce it to 18.8. Trying to increase the dp after the original value has been sent will only result in additional zeroes at the end.
What I’m saying is, if ZHA only sends 18.8, you can choose to either display it as 18, 19 or 18.8. Increasing the dp won’t magically cause the “proper” value to be shown - all it’ll do is just add a bunch of zeroes at the end.
Neither integration can do that, hence my emphasis on reduce. It all boils down to the chain between the base device reporting precision to HA:
- End Device: 72.76565875
- Integration (eg. Z2M): 72.765 or 72.76 or 72.7 or 72
- HA (assuming you selected 72.76 above): 72.8 or 72.76 or 72.7 or 72 or 72.760 or 72.7600 or 72.76000…