I would not choose a Zigbee integration from a feature checklist alone. The right choice is the one you can recover at 2 a.m., after a coordinator firmware update or a dead battery has made half the house look unavailable.
I have used both ZHA and Zigbee2MQTT, and the practical difference is less dramatic than the community arguments suggest. Both can run a dependable mesh. Both benefit from a well-placed coordinator, powered routers, a sensible channel, and a backup that you have actually tested. The important difference is where each system puts complexity: ZHA keeps more of it inside Home Assistant, while Zigbee2MQTT exposes more knobs and separates the radio service from the automation platform.
What ZHA gets right
ZHA is the natural starting point for a Home Assistant installation. Add the integration, select a supported coordinator, and the devices appear in the same system that already contains your automations, dashboards, and backups. There is no MQTT broker to install and no second web interface to learn.
That simplicity matters. A smart home is not a lab benchmark. It is a collection of switches, leak sensors, buttons, and lights that other people in the house expect to work. Every additional service creates another update path and another log to check when something stops responding. ZHA keeps the ordinary path short.
ZHA also feels coherent when you use Home Assistant’s device and entity model. Pairing, renaming, areas, automation triggers, and diagnostics live in one place. New users can learn the system without first understanding topics, discovery messages, and broker credentials.
The tradeoff is that ZHA sometimes makes advanced behavior less obvious. A device may be supported, but an unusual cluster or configuration option may not be exposed in the UI. You can often solve that with quirks, custom handlers, or an issue report, but the solution can be more Home Assistant-specific than a Zigbee2MQTT converter.
Where Zigbee2MQTT earns its complexity
Zigbee2MQTT is compelling when device compatibility is your first concern. Its catalog and converter model give you detailed control over what a device exposes. When a vendor adds a new button action, power measurement field, or calibration option, Zigbee2MQTT users often see it quickly because the device definition is explicit and community-maintained.
The MQTT boundary is useful too. The Zigbee service can run beside Home Assistant, on another machine, or in a container. Home Assistant consumes the published state, but the radio is not conceptually trapped inside the automation server. That is attractive if you rebuild Home Assistant often, run multiple consumers, or want the same broker to carry other local systems.
You pay for that flexibility with more moving parts. The broker must stay available. Discovery must be configured correctly. Credentials, network paths, add-on updates, and retained messages are now part of the recovery story. None of these is difficult, but they are real.
I would pick Zigbee2MQTT when I have a device that ZHA does not expose properly, when I want precise device controls, or when I already operate MQTT for other services. I would not install it merely because a forum says serious users do.
Device support is not a permanent score
Comparisons that declare one stack the winner on device support age badly. The useful question is whether the exact devices you plan to buy work today, with the coordinator and firmware you intend to run.
Check the integration’s current device list before ordering a box of sensors. Search the exact model number, not just the brand. A manufacturer may sell several revisions under a nearly identical name, and the regional version may use a different radio or expose different clusters.
This matters especially for cheap sensors and buttons. The purchase price is low, but replacing ten paired devices after discovering a compatibility gap is expensive in time. I keep a shortlist of models with clear support, then buy one sample before standardizing on a new vendor.
For a first network, the SONOFF Zigbee Dongle Plus-E on SONOFF or on Amazon is a sensible baseline. Put it on a USB 2.0 extension cable, away from the host and USB 3 devices. Radio placement will usually matter more than the choice between the two integrations.
Backups are the deciding feature
The best integration is the one whose backup you understand before the mesh fails. Export the integration configuration and the coordinator network backup. Store them somewhere that survives a failed Home Assistant disk. A backup on the same tiny computer as the live system is not a recovery plan.
ZHA and Zigbee2MQTT do not present identical backup workflows. The coordinator radio stores network information, while the integration stores device and application configuration. You need both layers. Write down the coordinator model, firmware, Zigbee channel, network key policy, and whether the backup is encrypted. Future-you should not have to infer the architecture from a dead dashboard.
I also keep a plain inventory of important devices. It includes room, friendly name, model number, battery type, and the automation that depends on it. That document is boring until a migration loses a sleepy contact sensor and you need to know which door it protected.
The migration trap
Switching stacks is not a weekend configuration toggle. Sometimes a coordinator backup lets you preserve network identity. Sometimes the radio family, firmware, or backup format makes that impossible. Even when the devices remain joined, names, entities, triggers, and automations may need cleanup.
Do a small migration first. Pair or move a spare plug and one battery sensor. Test state changes, battery reporting, and an automation that uses the device. Leave the production integration alone while you learn the new path. If you need to move the main network, make a checklist and move one room or device class at a time.
Do not change the coordinator, integration, channel, router layout, and firmware on the same afternoon. If the result is worse, you will not know which change caused it. A stable mesh is more valuable than a theoretically optimal one.
Networking and coordinator placement still matter
Neither integration fixes a radio hidden behind a server. Place the coordinator in open air, away from metal racks and USB 3 storage. If the best location is across the house from Home Assistant, an Ethernet coordinator can be a better architectural choice. My Ethernet Zigbee coordinator guide covers that tradeoff.
Use powered Zigbee devices as routers. A mains-powered plug or switch in the right room often improves a mesh more than replacing an otherwise adequate coordinator. Battery devices do not route traffic, no matter how expensive the sensor is.
Channel planning deserves attention, but it is not the first lever. Start with placement and routers. Then compare Zigbee behavior against nearby Wi-Fi use. Change one thing, allow sleepy devices time to report, and judge missed events and unavailable time rather than one attractive network-map screenshot.
My choice for three common setups
For a first Home Assistant house with ordinary lights, buttons, and sensors, I would start with ZHA. It has the shortest path from coordinator to automation, and the reduced service count is a feature. I would keep a compatibility check open for every unusual device before buying multiples.
For a house with mixed brands, unusual remotes, or a separate MQTT deployment, I would start with Zigbee2MQTT. The additional interface is worth it when the device catalog and exposed controls matter more than having one integrated screen.
For an existing stable system, I would not migrate for philosophical reasons. If ZHA works, keep ZHA. If Zigbee2MQTT works, keep Zigbee2MQTT. Use the time to improve backups, coordinator placement, router coverage, and monitoring. Those changes help either stack.
The Bottom Line
ZHA is my default recommendation for a new Home Assistant installation because it keeps the system understandable and reduces the number of services that can fail. Zigbee2MQTT is the better choice when exact device support, detailed controls, or a portable MQTT architecture justify the extra moving parts.
Choose based on the devices and recovery plan you actually have, not on which project wins a forum argument. Put the coordinator somewhere the radio works, add powered routers where the mesh needs them, and make a backup before you experiment. A boring Zigbee network is a successful Zigbee network.
One final practical point: keep the integration choice separate from the brand of sensor. A good Aqara, IKEA, Philips Hue, or SONOFF device can be reliable under either stack when the exact model is supported. If a device behaves badly, verify the model and route before rewriting the entire system. Most household failures are local problems, not proof that the other integration is universally superior.
When I troubleshoot a Zigbee issue, I start at the edge: does the device have power, is it awake, and is the signal path plausible? Only after that do I inspect the integration logs. This order prevents a missing battery report from turning into an unnecessary coordinator migration. It also keeps the recommendation honest: software can expose a device, but it cannot create a radio route through concrete and metal.