Short answer: Choose Zigbee2MQTT when your network is more than a handful of devices, spans several brands, or you want the detailed network map and MQTT decoupling that come with it. Choose ZHA when you want the absolute minimum: one Home Assistant install, no extra add-ons, pairing that just works. Both are free, both are fully local, and both run on the same radios — including the Sonoff ZBDongle-E we use. On paper the difference is feature depth; in practice it’s about how much of the mesh you want to see and control.

What we run

Our home network runs 46 Zigbee devices on a Sonoff ZBDongle-E, plugged into the Home Assistant box over a 1 m USB 2.0 extension cable, and the software layer is Zigbee2MQTT. That combination has survived a full coordinator migration without re-pairing a single device, and the Z2M network map is how we locate dead zones before moving a plug or a sensor.

One honesty note before the comparison: we evaluate Zigbee2MQTT from years of daily production use, and ZHA from the official documentation, release notes and the community threads linked below — we don’t pretend we ran both stacks side by side for years.

What they both do

Both stacks are the software that sits between Home Assistant and the Zigbee radio. Both are local-first — no cloud, no vendor account. Both expose normal entities to Home Assistant, support Zigbee 3.0, and work with the same coordinators, whether that’s a USB stick or a network box like the SLZB-06.

The difference is architecture. ZHA (Zigbee Home Automation) is an integration inside Home Assistant core: install Home Assistant and you already have it. Zigbee2MQTT is a separate service that bridges the coordinator to an MQTT broker (Home Assistant has a built-in MQTT integration), so it runs as an add-on — or standalone on another machine entirely.

Zigbee2MQTT — for control

The arguments that push most larger networks to Z2M:

  • Broadest device support. Z2M’s device database is bigger and gets new and fringe hardware faster. This is where quirky brands — Aqara above all — shine, and it’s the reason we run our Aqara door sensors through it without drama.
  • MQTT decoupling. Home Assistant can restart, upgrade or crash without breaking pairing state, because the Zigbee network lives in its own process. If Home Assistant is down, the mesh keeps routing.
  • A real network map. The Z2M web frontend shows every device and its parent. We used it to find the exact dead zones in our range fix guide — that level of visibility is simply not part of ZHA.
  • Per-device control. Bindings, groups, advanced reporting, per-device config that matters for battery-powered sensors and thermostats.

The cost: more moving parts. An add-on, an MQTT broker, a configuration layer, and a mental model of what runs where. That’s fine for a tinkerer and friction for everyone else.

ZHA — for simplicity

The counter-argument, and it’s a strong one:

  • Zero add-ons. ZHA is part of Home Assistant core. One install, one update track, no MQTT broker to maintain.
  • Simplified pairing. “Add device” just works for mainstream hardware, and the setup flow hides the Zigbee nerdery behind sensible defaults.
  • Plenty for a normal home. For a 10–25 device network of mainstream brands — IKEA, Sonoff basics, Philips Hue — ZHA genuinely covers almost everything, and many people on the forums run it happily for years.

The trade-offs mirror Z2M’s strengths: device support lags for exotic hardware, there is no equivalent of the Z2M web map, and per-device tuning options are fewer. Historically, new device quirks have also taken longer to land in ZHA than in Z2M.

Which one should you pick?

Use the decision rule, not the hype:

  • 1–20 devices, mainstream brands, want zero maintenance → ZHA. Install Home Assistant, pair, done.
  • 20+ devices, mixed brands, Aqara / thermostats / lots of sensors → Zigbee2MQTT. You will want the device coverage and the map.
  • Home Assistant inside a VM or Proxmox, coordinator on the network → both work; we’d still pick Z2M, because then the mesh keeps routing even when the VM reboots. Pair it with an SMLIGHT SLZB-06 over PoE and the Zigbee network stops caring about your server’s uptime entirely.
Criterion ZHA Zigbee2MQTT
Setup effort None (built-in) Add-on + MQTT broker
Device support Good, mainstream Larger, faster for new/fringe
Network visibility Basic Web map + per-device stats
Survives HA restarts Reconnects Network fully independent
Best for Small/medium homes Larger, mixed, power users

The honest caveats

  • Neither stack fixes radio physics. If devices drop because of bad placement or low router density, switching software changes nothing. See our range guide for the actual fix.
  • Switching between ZHA and Z2M means re-pairing every device. Don’t treat it as a free migration. (Switching coordinators within Z2M is the exception — that’s a no-re-pair move, see our migration guide.)
  • “Stability” threads go both ways. There are community threads reporting issues with each stack (ZHA vs Z2M: which is most stable?, ZHA vs Zigbee2MQTT — pros and cons for conversion). In our experience, coordinator placement, firmware and USB interference cause more real-world pain than the software choice.
  • Start small either way. If you already run MQTT for other things, Z2M costs you almost nothing extra; if you don’t, ZHA is one less service to maintain.

Bottom line

For most starter homes, ZHA is the sensible default — it’s built in, it works, and you can always migrate later. The moment your network outgrows it — more devices, weird brands, a dead zone you can’t find — Zigbee2MQTT earns its extra moving parts with a bigger device database, MQTT decoupling and a network map that actually shows you what’s wrong. Both run perfectly on the ZBDongle-E; the choice is between simplicity and control, and we’ve now told you exactly what each one costs.

Prices and availability checked 2026-09-25. Commissions are earned from qualifying purchases — see our affiliate disclosure.