120 Zigbee Devices Later: My Move from Zigbee2MQTT to ZHA

I have recently started a new project in my Home Assistant setup that I have called “Better Zigbee”.

The goal is not necessarily to replace something that was broken. In fact, my previous Zigbee setup using Zigbee2MQTT had been working very well. It was stable, reliable, and had served my smart home for a long time.

Instead, I wanted to explore what would happen if I moved closer to the native Home Assistant ecosystem by replacing Zigbee2MQTT with ZHA.

At the same time, I decided to take the opportunity to experiment with a different approach to the Zigbee coordinator. Instead of continuing with my previous setup, I moved to a Ziggurat-based coordinator using the Home Assistant ZBT-2 as the radio hardware.

The result so far? I have now migrated approximately 120 Zigbee devices, one device at a time — and the biggest surprise has been how little the rest of my smart home has noticed.

And surprisingly, the process has been much easier than I expected.

Why Move Away from Zigbee2MQTT?

The short answer is: I didn’t really have to.

Zigbee2MQTT had been working well for me. There was no major stability problem that forced me to migrate, and I wasn’t experiencing a network that constantly needed troubleshooting.

This was more of an experiment.

I have used Home Assistant for many years, and I have gradually become more interested in reducing the number of separate layers between my devices and Home Assistant itself.

Zigbee2MQTT is an excellent project, and I have nothing against it. But with Home Assistant’s own ZHA integration becoming increasingly mature, I wanted to see what a more native setup would feel like.

The project became even more interesting when I started looking at Ziggurat, a newer Zigbee coordinator approach within the broader zigpy ecosystem.

So rather than simply switching:

Zigbee2MQTT → ZHA

I effectively changed the architecture to:

Zigbee2MQTT + previous coordinator → ZHA + Ziggurat + ZBT-2 radio hardware

That made this more than just an integration migration.

It became a small rebuild of my Zigbee infrastructure.

No Migration Button

One of the biggest challenges is also the most obvious one: there is no magic “Move Everything to ZHA” button.

At least, not one that I could use to migrate my entire network while keeping everything exactly as it was.

So I decided to take the safest approach.

One device at a time.

The process was essentially:

1. Remove the device from Zigbee2MQTT.
2. Pair it with the new ZHA network.
3. Check that the device and entities were correctly identified.
4. Rename or adjust anything necessary.
5. Test the device.
6. Check the relevant Home Assistant automations.
7. Move on to the next device.

With around 120 devices, this is obviously not something you finish in ten minutes.

But it does have one major advantage.

If something goes wrong, you only have one device to troubleshoot.

There is no big-bang migration where suddenly 120 devices disappear and you have to figure out what happened.

I could migrate a few devices, test the network, and continue when everything looked good.

This also meant that the house continued to function throughout the migration.

Lights still worked.

Automations still ran.

Sensors continued to provide data.

And gradually, more and more of the old Zigbee network disappeared while the new one grew.

The Room Matters More Than the Device

One of the things I was most curious about was what would happen to my Home Assistant automations.

I have a fairly large number of automations built around my smart home devices.

Lights are controlled by motion sensors.

Heating depends on temperature sensors.

Doors and windows trigger different actions.

Buttons control scenes.

And several devices are involved in more complex automations.

At first glance, moving 120 devices from one Zigbee platform to another might sound like a massive automation migration project.

In reality, it was surprisingly easy.

And this is where Home Assistant’s newer approach to automations really makes a difference.

I have been testing the new automation setup while it was still available through the Labs features, so much of my automation setup was already built around the concepts described in the Home Assistant 2026.7 release.

The most important change, at least from my perspective, is that the automation logic is increasingly about the room and the role of a device, rather than the underlying technology or the exact physical device.

Think about a simple example.

I have a motion sensor in my hallway.

The automation doesn’t really need to know whether that sensor is connected through:

• Zigbee2MQTT
• ZHA
• Z-Wave
• Matter
• Thread
• Bluetooth

It simply needs to know that it is a motion sensor in the hallway.

That is a very different way of thinking about smart home automation.

Instead of building automation logic around a specific physical device, the automation can focus on what the device is and where it belongs.

For example:

Hallway
├── Motion sensor
├── Ceiling light
└── Temperature sensor

The automation can then work with the concept of the hallway and the devices that belong to it.

When I migrate a motion sensor from Zigbee2MQTT to ZHA, the underlying technology changes.

The device changes.

The integration changes.

The Zigbee network changes.

But the device is still a motion sensor.

And once I assign the newly migrated device to the correct Home Assistant area, the rest of the smart home logic can continue to work.

This means that my migration process has often been as simple as:

Remove device from Zigbee2MQTT
        ↓
Pair device with ZHA
        ↓
Assign device to the correct Area
        ↓
Check device classification
        ↓
Done

There is no need to go through dozens of automations and replace every reference to the old Zigbee2MQTT device.

The automation is no longer tightly coupled to the technology that happens to provide the sensor.

This is a major advantage when building a smart home that is intended to evolve over time.

The Room Matters More Than the Device

This is perhaps the biggest lesson I have taken away from the migration.

Imagine that I have a motion sensor in the hallway.

Today, it might be a Zigbee device connected through Zigbee2MQTT.

Tomorrow, I might replace it with a ZHA device.

Next year, I might replace it with a Z-Wave or Matter sensor.

From the perspective of the smart home, none of that should really matter.

The hallway still needs to know when there is movement.

The lights still need to turn on.

The heating system might still need to know that the room is occupied.

The technology underneath is simply the transport layer.

This makes the smart home much more modular.

I can replace individual devices without having to rethink the entire automation architecture.

For me, this became very obvious during the migration.

I could move a sensor from Zigbee2MQTT to ZHA, assign it to the correct room, and suddenly the new sensor simply became part of the existing smart home.

The room didn’t care that I had changed the technology underneath.

And neither did the automation.

That made migrating 120 devices considerably less intimidating.

Why This Matters

This is also one of the reasons I think it is worth spending time building automations around Home Assistant’s higher-level concepts.

If your automations are tightly connected to specific devices and integrations, changing your smart home infrastructure can become painful.

But if your automations are built around concepts such as:

• Areas
• Device classes
• Entities
• Occupancy
• Motion
• Temperature
• Light levels

then the underlying hardware becomes much less important.

A motion sensor is a motion sensor.

A light is a light.

A temperature sensor is a temperature sensor.

It doesn’t necessarily matter whether the data comes from Zigbee, Z-Wave, Matter, Thread or another integration.

This abstraction was one of the reasons the migration from Zigbee2MQTT to ZHA turned out to be so straightforward on the automation side.

The physical devices changed.

The Zigbee integration changed.

The coordinator changed.

But the smart home itself didn’t really have to change.

That, in my opinion, is exactly how a good smart home platform should work.

Does ZHA Feel Faster?

This is where things get interesting.

After moving a significant number of devices to ZHA and the new Ziggurat-based setup, one of the first things I noticed was responsiveness.

The lights seem to react faster.

Not dramatically faster.

Not in a way that I have measured with a stopwatch.

But fast enough that I noticed it while using the system normally.

When I press a button or trigger an automation, the lights seem to respond almost immediately.

This is, however, purely my experience.

I have not performed a controlled benchmark comparing the old and new networks under identical conditions.

There are simply too many variables involved.

The network topology has changed.

The coordinator setup has changed.

The Zigbee integration has changed.

The number of devices and routes has changed during the migration.

And the overall Zigbee mesh is still settling into its new configuration.

So I am not going to claim that ZHA is objectively faster than Zigbee2MQTT based on my experience.

But I can say this:

The new setup feels fast.

And after running Zigbee2MQTT for a long time, I believe I would notice if the new setup felt significantly worse.

So far, it doesn’t.

If anything, the opposite is true.

120 Devices and a New Zigbee Mesh

The most interesting part of the migration has probably been watching the new Zigbee network develop.

With approximately 120 devices now migrated, the network is becoming large enough to give me a good indication of how the new setup behaves under normal conditions.

Most of my devices are mains-powered Zigbee devices, including smart lights and other permanently powered equipment.

These devices also help build the Zigbee mesh by acting as routers.

I have also moved battery-powered sensors and other end devices across to ZHA.

The migration process means that the network has effectively been rebuilt from scratch.

Instead of keeping the old routing structure from Zigbee2MQTT, the new network has had to establish its own routes.

This is one of the reasons I wanted to migrate gradually.

It allowed me to see how the network behaved as it grew.

At first, there were only a handful of devices.

Then dozens.

Then more than 100.

So far, the experience has been encouraging.

After almost a week of testing, the network appears stable.

I have not experienced any major problems that would make me regret the migration.

Devices are available.

Lights respond quickly.

Automations continue to work.

And the network does not appear to be struggling despite the relatively large number of devices.

Of course, one week is not enough to declare the project a complete success.

Zigbee networks can change behaviour over time.

Devices may find new routes.

Battery-powered sensors may behave differently as they sleep and wake.

New devices may be added.

And real-world usage is always more demanding than a controlled test.

So I will continue monitoring the network.

What About the Devices That Didn’t Migrate Perfectly?

Not every device migration is completely straightforward.

Some devices pair immediately.

Others need a little patience.

Some devices expose slightly different entities after being paired with ZHA.

And this is where it becomes important to check each device after migration instead of assuming that everything is identical.

For me, this was another reason to migrate one device at a time.

After pairing a device, I could immediately check:

• Are all expected entities available?
• Does the device report correctly?
• Are battery levels working?
• Are the sensors updating?
• Do button presses work?
• Do automations still trigger?
• Does the device behave correctly after a few hours?

This approach takes more time, but it makes the migration much less stressful.

It also gives you the opportunity to discover devices that need custom handling.

In my case, I have already had to look more closely at specific devices and ZHA quirks during the project.

That is not necessarily a disadvantage.

In fact, one of the unexpected benefits of this migration has been learning much more about how Zigbee devices actually work underneath Home Assistant.

Would I Recommend Migrating?

At this point, I would say: it depends.

If your Zigbee2MQTT network is stable and reliable, there is no urgent reason to migrate just because ZHA exists.

“Don’t fix what isn’t broken” is still good advice.

But if you are already considering changing your Zigbee setup, or if you want to experiment with a more native Home Assistant architecture, I think ZHA is definitely worth looking at.

The migration is also less frightening than I initially expected.

The biggest task is not necessarily rebuilding your Home Assistant automations.

The biggest task is simply moving the devices.

And if you are willing to do it gradually, one device at a time, the process becomes much more manageable.

For me, the combination of ZHA, Ziggurat and the ZBT-2 radio hardware has so far been a very positive experience.

The network feels responsive.

The devices appear stable.

And after migrating around 120 devices, I have not encountered any major issue that makes me want to return to the old setup.

But this is still the beginning.

What’s Next?

The “Better Zigbee” project is not finished.

In fact, the next phase might be even more interesting.

I want to continue monitoring the network for several weeks and see whether the initial impressions remain true.

I am particularly interested in:

• Long-term network stability.
• Battery-powered device reliability.
• Device availability.
• Zigbee mesh routing.
• Response times for lights and switches.
• How the network behaves under heavy traffic.
• Whether new devices join reliably.
• How the system behaves after Home Assistant restarts.
• Whether the initial performance improvement is still noticeable after several months.

I would also like to do some actual performance testing.

My current observation that lights “feel faster” is useful, but it is still subjective.

A future test could measure the time between an automation trigger and the actual light state change.

That could give a much better comparison.

For now, though, I am happy with the results.

I started with a working Zigbee2MQTT installation.

I moved 120 devices to a completely new ZHA network.

I changed the coordinator architecture at the same time.

And I did it all without having to rebuild my entire Home Assistant automation system.

Most importantly, the house still works.

The lights turn on.

The sensors report their values.

The automations run.

And the Zigbee network feels fast and stable.

For a migration project, that is a pretty good start.

I’ll keep monitoring the network and report back when I have more long-term data.

The “Better Zigbee” project is still ongoing.

But so far, so good.

YAML Example

The new automation model makes this concept even clearer.

Instead of explicitly referencing a specific motion sensor, the automation can work with the area itself.

Here is a simplified example from my laundry room:

alias: Laundry room light
description: ""
triggers:
  - trigger: occupancy.detected
    target:
      area_id: laundry
    options:
      behavior: each

conditions: []

actions:
  - action: light.turn_on
    metadata: {}
    target:
      area_id: laundry
    data:
      brightness_pct: 85

  - wait_for_trigger:
      - trigger: occupancy.cleared
        target:
          area_id: laundry
        options:
          behavior: each
          for:
            hours: 0
            minutes: 3
            seconds: 0

  - action: light.turn_off
    metadata: {}
    target:
      area_id: laundry
    data:
      transition: 10

mode: restart

There is no specific motion sensor referenced in this automation.

Instead, the automation says:

When occupancy is detected in the laundry room, turn on the lights in the laundry room.

And when the room has been clear for three minutes, turn the lights off again.

This is a perfect example of why migrating my Zigbee devices from Zigbee2MQTT to ZHA has required so little work on the automation side.

The motion sensor could be a Zigbee device connected through Zigbee2MQTT.

It could be a different Zigbee device connected through ZHA.

It could be a Z-Wave motion sensor.

Or it could be a Matter or Thread device.

As long as Home Assistant knows that the device provides occupancy information and that it belongs to the laundry room, the automation does not need to care about the underlying technology.

The same principle applies to the lights.

The automation targets the laundry room rather than a specific light entity.

This means I can replace devices, change integrations, or even change communication protocols without necessarily having to redesign the automation itself.

The room becomes the abstraction layer.

That is a significant shift in how I think about building Home Assistant automations.

Instead of asking:

“Which device should trigger this automation?”

I can increasingly ask:

“What should happen when this room becomes occupied?”

And that makes the smart home much more flexible.

It also explains why migrating 120 Zigbee devices did not result in 120 devices worth of automation work.

Once each new device was paired with ZHA and assigned to the correct Home Assistant area, it could simply take over the role of the old device.

The underlying technology changed.

The room did not.

And, in many cases, neither did the automation.