You can use Z2M to control the lights etc. if HA is broken/misbehaving.
You can, but then what’s the point of having HA then… ?
I think you are missing the point, but never mind.
Well, for now I’m up to mostly light control and so on, nothing complicated.
The reason why I started to fiddle with HA (besides the nice community with you <3) is to have the network under one roof, simply.
Not to use 3-4 different networks, tools, apps etc.
I will already have a matter-to-wifi and ZigBee network, but should be ok. Don’t want to make a 2nd ZigBee just for a couple of switches.
For me, it seems like it might worth to restart with Z2A, and it might be more future proof in case I want to update something fancy later.
Quick, maybe stupid question:
Is anything related to Z2A require any additional HW or subscription? Like is there a server that needs to run somewhere else outsa HA green? Do I need to pay for additional cloud or blabla?
I don’t mind if something won’t run if HA or internet is down. It’s an old house, I can switch lights with the original built in switches if needed. 
I just fancy the voice control and some remote switching/automation.
And I can’t stress how thankful for the support guys. Wish you good luck.
I was talking about setting it up. To add devices you also just click add (permit join) and you’re done in Z2M.
It’s a good bridge between random devices and MQTT - in that you can write your own logic against MQTT and integrate almost anything via Home Assistant.
Whether the effort of rolling your own programming model is worth it is going to be a personal choice, but I could see keeping HA around if I ever did, for that reason.
I was in the same position - my intent was to remove the second coordinator once I moved to Z2M - however I never got round to actually unplugging it, so when I wanted to test if one temp sensor would work better on ZHA no hardware changes were needed I just made a couple of clicks in the UI and I was done.
TL;DR - it sounds bad having 2 networks, in my case one only has that 1 temp sensor on it - but the reality is it just works and doesn’t cause me any issues.
Hm… that’s true, i admit. But, in my case GETTING to that took time. With that i mean installing z2m, finding and interconnecting zb receiver, setting all up… once this was done adding trv’s was easy, yes.
Now don’t get me wrong: i’m NOT against z2m, if needed i’ll change to that. It’s just that zha is simpler…
Whilst its true that Z2M has wider device support, and in some cases, better individual device support, I’ve never found that to be a real issue in practise. There are increasingly few devices not supported in ZHA, and those that aren’t, you can usually find a custom quirk to support it until its adopted formally.
If you aren’t sure what custom quirks are, do a quick google search.
I also have several devices from ikea and others that do not expose any entities, mostly button based remote controls. As you’ve already discovered, blue prints are your friend here, and with these you can usually get them to behave how you want.
Does this work for you? I see mixed comments both positive and negative from both zha and z2m users.
I don’t have a Bilresa so can’t really help you.
To clarify…
The difference between ZHA and Z2M is one of philosophy. ZHA aims to support any device which is Zigbee compliant out of the box. Z2M aims to provide a bespoke driver for each individual device, compliant or not.
Since there is a very large number of people contributing to Z2M their approach works very well; the number of people creating ZHA quirks for unorthodox devices is relatively small. On the other hand you can’t count how many devices work with ZHA - they all should. Sadly any manufacturer can put Zigbee on the box.
In the end it makes no difference. Zigbee is Zigbee, whichever integration you choose. You pick the one that suits your devices and meets your user preferences.
In my opinion this is one off the key reasons to run Z2M instead of ZHA. Every restart of Home Assistant restarts ZHA and hence restarts the Zigbee network. If you have a large number of devices it can take some time for the network to stabilize.
Whilst the OP probably won’t, if you were to use Z2M you can link 2 different Home Assistant instances to the same MQTT server. The benefit of this is allowing you to have a production instance and a development instance. Both instances will have access to all your devices via the MQTT broker and hence you can test changes before pushing them up to production. As a note to anyone else setting this up, add a helper to distinguish between instances and include a check on that in automations you only want to run in production to avoid them running on both instances. Also be aware off any Integrations that use API’s which may have rate limits that get triggered by having multiple instances.
Are you sure?
I genuinely don’t know if this is true or not.
Firstly if you have a network attached coordinator I don’t understand why that would go down.
However even if you have a USB coordinator I can see that the power might be cut so it might go offline - however I don’t know what effect that would have on the Zigbee network - I assume that each device remembers what network it is attached to and has local routing tables for its peers (the network topology is not managed by the coordinator), so I can foresee that the last hop to the coordinator might change but I doubt the rest of the network would be affected.
More practically I have never noticed any instability after restarting HA or the Z2M docker containers.
Beside this again (more like a question): if you have mqtt server running in HA also “goes down”, so in this case ZHA or Z2M doesn’t matter… right?
If you only restart HA nothing goes off power, since HA restart is done inside HAOS (container, VM…as you restart, say, autocad inside windows).However, i guess that it is detached and re-attached to HA. But is that affecting zb network? My understanding of zb network is that zb devices are connected to zb coordinator, not to HA (Ha only communicates with zb coordinator), so if you restart HA zb network is not “destructed”.
Same here (so far…): no problems using ZHA and restarting HA
1 Like
What actually happens during a restart:
- The Zigbee coordinator (USB stick or radio) is reset when HA restarts.
- All Zigbee devices temporarily lose their parent.
- Routers reconnect first.
- End devices (battery sensors) reconnect slowly — sometimes minutes.
- Nothing needs re‑pairing as the devices already know the details.
The larger your Zigbee network the more this will have an affect, since during the reboot routers stop forwarding packets and end devices stop talking. This also means on a larger network you will get a reconnection storm when the co-ordinator get’s back online.
Yes, if you have Z2M as an ‘app’ installed within Home Assistant, then the same thing happens and the MQTT is potentially another layer which also restarts if it is installed as an ‘app’.
Why I would suggest using Z2M and MQTT now is because when you grow your Smart Home a good move is to separate those ‘apps’ which is relatively easy to do by putting them on separate hosts. The real question here is at what point do you make that decision because you would have the pain point of repairing all your devices.
However, you can make your own choice based on:
Zigbee2MQTT — Pros
- Best device support, especially Tuya / non‑standard devices
- More features exposed (attributes, controls, reporting)
- Faster updates (community converters)
- Excellent debugging (logs, routing tables, raw frames)
- Coordinator stays online if run outside HA
- More control over mesh behaviour
Zigbee2MQTT — Cons
- Add‑on version restarts with HA → no uptime advantage
- More moving parts (MQTT broker, external service)
- More configuration overhead
- UI less integrated than ZHA
ZHA — Pros
- Native, simple, zero‑maintenance
- No external services needed
- Good for standard Zigbee devices
- Cleanest HA integration
- Fewer components to break
ZHA — Cons
- Coordinator restarts with HA → mesh pauses
- Slower device support for weird/Tuya devices
- Less debugging visibility
- Fewer exposed features per device
2 Likes
There is a critical detail missing from your explanation, specifically how long the timeouts are - i.e. if the restart is quick the routers may not even notice that the coordinator is offline.
The lowest number I saw was 3 checkins occurring every 15 seconds (so totaling 45 seconds) however I have also seen some posts saying that it take longer than that - I wasn’t able to identify a conclusive answer.
I think it’s only the devices connected directly to the coordinator that lose their parent - I believe other devices and routers that are parented to a different router would still have their parent / be able to continue to route.
If it’s less than a twenty minute downtime it won’t matter the child device won’t go into panic seek until it’s parent is gone for the timeout period - generally 20 minutes. This is why you can force a node to seek a (properly behaving device according to the spec) parent by shutting down its parent for thirty minutes…
The biggest difference is of the software runs in memory process with HA or not. And if the reboot takes less than twenty because prev. It won’'t really matter… Shut it off for MORE though. Then first hop panic hunts.
SJ20035 → thanks for explanation!
Personally i prefer wifi over zb anyway… can’t say why… i guess because i started with esphome modules. I only have zb network because sonoff trv’s are zb only, all other devices are wifi (50+) and BLE (10-15). I did connect shelly e-ink thermometers to ZB, but only “because i can” 
… they have BLE, too, so HA uses BLE connection, ZB is just … let’s say “a spare”…
But, it’s just a personal choice, i guess.
1 Like
I have some Govee lights and stuff I want to add as well.
They are Matter-over-Wifi and Bluetooth compatible.
No there’s an integration if I set the device(s) to be LAN control enabled with API, I can control them with HA.
With LAN control, some very basic scenes are also can be selected along with colors, but not Dreamview or Complicated things. Also, I can just enable them in the Govee APP and they’ll show up in HA, no need to add 1by1.
Now if I connect the devices directly to HA through Matter, they become even more limited. ON-OFF and some color. No scenes, nothing at all.
There might be some blueprint or tinkering that would help me out, but for many devices to do it 1by1 would be a mess.
I just read about Govee2MQTT, which they say enables more complicated features on the devices as well (similarly like the ZHA vs. Z2M).
I didn’t deep dive into all this MQTT, docker, blablabla yet, but I guess it’s not very hard either.
My question is:
Do I need a separate hardware for any of the MQTT stuff? Like a server running somewhere? Or can I do all of this on my HA green (which will run non stop anyway).
My other question is:
If I set everything up (docker, whatever is needed) for MQTT(s) to work, can I use the same stuff for both integrations, or do I have to have 2 separate ones?
I know it might be a very stupid question, but for Zigbee2MQTT and Govee2MQTT? Like I would need 2 separate antenna for ZHA and Z2M, similarly 2 separate servers?
Thanks all.
I have no idea why the above answer replied to that quote 
Also worth to mention, that controlling every single function of Govee stuff is not a must, as I can control them via its app through Bluetooth if I want.
A lot of the replies here go a lot into technical detail, but in my opinion, the most important thing is to just get started first, and not worry too much about what the best choice is. Picking the ‘wrong’ option and getting started is much better than not getting started at all because you are unsure what to pick.
When I got into home automation, I definitely picked some options that were… well, not wrong per se, but that I wouldn’t have picked if I’d have do it a second time. But it got me into home automation, I learned loads, and to be honest, even fixing some of my oopsies were fun (and frustrating at the same time!).
The home assistant green is great hardware when you’re getting started, and I think it’s a great choice because it takes away a lot of the barrier to entry by providing you with a device that is easy to get started with.
Now, as for whether to pick z2m or ZHA - personally I would recommend you to go with ZHA just so you get started, and you can always switch later. Yes, it will be a bit more work that way, but it’s not the end of the world.
However, since you mentioned wanting to use some Govee stuff, and are considering govee2mqtt, that does change things a little. If you do decide you want to use govee2mqtt, you might as well opt to use zigbee2mqtt since I expect z2m to be of similar (or lower) complexity relative to govee2mqtt. Both are available as add-ons for home assistant os, so you shouldn’t need to use docker I think.
1 Like