Short Answer: Start With ZHA Unless You Already Know Why You Need Zigbee2MQTT

For most homeowners building a reliable local Zigbee network in Home Assistant, ZHA is the safer default. It is built into Home Assistant, can auto-discover supported coordinators, exposes a native Zigbee dashboard, and now sits more clearly inside Home Assistant's protocol settings.

Zigbee2MQTT becomes the better first choice when you want a separate Zigbee layer, already run MQTT, need the broadest possible device catalog, or expect to lean on device-specific exposes and troubleshooting tools. In other words: ZHA wins on simplicity, Zigbee2MQTT wins on flexibility.

Tara's default: if the goal is a boring, spouse-safe house with fewer moving parts, start with ZHA. Reach for Zigbee2MQTT only when you can name the exact advantage before you install it.

Why This Question Keeps Coming Up

This is one of the recurring Home Assistant questions because both answers are defensible. A November 23, 2024 Home Assistant Community thread about converting from ZHA to Zigbee2MQTT framed the real tension well: people start on ZHA because it is built in and works, then later see feature-rich Zigbee2MQTT setups and wonder if they chose the wrong foundation.

A recent Reddit thread asked whether Zigbee2MQTT is still the clear winner or whether ZHA has caught up. The replies split along the same lines: ZHA is easy, native, and good enough for many homes; Zigbee2MQTT is often chosen for broader device support, looser coupling to Home Assistant, and more power-user controls.

That is why this choice matters early. Once your Zigbee network is full of in-wall modules, battery sensors, and automations, changing stacks later stops being a fun experiment and starts becoming labor.

Diagram-style view of smart home protocols managed by a local hub
The real decision is not just “which integration works.” It is which operational model you want to own after the house fills up with devices.

What Changed Recently

If your mental model is still “ZHA is basic and Zigbee2MQTT is for real users,” update it.

  • January 7, 2026: Home Assistant 2026.1 made protocol dashboards easier to find, including Zigbee. That matters because ZHA is now surfaced more like core infrastructure and less like a hidden integration.
  • ZHA today: the official docs include OTA firmware updates, groups, binding, network topology visualization, coordinator backups, and migration to a new Zigbee adapter inside ZHA.
  • Zigbee2MQTT today: the current getting-started guide includes a first-run onboarding flow instead of assuming hand-edited YAML from minute one, and its Home Assistant integration still uses MQTT discovery to drop devices cleanly into Home Assistant's registry.

So the old caricatures are out of date. The real gap in 2026 is not that one is modern and the other is primitive. The gap is that one is simpler and more native, while the other is broader and more modular.

ZHA vs Zigbee2MQTT Side by Side

Category ZHA Zigbee2MQTT
Setup overhead Built into Home Assistant, can be auto-discovered, and configured from Settings > Devices & Services. Needs Zigbee2MQTT itself plus an MQTT broker. The docs now include onboarding, but it is still another service to run.
Home Assistant feel Native protocol dashboard, native device presentation, native repair flow. Integrates back into Home Assistant through MQTT discovery and the device registry, but you still maintain the Zigbee2MQTT frontend and MQTT path.
Device support edge cases Supports many off-the-shelf devices directly, but unusual devices may need a new ZHA quirk or a device-support request. Currently documents support for 5,473 devices from 577 vendors and has a documented path for temporary external converters when a device is not yet fully supported.
Backups and adapter changes Home Assistant added ZHA network backups and migration between coordinators back in 2022.9, and the current ZHA docs still document that path. Coordinator backups depend on adapter family, and the docs warn that some adapter migrations may require repairing devices.
Power-user controls Supports OTA, groups, binding, topology view, and troubleshooting inside Home Assistant. Provides a dedicated frontend plus documented areas for groups, binding, OTA, exposes, health, network maps, and device-specific configuration overrides.
Architecture Best when Home Assistant is the one place you want to manage the home. Best when you want Zigbee to stay more independent from Home Assistant and are comfortable with MQTT as the integration layer.

When ZHA Is the Right Answer

ZHA is usually the correct answer if you are optimizing for reliability per hour of effort.

  • You want fewer moving parts. No separate Zigbee frontend is required, and you do not need MQTT just to get Zigbee devices into Home Assistant.
  • You value the native Home Assistant experience. ZHA lives in the same place as the rest of Home Assistant's protocol and hardware settings.
  • You want the cleanest backup and coordinator-migration story. Home Assistant has published and maintained that path inside ZHA for years.
  • Your device mix is boring in the best way. If you mostly buy mainstream Zigbee devices and prefer fewer compatibility experiments, ZHA is hard to beat.

That does not make ZHA “basic.” It makes it opinionated in the direction most houses benefit from.

When Zigbee2MQTT Is Worth It

Zigbee2MQTT is the better first choice when your priorities are broader than “keep Zigbee simple.”

  • You already want MQTT anyway. If your Home Assistant setup already uses MQTT for other infrastructure, the extra dependency stops being a special cost.
  • You buy uncommon or vendor-weird devices. Zigbee2MQTT's supported-device catalog is enormous, and its external-converter path makes unsupported devices less final.
  • You want a dedicated Zigbee control plane. Its frontend, exposes model, and configuration overrides are attractive if you enjoy seeing and tuning more of what a device can actually do.
  • You care about decoupling. Some advanced users prefer that Home Assistant can restart without also being the thing that directly owns the Zigbee network stack.

This is where Zigbee2MQTT earns its reputation. It is not just “more devices.” It is a different operating style.

The Expensive Part Is Switching Later

The biggest mistake is not choosing ZHA or Zigbee2MQTT. The biggest mistake is choosing one casually while assuming the other can be adopted later without pain.

The Home Assistant forum thread that drove this article includes a user staring at a 90-plus-device Zigbee network and hesitating to move because rebuilding it would be miserable. The newer GitHub discussion showing a successful ZHA-to-Zigbee2MQTT migration without re-pairing proves that advanced migration work is possible, but it also proves the point: this is not the sort of clean homeowner workflow you should bank on.

  • If you are still in the first 10 to 20 devices, test early. It is the cheapest moment to decide.
  • If you already have many hidden or physically awkward devices, treat migration as a project.
  • If you want to run both, use separate coordinators and separate meshes. A Zigbee network still gets one coordinator, and two stacks mean two networks to manage.

A Practical Recommendation for Real Houses

If you are helping a technically curious homeowner and want an answer that will still look sane six months later, use this rule:

  • Start with ZHA when the home values low maintenance over lab-grade flexibility.
  • Start with Zigbee2MQTT when you already know you care about MQTT, oddball device support, or deeper device tuning more than you care about native simplicity.

There is nothing prestigious about extra moving parts. There is also nothing wrong with choosing the more flexible tool when you actually need its flexibility. The failure mode is picking the more complex stack because internet culture makes it sound mandatory.

Tara's Take

Tara-style installs try to keep the home local, recoverable, and understandable by somebody other than the person who first built it. That pushes us toward ZHA as the default for many installations, especially when the device plan is already curated and boring on purpose.

Zigbee2MQTT is still a strong choice when the home deliberately needs its strengths. But if your real goal is “I want the lights, sensors, remotes, and locks to keep working without becoming my second job,” simpler infrastructure usually wins.

If this decision is part of a bigger Home Assistant build, these pages cover the next choices that usually follow it.

FAQ

Which is better for a first Home Assistant Zigbee network?

For most homeowners, ZHA. It is built in, easier to explain, easier to hand off, and now easier to find in Home Assistant's settings. Choose Zigbee2MQTT first only when its advantages are already part of the plan.

Do I need MQTT to use Zigbee2MQTT?

Yes. Zigbee2MQTT's docs say the host should have an MQTT broker installed, and its Home Assistant integration uses MQTT discovery to add devices into Home Assistant.

Can I run ZHA and Zigbee2MQTT at the same time?

Yes, but only on separate coordinators and separate Zigbee meshes. That can be useful for testing, but it also means two networks, two channels, and two troubleshooting surfaces.

Can I switch from ZHA to Zigbee2MQTT later without re-pairing everything?

Maybe, but do not plan your house around that “maybe.” Advanced community migrations exist, yet they are manual enough that most homeowners should assume real migration work, testing, and cleanup.

Does ZHA support OTA updates, groups, binding, and coordinator migration?

Yes. The official ZHA documentation includes OTA updates, Zigbee groups, binding, topology mapping, backups, and adapter migration inside ZHA.