Building a Stable Zigbee Network: Lessons from 150 Devices

Our home runs around 150 Zigbee devices. Lights, sensors, switches, plugs, blinds, leak detectors, climate sensors, you name it. Most of the time it just works, but getting there took a few painful nights, an unhappy wife, and more re-pairing than I want to admit.

This post is what I’d tell myself if I was starting over. Nine things that actually broke or saved my Zigbee network, grouped into three areas: the foundation you set once, the mesh you grow over time, and the operations you do (or skip) every week.

I’m using Zigbee2MQTT with a SMLIGHT SLZB-06p7 PoE coordinator. If you’re on ZHA or a different stick, most of this still applies. Just translate the tooling.

The Foundation

These are the decisions you make early and rarely change. Get them wrong and everything downstream feels broken.

Put the coordinator in the middle of the house

About a year ago, my Home Assistant instance lived on the second floor of the house. Then we had a kid, that room became the nursery, and I moved everything down to the ground floor.

Within a few weeks, lights started taking longer to respond. Scene switches felt sluggish. Nothing was completely broken, but the snappy feel was gone. When I finally opened the Zigbee2MQTT network map, almost 50 devices were sitting on a low LQI score (the link quality between a device and its parent).

I tried the obvious things first. Firmware updates on the worst devices. Swapping a few problem switches for known-good ones. I even flashed a couple of spare Sonoff sticks as repeaters and plugged them in around the house. None of it really helped.

What actually fixed it was moving the coordinator back to the middle of the house. I switched from a USB stick to a SMLIGHT SLZB-06p7 (a PoE coordinator with Ethernet), put it in a central spot on the second floor, and ran my Home Assistant instance from wherever was convenient. LQI scores recovered within a day.

The non-obvious bit: even though I had repeaters scattered around, devices kept choosing the strongest signal, which was the coordinator downstairs. So they’d route through one giant weak hop instead of using the closer router. Adding more routers didn’t help when the coordinator was loud enough to outshout them all.

If your coordinator is sitting in your meter cabinet, that’s almost always the wrong spot. Modern houses have heavy insulation, sometimes three layers between the cabinet and the rooms above. Zigbee at 2.4 GHz doesn’t love that. PoE coordinators solve it cleanly: the coordinator goes where the radio coverage needs to be, and Home Assistant goes wherever you have a network port.

Pick a Zigbee channel that isn’t fighting your Wi-Fi

Early on, when our network was still small, devices would randomly drop and refuse to come back. I went through the usual fix-it-in-software cycle. Read GitHub issues, run updates, restore old configs, swap firmware. Devices kept disappearing.

The actual problem was the channel. I scanned my Wi-Fi environment with NetSpot (free version, Mac and Windows), and channel 11 was completely saturated. My Zigbee network was on the default, which happened to overlap channel 11. I was running both technologies on the same slice of 2.4 GHz spectrum.

I switched my Zigbee network to channel 25 and stability came back immediately.

The painful part: I didn’t know how to migrate devices to a new channel cleanly, so I re-paired almost everything. That’s the warning I want to give you upfront. Changing the channel on a live network is a near-one-way door. Devices don’t follow the coordinator, you have to re-pair them. Pick your channel before you pair 100 devices, not after.

Channel 25 is usually the safest bet. It sits above Wi-Fi channel 11, which means you’re outside the busy 2.4 GHz Wi-Fi range (channels 1, 6, and 11). Channel 26 is restricted to lower transmit power in the US under FCC rules. I’m in the Netherlands so it’s not an issue, but worth knowing if you’re elsewhere.

Use random PAN IDs and back them up

I don’t have a war story here, which is exactly why it’s worth mentioning. The PAN ID and Extended PAN ID identify your Zigbee network. If two networks in radio range share the same values, things get messy.

Older Zigbee2MQTT installs used a static default PAN ID (0x1a62), which meant any two neighbors who never touched their config could clash. Modern Z2M ships with pan_id: GENERATE and ext_pan_id: GENERATE in the example config, so a fresh install picks random values for you. If you set up Z2M years ago, check your configuration.yaml and make sure those values aren’t still on the static default.

Once Z2M generates the values, write down the pan_id, ext_pan_id, network_key, and channel. You’ll need the exact values if you ever migrate to a new coordinator without re-pairing every device.

Same caveat as the channel. Changing any of these on a live network forces re-pairing.

The Mesh

These are the things that take time and money to build. You add to them as your network grows.

Add routers as you grow

When we first moved into our home, the network started small. Just a handful of devices on the ground floor. As we expanded, we added a sensor to the attic. It performed terribly. Constant timeouts, dropped events, going offline for hours.

That’s the symptom of not having enough routers. Zigbee is a mesh, but only mains-powered devices act as routers. Battery devices are leaves on the tree. If there’s no router between your far-away sensor and the coordinator, the sensor either has to make the full hop (often impossible in a normal house) or just doesn’t work.

I temporarily fixed it with an IKEA Tradfri Zigbee repeater, a USB stick you plug into a wall outlet that does nothing but act as a router. I think IKEA stopped selling those, but any decent mains-powered Zigbee device works the same way.

Today, out of about 150 devices, around 90 are routers. I don’t need the IKEA repeaters anymore because we built the rest of the network out so heavily that there’s always a router nearby.

Make Hue lights your backbone

When we built our home, we made one big architectural decision. Every ceiling light, wall light, and bulb would be Philips Hue. We’d already used Hue in our previous home and trusted them, and they happen to be excellent Zigbee routers.

That decision alone gave us router coverage in every room before we paired a single sensor. Lights are everywhere in a house, they’re always powered, and Hue’s mesh implementation is rock solid.

Innr lights work just as well if you want a cheaper alternative. Both brands are mainstream, well-supported in Zigbee2MQTT, and behave properly as routers. Pick based on color rendering and price, not Zigbee compatibility.

If you’re building or renovating, this is the easiest decision you’ll ever make. Pre-plan your lights as Zigbee, and your mesh problem mostly solves itself.

Beware cheap router devices

A few years in, I wanted to measure power on a few specific outlets. The oven, some entertainment gear, that kind of thing. I bought a batch of Tuya smart plugs from AliExpress, around eight to ten euros each, and put them everywhere I had a measurable load.

They worked. Sort of. The plugs themselves did what I bought them for. But devices that ended up routing through them started behaving strangely. Lag on actions. Random disconnects. Some sensors going offline at night and reconnecting in the morning.

I figured it out by opening the Zigbee2MQTT network map. Any device whose route passed through a Tuya plug, directly or indirectly, performed badly. Devices routing through a Hue bulb were fine. The plugs were technically routers, but they were dropping their children’s traffic.

I replaced all the Tuya plugs with better-known brands and the network healed within a few hours.

This isn’t just an AliExpress problem either. I’ve seen the same pattern with Aqara plugs, even though Aqara is a mainstream brand most people trust. The lesson: a cheap or poorly-implemented plug can be a bad neighbor for your entire network. If you must use them, keep them out of the routing path or check the Zigbee2MQTT supported devices list for known-good alternatives.

USB 3.0 interference (the trap I dodged)

Not really a war story, but worth a note. Before the SLZB-06p7, I was running a Sonoff stick plugged into a Raspberry Pi.

USB 3.0 ports and devices radiate noise around 2.4 GHz. If you plug your coordinator stick directly into a host that also has USB 3 SSDs or hubs nearby, your Zigbee range collapses. The fix is a one to two meter USB 2.0 extension cable that puts the stick somewhere away from the noise.

I happened to read about this before I set up my first network, so I always used an extension cable. If you’re starting fresh with a USB stick coordinator, this is the cheapest single thing you can do to improve range.

The Operations

These are the things you do (or fail to do) every week. They’re boring, but they’re the difference between a network that runs for years and one that breaks at 6am on a Tuesday.

Don’t update without a reason

This was the one that taught me the hardest lesson.

About two years into the network, sitting around 100 devices, I was clicking “update” every time Zigbee2MQTT or my coordinator firmware had a new release. I didn’t read the changelogs. I just trusted that newer was better.

One update broke almost everything. Devices started dropping out within hours. By the morning, half the lights wouldn’t turn on. My wife was very, very unhappy.

The cherry on top: I didn’t have Home Assistant backups configured at the time. Restoring took forever. I had to figure out how to roll Zigbee2MQTT back to the previous version manually, which is not the documented happy path. Then, because I assumed a coordinator firmware update might “stabilize things,” I updated that too. It made things worse.

After that, my approach changed completely:

• Daily Home Assistant backups, automated. If anything breaks tomorrow, I restore yesterday and life goes on.
• I read the Zigbee2MQTT changelog before any update. Most releases are device support I don’t need or fixes for things I’m not using. So I skip them.
• I do not touch the coordinator firmware unless I have a specific reason. If my current version is stable, that’s the version I run.

The principle: don’t update for the sake of updating. Read the changelog. If nothing in there matters to you, the safest move is to do nothing.

Back up before migrations

A separate thing from Home Assistant backups: when you change coordinator hardware, you can export a Zigbee network backup that captures the network key, channel, PAN ID, and device list. Without it, a coordinator swap means re-pairing every device.

I don’t run regular backups of this file. But when I migrated from the Sonoff USB stick to the SLZB-06p7, I exported one. If the migration had gone sideways, I could have restored it onto the Sonoff and tried again. The migration went fine, but that backup was the safety net that let me even attempt it.

If you’re planning a coordinator change, do the export first. The Zigbee2MQTT FAQ walks through which files to back up and the migration steps.

Use the network map when something feels off

The Zigbee2MQTT map (the Map tab in the Z2M frontend) is the most underused diagnostic tool in Home Assistant.

I don’t look at it on a schedule. I open it when something feels wrong. It tells me three useful things:

• Which devices have low LQI (anything under 50 is a yellow flag).
• Which router each device is talking to.
• Whether any router has a suspiciously large fan-out, which usually means other routers nearby aren’t working.

A useful detail: if you’ve recently lost power or rebooted your coordinator, devices spend hours rediscovering routes. The map will look messy in the meantime, and devices may temporarily perform worse than usual. That’s normal. Give it a day before assuming something is broken.

A 5-minute self-audit

If you read this far, here’s what to check on your network before you close this tab:

1. Where’s your coordinator physically? Is it in a meter cabinet or basement? Could you move it to a more central spot, or put a PoE one there?
2. What channel is your Zigbee network on? Is it set explicitly, or still on the default? Run a Wi-Fi scan with NetSpot or similar and see if your channel overlaps a busy Wi-Fi.
3. Open the Zigbee2MQTT network map. How many devices are below LQI 50? Are any of them routing through cheap plugs?
4. When did you last back up Home Assistant? Is the backup actually scheduled, or did you do it once last year and forget?
5. Do you have any AliExpress smart plugs or Aqara plugs acting as routers? If yes, watch them in the map. If devices are bunching behind them, that’s your next afternoon project.

A solid Zigbee network is the foundation for everything else. My iPhone presence detection setup wouldn’t survive a flaky mesh, and neither would any of the lighting automations my family relies on. So pick the worst item from the audit and fix that this weekend. You don’t have to do everything at once.