Zigbee2MQTT vs ZHA in Home Assistant: Which Fits Your Setup?
Two supported Zigbee stacks, one coordinator, and a decision that is mostly about how much you want to run. Here is the short answer, a six-question fit check, and the order to do things in if you do switch.
The short answer
Start from what already works. If ZHA is stable and every device answers after a restart, stay on ZHA — placement, channel and backups come before any stack change. Move to Zigbee2MQTT when you already run MQTT, when you want the Zigbee layer to live outside Home Assistant, or when one specific device is handled better there.
Six questions before you switch stacks
Answer in order. The first question matters most: a network that already works is the thing you are risking.
Is your current network stable — does every device still answer after a Home Assistant restart?
Are you already running an MQTT broker for something else?
Do Zigbee devices ever need to reach something other than Home Assistant?
Is one specific device behaving badly today?
Do you want to update the Zigbee stack on its own schedule?
Is your coordinator one whose firmware only one of the two stacks documents?
ZHA and Zigbee2MQTT, side by side
Neither column is a verdict. The right-hand column is the part that decides most setups.
| Dimension | ZHA | Zigbee2MQTT | Check this before deciding |
|---|---|---|---|
| Where it runs | An integration inside Home Assistant | A separate application that hands devices to Home Assistant over MQTT | Whether you want to run and update one more service |
| Extra pieces to run | Nothing beyond Home Assistant | An MQTT broker plus the Zigbee2MQTT application | Whether an MQTT broker is already part of your setup |
| Where you configure it | Home Assistant's own interface | Its own interface and configuration | Which one you will actually keep tidy six months from now |
| Device handling | Handled inside Home Assistant | Handled by the project's own converters | Look your exact model up in both device lists |
| Update rhythm | Follows the Home Assistant release you install | Ships on its own schedule | Whether you want the Zigbee stack updated independently of Home Assistant |
| Coordinator firmware | Documented per coordinator | Documented per coordinator | Read your coordinator's manual — the two stacks can expect different firmware |
| Backup and restore | Covered by your Home Assistant backups | Your own configuration, plus a coordinator network backup | Confirm what your backup actually contains before you rely on it |
| What it does not fix | Interference, distance, and a poorly placed stick | Interference, distance, and a poorly placed stick | Nothing on this page replaces placement work |
Situation → what we would do
Matched to the state of your network, not to a preference for either project.
| Your situation | What we would do | Why |
|---|---|---|
| Everything works and you are only reading up | Stay on ZHA | A working mesh is the asset. Placement beats a stack swap. |
| You already run MQTT for something else | Zigbee2MQTT is the shorter path | The extra moving part is already in your stack. |
| One device is poorly exposed | Check that model in both device lists first | A single-device gap is worth fixing before you move a whole network. |
| 30+ devices with occasional dropouts | Audit placement and channel before the stack | Our own 46-device network runs on one coordinator, and moving the stick has solved more complaints than changing software. |
| You want the Zigbee layer to outlive a Home Assistant rebuild | Zigbee2MQTT | The Zigbee layer lives in its own service, separate from the Home Assistant install. |
| You do not want to maintain another service | ZHA | Fewer moving parts to install, update, back up and monitor. |
If you do switch, do it in this order
Every step is reversible until step 5. After that, the old network is the thing you are giving up.
- Write down what you have. — Coordinator model, firmware version, Zigbee channel, and a list of every device with its model name. Do this before you touch anything; you will want it if you roll back.
- Take a backup and confirm it exists. — A Home Assistant backup, and a coordinator network backup if your coordinator's tooling offers one. Find the file afterwards so you know it is real.
- Check every device model against the target stack's device list. — If a model is not listed, assume it is the one that will not work, and decide now whether that is acceptable.
- Check what firmware your coordinator's manual names for the target stack. — Stop here if the manual does not cover your exact coordinator and firmware combination. Ask the project's support channel before going further.
- Stand up the new pieces before you unpair anything. — For Zigbee2MQTT: the MQTT broker first, then the application, then a single test device. The old network keeps running while you do this.
- Move one device. — Pick a mains-powered device near the coordinator. Join it to the new stack and leave it for a day. If it drops, fix placement and channel before adding anything else.
- Move the network in batches. — A few devices at a time. Confirm each batch still answers after a restart before starting the next one.
- Keep the old setup until the new one has run a full week. — That week should include a Home Assistant restart and at least one coordinator power cycle. Only then retire the old network.
Mistakes that cost a weekend
All six of these are more common than a genuine stack limitation.
Migrating a network that already works
If every device answers and restarts are boring, the stack is not your problem.
Blaming the stack for interference
USB 3.0 ports and busy 2.4 GHz Wi-Fi sit right on top of Zigbee. Move the stick before you move the software.
Unpairing first and checking later
Verify your exact device models in the target stack's list while the old network is still standing.
Running two Zigbee networks on the same channel
If you keep both stacks live while you migrate, give each its own coordinator radio and keep their channels apart. Two stacks sharing one coordinator is not a configuration to attempt.
Skipping the backup because the move looks simple
The simple ones are exactly where it gets skipped.
Copying someone else's channel number
Their 2.4 GHz environment is not yours. Scan your own before you pick.
Edge cases worth knowing about
These are the ones that turn a tidy migration into an evening.
Before you flash anything
Coordinator firmware is the one step on this page that can leave hardware unusable. Flash only firmware that your coordinator's official manual names for your exact model, using the vendor's documented tool. If the manual does not cover your combination, stop and ask the project's support channel or the coordinator vendor first. Nothing on this page replaces your device's official documentation, and if you are unsure at any point, stop and consult the manufacturer's instructions or a qualified professional.
Questions we get about the switch
Can I run ZHA and Zigbee2MQTT at the same time?
Will I have to re-pair every device when I switch?
Which one is more reliable?
Do I need MQTT if I use ZHA?
Does device count decide it?
Can I keep my current coordinator?
Pick the stack, then copy a setup that already runs
Our guides come from a live 46-device Zigbee network at home: choosing a coordinator, migrating a network to new hardware, and the placement fixes that resolve most "device unavailable" complaints.