Those who follow this website regularly, already know that Zigbee is heavily favored and focused on in our content over other connectivity standards. It’s a simple, reliable and robust communication protocol with mesh network capabilities.
On one hand, most users prefer Zigbee devices since they are relatively more affordable compared to Z-Wave of Thread alternatives. On the other hand, Zigbee operates within the congested 2.4GHz band, posing challenges of deployment in typical home environments where this spectrum is heavily saturated.
Thankfully, there are steps you can take to ensure the creation of a strong and reliable Zigbee network. This article is the Ultimate Guide to Building a Strong, Stable and Robust Zigbee Network from the ground up. Even if you already have a network in place, this article will prove highly valuable as it provides practical solutions to address and rectify issues with an unreliable Zigbee network.
Choose an application
Picking the right application is crucial in creating a good Zigbee experience. This decision will heavily influence your coordinator choice as well as device support. The two most popular integrations are considered in this article: Zigbee2MQTT and ZHA (Zigbee Home Automation).
The ZHA vs Z2M debate has been going on in community forums and subreddits for as long as I can remember and it always seems to arrive to the same conclusion:
- You want great device support, with new devices added fast
- You want full control over your network and devices
- You want easy OTA firmware updates
- You want you network online when Home Assistant is down
- You want a simple integration, native to Home Assistant
- You want a very easy installation and setup
- You want broader coordinator support
- You don’t want to use an MQTT broker
There is so much more to talk about between the two, but it would require a separate article just to scratch the surface. I can comfortably say that at this point in their development, both are very mature and you cannot go wrong with either one. It’s also possible to run both apps on a single network coordinator!
For the sake of transparency, If I had to pick one, I would choose Zigbee2MQTT.
SIDE NOTE: Before anyone asks, I am not recommending Deconz in this guide since I see no tangible benefit in using it over the other two. It’s designed specifically for the Conbee II/III coordinators, which limits your choices quite a bit.
Use a good coordinator
The next important step to building a strong Zigbee mesh network is to pick a good coordinator. You cannot expect an outdated dongle to perform well with newer devices and large networks.
Sure, the Conbee II stick is an excellent coordinator, it has served you (and me) well over the years. But scaling your network requires an upgrade. Great news is you can flash the Conbee II with Thread firmware and re-deploy it as a Border Router, enabling Matter-over-Thread support in Home Assistant.
I would recommend the following coordinators, depending on your use case and installation method:
- Best Coordinator for ZHA
- USB: Sonoff ZBDongle-E [Amazon, AliExpress]
- LAN/PoE: ZigStar UZG-01 Universal Gateway [Elecrow]
- LAN/PoE: SMLight SLZB-06M [AliExpress, Amazon]
- Best Coordinator for Zigbee2MQTT
- USB: Sonoff ZBDongle-P [Amazon, AliExpress]
- LAN/PoE: ZigStar UZG-01 Universal Gateway [Elecrow]
- LAN/PoE: SMLight SLZB-06 [AliExpress, Amazon]
It’s important to note that EFR32MG21 coordinators are not officially supported in Zigbee2MQTT (e.g. Sonoff ZBDongle-E, SkyConnect), although people are still using them successfully. On the other hand, CC2652x coordinators (e.g. ZigStar UZG-01) are officially supported and work well in both applications.
Check out the Best Zigbee Coordinators for Home Assistant to find good alternatives.
Update coordinator firmware
Even if you have a newer coordinator, it may be necessary to update it’s firmware which will usually include bug fixes, improvements and optimizations. Most manufacturer include a how-to guide, for updating their hardware to the newest firmware. Do this before you start pairing devices. Some resources:
Install your coordinator correctly
The next step is to install and position your coordinator correctly. The models I’ve recommended above all come with external antennas, boosting their signal and reception range. This does not automatically mean you get problem-free network performance out of the box, you still need to pick a proper location and optimize the connection.
- Attach USB coordinators with an USB extension cable
- Always attach the coordinator to an USB 2.0 port (NOT USB 3.0)
- Adjacent USB ports (especially USB 3.0) on your Mini PC/Raspberry Pi are very noisy and known to cause interference issues when the coordinator is plugged in directly to your server.
- Use longer and shielded USB extension cables
- Move the coordinator as farther away from the server as you can (2+ meters)
- Always use a shielded cable and not the one that came with your printer 4 years ago
- Position the coordinator in the center of your network
- This usually means the middle of your home, at equal distance from the farthest devices on both ends.
- Aim the coordinator towards the empty area of your room, away from walls.
- Pivot the antenna to get better signal quality, aiming it towards the bulk of your devices.
- Don’t hide it behind thick furniture or other electronic devices
- Don’t install the coordinator next to routers, access points or other electronic equipment
If you can, use a LAN/PoE coordinator instead of USB. It gives you much more flexibility in choosing an installation position and does not suffer from issues related to USB ports. Again, the ZigStar UZG-01 is the top choice for a hybrid LAN/PoE/Wi-Fi/USB coordinator.
Set channel and eliminate interference
Zigbee operates across 16 channels ranging from 11 to 26 within the 2.4 GHz band, each channel spanning a width of 2MHz. From a Zigbee-only perspective, it may seem that there is flexibility in selecting a suitable channel in the 2.4 GHz band.
This is not true.
Most devices perform optimally on channels 11, 15, 20, or 25, commonly referred to as the primary ZigBee Light Link (ZLL) channels [Source]. In accordance with this specification, ZHA defaults to channel 15, whereas Zigbee2MQTT uses channel 11 in a fresh install.
It’s possible other channels will works just as well, but in my experience, it’s best to choose one of the ZLL channels and work around it to eliminate interference. Which brings me to my next point.
Wi-Fi Interference
Similarly to Zigbee, Wi-Fi can be configured to use 11 different channels, numbered from 1 to 11. Each channel is 20 MHz wide and spaced out 5 MHz from each other. In this case too, it may seem there is room for choosing a free channel.
This is also not true.
Wi-Fi has only 3 non-overlapping channels: 1, 6 and 11, meaning you can only truly use one of the three. Further, the numbering does not mean Wi-Fi ends at channel 11 and Zigbee starts from 11. All their channels overlap, and you need to make sure your Zigbee channel choice is not caught in Wi-Fi’s sideband lobes.
Take a look at this graph for easy understanding:
From the image, we can see that all Zigbee channels (11-26) overlap with one or two Wi-Fi channels (1, 6, 11). This is the reason why it’s crucial to select a Zigbee channel that is as far apart from the Wi-Fi channel as possible. The Best Zigbee channel when coexisting with Wi-Fi is as follows:
- Zigbee channel 11, Wi-Fi channel 6 or 11
- Zigbee channel 15, Wi-Fi channel 11
- Zigbee channel 20, Wi-Fi channel 1
- Zigbee channel 25, Wi-Fi channel 1 or 6
Changing the Zigbee channel requires repairing of all your devices, which is why it’s much easier to change Wi-Fi channel instead. If you can eliminate 2.4 GHz completely and only use 5 GHz, you have solved all your problems.
Bluetooth Interference
Even though Bluetooth operates on the 2.4 GHz band as well, its traffic is handled much differently from Zigbee or Wi-Fi. Bluetooth Classic, which is an active connection method, uses 79 channels spanned across the spectrum with 1 MHz width each. Bluetooth Low Energy, which is a passive communication protocol, uses 40 channels with 2 MHz width each.
Bluetooth uses a technique called Adaptive Frequency Hopping to avoid packet collisions and find a clear path for transmission. It breaks the frequency band into smaller channels (like 40 in Bluetooth Low Energy) and quickly switches between them during transmission. To cut interference even more, Bluetooth adjusts its hopping sequence. It keeps an eye on noisy, busy channels and avoids them when sending packets.
In other words, Bluetooth will only interfere with Zigbee if they’re really close together, especially near the coordinator. To prevent this, make sure your Bluetooth gadgets aren’t packed too closely to your Zigbee coordinator. Spread them out instead of keeping them all in one place and you should have no problems.
Other interference
Another source of interference you need to be on the look out for is so-called EMI (Electromagnetic interference), sometimes called RFI (Radio frequency interference) or signal noise.
All electrical devices, particularly computers and their peripherals, emit electromagnetic interference (EMI). This interference can disrupt or interfere with signal transmissions on the 2.4 GHz radio band frequency, causing degradation in wireless communication with Zigbee adapters and devices.
USB 3.0 ports and unshielded USB peripheral cables are notorious for causing interference that impacts the reception of 2.4 GHz radio signals, particularly for low-power or low-bandwidth devices. Using a sufficiently long and shielded USB extension cable connected to a USB 2.0 for all peripherals, including your coordinator can help eliminate EFI. Home Assistant posted a video about USB 3.0 interference, take a look.
Alternatively, shield any unshielded computers, peripherals, or devices by adding all-metal enclosures if you can. Single-board-computers and USB hard drives are especially known as sources of EMI/EMF.
Plan network topology
The next step towards building a stable and robust network is to properly plan out your network topology. A Zigbee network has only 3 devices types: Coordinator, Router and End Device.
Add sufficient routers
Adding sufficient routers will solidify the network and make it much more stable and reliable. Most mains powered devices (L + N) can act as routers in a Zigbee mesh network, for example: smart plugs, outlets, wall switches, dimmers, modules, presence sensors, led controllers etc.
Some devices, despite being mains powered, don’t function as Zigbee routers, or even worse, they perform poorly as routers. Lightbulbs are a prime example. When you flip the switch on the wall, the lightbulb turns off, interrupting the connection and essentially breaking the path that some End Devices were depending on.
Adding too many End Device and no routers will also result in a weak mesh network and connection drops. Routers are the backbone of any Zigbee mesh network, which is why need to make sure you have enough.
Build from the ground up
Building from the ground up means pairing your Routers first and leaving the End Devices for the final step. This will allow the network to create proper paths to your coordinator and easily relay traffic from adjacent devices.
Scatter around some smart plugs and pair them to the coordinator before adding any sensors and battery-powered devices.
Pair End Devices in their final position
Users often make the mistake of pairing their End Devices near the coordinator and then install them in their final position. This creates a pathing issue because the device will form one path when initially paired (usually a direct one) to the coordinator, which will become out of range when installed farther away.
When paired in the final position, End Devices will find the best path possible to your coordinator, either directly or through the nearest router.
Pair End Devices through adjacent routers
You can force Z2M and ZHA to pair a device to your network through a nearby router, forcing the End Device to form that path specifically. Even though Zigbee is self-healing by design, using this method ensures the initial path is formed optimally.
In Zigbee2MQTT, instead of clicking Permit Join (All), click the dropdown and select Permit Join (Device Name). In ZHA, select the device, click the three dots under Device info and click + Add devices via this device.
Add dedicated signal repeaters
Dedicated signal repeaters are devices with one single purpose: to extend and solidify your network by sending payloads from neighboring devices to the coordinator. These are USB devices that you can plug-in your TV, soundbar or anything with a constant 5V power supply.
Check out this image from my article:
Adding a single USB signal repeater automatically formed paths to most of my devices without tweaking anything. Just like any other router, you can force End Devices to pair through this signal repeater, solidifying the path to the coordinator.
I recommend installing at least one, ideally two of these repeaters, confirmed to work with both ZHA and Zigbee2MQTT:
- Loratap Zigbee 3.0 Signal Repeater [Amazon]
- eWelink Signal Repeater
- Gleco Signal Repeater (New)
- IKEA Tradfri Signal Repeater
- Aeotec Range Extender Zi
Alternatively, you can flash a spare coordinator like the Sonoff ZBDongles with router firmware and use them exclusively as dedicated signal repeaters. This is cost effective, since the Sonoffs are affordable on Amazon and AliExpress.
Form direct links where you can
Zigbee Direct Binding enables the direct linking of an endpoint from one device (source) to one or multiple endpoints of another device or group (target). It basically means establishing a connection between two devices independent of any software apps (such as Zigbee2MQTT or ZHA), the primary coordinator, or other devices within your network.
It’s worth mentioning that not all Zigbee devices support direct binding, which depends on how the manufacturer designed their Zigbee app layer. Also, some devices may support direct binding but won’t change state when activated by the source.
Most remotes do support direct binding as a source, while most lights can act as a target. Directly bound devices can be used even when your Zigbee network is down!
Send commands in Zigbee groups
In a Zigbee network, a group represents a set of endpoints, like a collection of lightbulbs. Sending a command through Home Assistant to turn them all on at once creates significant Zigbee traffic, congesting the 2.4 GHz band.
The concept is pretty straightforward: group similar devices together and send only one command, substantially cutting down the payload. Remember, groups needs to be created in Zigbee2MQTT directly and not Home Assistant, which is a completely different thing.
Identify and eliminate noisy devices
This has been a rising issue with the mass appearance and deployment of presence sensors in smart homes. Since a presence sensor requires an active scan of it’s surrounding to determine whether or not a human is present, it can easily overload your Zigbee network by sending constant packets.
One recent example is the Moes/Linptech ZSS-LP-HP02 presence sensor. Unfortunately, this device floods your Zigbee network HARD. Because Tuya doesn’t follow standard Zigbee protocols and data is pushed instead of polled, there’s no way to reduce this traffic, either per device or entirely. Read more about this here.
You can easily identify spammy devices by looking at the logs in Zigbee2MQTT or ZHA. Your best course of action is to simply remove those.
Ensure devices can talk to each other
It’s important to note not all brands are optimized to talk to each other. For example, Aqara devices are known to be very picky with what they work with. They will outright refuse to pair, cause delays or dropout of the network. You need to make sure your devices can talk to each other, especially when forced to pair through a specific router. Some tips:
- Aqara devices don’t work well with: Legrand/Netatmo, Centralite, Ledvance/Osram, Lightify/Sylvania, Securifi, Orvibo, Iris, General Electric or SmartThings/Samsung routers
- Aqara devices work well with: Phillips Hue, Ikea Tradfri (newer), Tuya Zigbee 3.0 routers
Have a suggestion? Share it in the comments bellow.
Heal your Zigbee mesh manually
Zigbee devices form their communication mesh automatically, but this process isn’t immediate and takes time. Depending on your devices, it can take somewhere between a few days to two weeks to fully heal your mesh network and have devices form their optimal paths automatically.
However, you can force this healing process by fully powering down your network for 30 minutes. Have all your devices powered on and ready before you turn on your server and coordinator.
Don’t go over the device limit
Depending on your coordinator, you can attach a finite number of devices in a direct connection. Older coordinators usually have a limit of 16-32, while newer and more capable coordinators can handle up to 100 devices directly connected.
This doesn’t mean you cannot go over the limit at network level, it just means you cannot connect more than the limit directly. For reference, CC2652x coordinators can handle up to 200 unique routes. Koenkk’s Z-Stack 3.0 firmware repo has a good table explaining these limits.
Dealing with neighboring Wi-Fi networks
If you’ve remained working from home like some of us did post-COVID, then you’ve encountered a cluttered 2.4GHz band from neighboring networks. Beside your own, they can interfere with your Zigbee network and cause problems, which is why they need to be dealt with. On a related note, if you’re still trying to find remote job opportunities, Jooble is an excellent resource to start a remote career!
Well, the first step is to scan the 2.4GHz band with an app like Wi-Fi Analyzer. If you discover your neighbors Wi-Fi is emitting on say, channel 1, set your Wi-Fi to channel 6 and build your Zigbee network on channel 20 or 25. Work around both networks to form a solid Zigbee mesh.
The thing is, 99% percent of routers do not have the channel preset at any number. They use auto mode, meaning they actively scan the 2.4GHz band and broadcast the network on a channel that is the least congested. Whenever your neighbors routers does this, it will, theoretically swap to a free channel, one that you haven’t already occupied.
Ultimately, if the interference persists despite your efforts, there’s always the human approach. Consider having a friendly conversation with your neighbor about the issue, they may be willing to adjust their WiFi settings or let you do it instead.
Summary
Hopefully, this article helps you understand what it takes to create a stable and robust Zigbee network. If you employ at least half of these tips and advices, I am confident you will have no issues.
This article will be frequently updated to include new tip, trips and hacks for properly maintaining a Zigbee mesh network.
If you have anything you want to share, write it in the comments bellow.
Great article, thanks! Can you clarify what devices are allowed within a Zigbee group? Are end devices allowed or is it mostly for routers and light groups? I can’t seem to add binary sensors to groups. And how should you configure a presence sensor with a light zigbee group? By binding the sensor to the group? Thanks again!
Hey Sam,
I highly suggest you read this:
https://www.zigbee2mqtt.io/guide/usage/groups.html
and this
https://www.zigbee2mqtt.io/guide/configuration/devices-groups.html
And you are correct about the presence sensor binding. You need to directly bind the device to a Zigbee group.
Cheers.
Excellent article with tons of great tips and recommendations. Thanks for putting it together.
Would you mind sharing some tips on how to differentiate Sonoff ZBDongle-E from Sonoff ZBDongle-P? I have 2 of these, except I’m not quite sure which model they are.
Sonoff ZBDongle-P is bigger (longer) than the E.
You can always dismantle the device (2 screws) and see the chip.
EFR32MG21 – Sonoff ZBDongle-E
CC2652P – Sonoff ZBDongle-P
Thanks, I thought I could somehow get the info from Linux cli, same goes for finding out the current firmware of the stick before going through all the hassle of upgrading. I just realized, Z2M shows me the firmware version of the stick under Settings => About
‘Coordinator revision 20220219’
Hi There, Just wanted to say thanks for the articles! Your one on the best Zigbee coordinator prompted me to purchase the UZG-01. I had a SkyConnect, but had set this up with multiprotocol when they first came out, needing both Thread and Zigbee. I migrated ZHA to the UZG-01 (Crazy how easy that was!) and how can reset the SkyConnect to just thread.
Hey, you need to use the web flasher and install the Thread firmware on the SkyConnect.
See here for more info: https://skyconnect.home-assistant.io/about-firmware-options/
Do you have any reviews or opinions on SkyConnect? I note it’s not in your recommendations. Contemplating moving away from it and to one of your LAN recommendations. Currently a happy ZHA user, but also toying with switching to Z2M as community seems to lean that way for the reasons you give.
I don’t recommend the SkyConnect because it’s USB-only, not officially supported by Z2M (to be fair, no EFR32MG21 modules are) and I see no point in using it over others (Sonoff ZBDongle-E is the same identical stick with a better antenna!).
I always mention the SkyConnect is simply a way to support Home Assistant devs though, so that would be one reason why.
Hi, regarding your recommendation for using usb 2.0 to plug in the coordinator, I would like to suggest a follow up article or an additional update to this guide. I would like to find out if is using a USB 2.0 extension cable connected to a USB 3.0 port on a system good enough, or is it better to get a USB 2.0 hub and use that instead. I hope you could have some answers or you could test it out.
This is because systems that ONLY have USB 3.0 and above ports are getting more and more common, and not everyone has access to a raspberry pi or their alternatives even though there shouldn’t be a shortage anymore. There are many advantages of getting more modern mini PCs, one of which is higher availability in many developing countries. And I am definitely not gonna go and spend even more time and money just to buy a pi or an older system if I acquired my mini PC before your article appeared.
Hello,
There is no need for a separate article.
If you have only USB 3.0 ports, you must use a good quality SHIELDED USB cable.
If you have USB 2.0 ports, you won’t have issues in the first place, which is why I suggested using 2.0.
But if you are limited to only 3.0, use a good cable (I like UGREEN) and you won’t have issues.
A USB hub is also a good solution, but I would say there is no need.
Cheers.
Hi, I’m running Z2M in a docker container on a QNAP NAS and my coordinator is a Sonoff ZigBee Bridge (not the Pro version) which I have flashed with Tasmota. All is integrated with Home Assistant, and all is mostly well.
However, some times, now and then, the bridge looses connection to the MQTT server (Mosquitto) which also runs in a docker container on another QNAP server. Exactlt why this happens now and then, is unclear to me, but certainly everytime the NAS needs to be rebooted to upgrade its firmware, or because the MQTT server need to be updated, which are obvious reasons for disconnections.
However, what bothers me is that Z2M seems completely unabel to handle lost MQTT connection gracefully. It simply crashes! That’s totally unneccessary. A warning on screen while ideling and awaiting reconnection should be easy to implement. At least, then I could still use the WebUI and easily se the error log and time of events.
As it is now, everything just stops working without any warning, and I have to log into the container management system in order to seewhat has happened, and manually restart Z2M. I know I can use restart: unless-stopped as a container setting, but that too has it’s drawbacks.
Bottom line is: Z2M is great as long as it remains running stable, but it’s not very robust as far as graceful handling of hickups and interruptions.
Thanks for sharing your experience.
Maybe you can submit a new feature request? That sounds like a great addition to the app.
https://github.com/Koenkk/zigbee2mqtt/issues
Thanks a lot!
Thanks to SHS putting this guide together. Setup my HA with Z2M for a couple of years and lately one of the Aqara E1 blind motors started acting up. Not sure if it is explicitly affected by https://github.com/Koenkk/zigbee2mqtt/issues/22189 or what.
Anyhow, the E1 was placed in my upstairs where it’s the furthest distance to the SONOFF ZB Dongle-P. But even when I selected the nearest smart plug (10 feet away) to be joined by the E1, it still joined with the other routers located on a further distance than the smart plug.
Any recommendation?
Aqara devices do not follow the Zigbee specification and use their own implementation of the protocol at the application layer.
In other words, they are very picky with which devices they can talk to.
You E1 is out of range and your best bet is to find a suitable router.
Tuya Zigbee plugs are good routers for Aqara EndDevices.
I got an Aqara Smart Light Switch (required Neutral) in which I will give it a try, install it in the same room with the blind. See if that makes a difference when the switch can be acted as a router, compatible with E1.
This out of range issue didn’t bother me until the Z2M upgraded to the 1.36.1 that led to a wider problem to more Z2M HA users.
Just share some updates on my network issue and remediation.
After I installed an additional Aqara single-pole smart switch (neutral required) on my Zigbee network, issues I described earlier above resolved automatically.
Apparently it was a coincidental issue appeared right about the same period as https://github.com/Koenkk/zigbee2mqtt/issues/22189 reported with the same error message received in my log.
Hi,
thanks again for your good guides. I have one question though, my network finally works stable using the Dongle-E with ZHA and 67 devices (as of now).
Most light devices are grouped by room or lighting area and have at least two remotes (philips hue remote) connected to the same group. Whenever I switch light on or off using another remote than previously used I have to press the button twice before anything happens. Is this normal for zigbee when the commands are delivered directly within a group or can this be fixed?
Thanks 🙂
No, not really. I would need to see the logs to know whats happening. Perhaps the first payload is not going through
I can find no entries related to that in the logs (debug logging for zigbee is active). I see every button press in the log but the lights just don’t react to the first press, always when I use a different remote than the last button press. If I use the same remote for several actions in a row (even if spread over several hours) all lights always react. As I said the remotes and the lights are in the same groups and the commands are delivered directly not through the coordinator.
Hey Thorsten,
Seems to be a bug with some remotes and ZHA refactoring. Can you try changing to an automation in the following format?
https://github.com/home-assistant/core/issues/92138#issuecomment-1526946834
Let me know how it goes.