Zigbee Devices Going Unavailable: How to Fix It
Zigbee devices dropping offline are usually a mesh or interference fault, not a broken device. Work the documented causes in the order that pays off.
A Zigbee device showing as unavailable is rarely a broken device. It is a message that did not get through, repeated until Home Assistant gave up on the entity. The device is usually fine, sitting exactly where you left it, unable to reach anything that will forward its traffic.
That matters because it changes what you should do first. Re-pairing the device is the most common first move and one of the least productive, because it fixes the symptom at the same location that just failed. The Home Assistant documentation orders the real causes differently, and so should you.
Work this list in order. Each step is cheap, and the early ones resolve the majority of cases.
1. Get the coordinator away from the computer
This is first because the documentation puts it first, on both Zigbee and Z-Wave.
The ZHA documentation states that all electric devices, especially computers and computer peripherals, generate electromagnetic interference that can partially degrade or fully jam 2.4 GHz communications, and it names the culprits: signal noise from USB 3.x ports, unshielded USB 3.x devices, and non-shielded USB 3.x peripheral cables. The Z-Wave documentation is blunter still, opening its troubleshooting FAQ with the observation that many reported issues result from RF interference caused by the system’s USB ports, and asking users to try an extension cable before opening an issue at all.
This is not folklore. Intel’s white paper USB 3.0 Radio Frequency Interference Impact on 2.4 GHz Wireless Devices documents broadband noise from USB 3.0 signalling landing in the 2.4 GHz band, which is precisely where Zigbee lives.
The fix, in the order the docs give it:
- Put the coordinator on an adequately shielded USB extension cable. Thicker cables generally shield better.
- Connect it to a USB 2.0 port, or a powered USB 2.0 hub if the machine only has USB 3.x ports.
- Move it away from power supplies, drives, electrical cabling and household appliances.
- Move it away from Wi-Fi access points.
- Try different orientations, and aim for somewhere near the middle of the house, away from walls, ceilings and floors.
If Home Assistant is running on a NAS or in a rack, this step alone frequently ends the investigation. A coordinator in the back of a metal chassis in a cupboard is in close to the worst environment available. The hardware guide covers why the appliance boxes ship USB 2.0 ports deliberately.
2. Count your routers, not your devices
Zigbee is a mesh, and a mesh with nothing to route through is a star network pretending. The docs are explicit that Zigbee networks depend heavily on having multiple router devices to expand coverage and increase capacity, and that most mains-powered devices such as always-on wall plugs and bulbs act as routers automatically.
Two failure patterns come out of this:
- Not enough mains-powered devices. The advice in the docs is to start with mains-powered devices before adding battery-operated ones. A network built entirely from battery sensors has no backbone at all.
- Routers that get switched off. The docs say directly that you should not have a setup where router devices such as light bulbs are often powered off, because routers are meant to be always available. A smart bulb on a wall switch that people turn off is a routing hole that opens and closes at random, which is exactly what an intermittent unavailable device looks like.
There is a capacity ceiling too. The zigpy library ZHA depends on has an upper limit of 32 direct children on the coordinator. Beyond that you need routers, not a better coordinator, and the docs work through an example where three routers lift a network from 32 to 77 devices.
Not all routers are equal. The docs record a specific known incompatibility: Xiaomi and Aqara devices are known not to work with router devices from Centralite, General Electric, Iris, Ledvance/OSRAM, LIGHTIFY/Sylvania, Orvibo, PEQ, Securifi and SmartThings/Samsung, and better results are usually achieved with IKEA or Nue/3A Home mains-powered devices, or dedicated DIY routers built on TI CC253x/CC26x2 or XBee Series 2/3 radios. If your Aqara sensors in particular are the ones dropping, check what they are routing through before blaming the sensors.
3. Fix the Wi-Fi channel before you touch the Zigbee channel
Zigbee and Wi-Fi overlap in 2.4 GHz, and the instinct is to move Zigbee. The docs recommend the reverse: if you have issues with overlapping frequencies, it is usually better to first set a static Wi-Fi channel on your router or access points instead of changing the Zigbee channel.
The reasoning is practical. Zigbee is the narrower, less flexible side of the pair. The specification divides the band into 16 channels, not all devices support all channels, and the general recommendation is to stay on channel 15, 20 or 25 to avoid interoperability problems.
If you do change the Zigbee channel, know what you are signing up for. The channel can be edited from the ZHA network settings, and the Smart option scans all of the channels and then picks the best one. It is a one-time operation; it does not monitor and re-tune later. After a change it can take up to an hour for devices to reconnect, and power-cycling battery-powered end devices speeds that up.
4. Update the coordinator, and retire obsolete ones
The docs name outdated coordinator hardware and old firmware as a common root cause of unreliable performance: obsolete chips, poor antenna designs, buggy firmware. They also make a specific call, that CC2530 and CC2531 sticks are no longer recommended and will not work properly on networks larger than 15 to 20 devices.
Two things to do here:
- Update the coordinator firmware before deeper troubleshooting. The docs recommend it as a general first move when devices start misbehaving.
- Replace genuinely obsolete radios. Current recommended options include Silicon Labs EmberZNet parts, current TI CC2652 and CC1352 parts, and the ConBee III. An adapter with an external antenna gives you placement flexibility that an integrated one cannot.
Migration is less painful than it used to be. ZHA takes automatic backups of the network and supports migrating between Silicon Labs, TI and ConBee adapters, including permanently overwriting the radio IEEE address so devices do not all need re-pairing. The protocol comparison covers which coordinators are worth migrating to.
5. Check the batteries, especially before firmware updates
Low battery voltage causes symptoms that look nothing like a flat battery. The docs note that some battery-operated devices have problems pairing at low voltage, and that replacing the battery on newly received Xiaomi and Aqara devices has resolved pairing issues for some users.
Over-the-air firmware updates are the sharper case. The docs recommend installing fresh batteries before any OTA update, because updates are power-intensive and some devices check for a minimum battery level and refuse to start. Battery devices are sleepy devices, so an update may not begin until you wake the device by pressing a button or triggering a state change, and a normal OTA takes around 10 minutes per device. Longer than that usually means poor reception, which returns you to steps 1 and 2.
6. Pair devices where they will live
A device paired next to the coordinator and then carried to the far end of the house keeps the route it learned during pairing. The docs advise pairing devices where you intend to use them, and warn that pairing next to the coordinator and moving the device later can result in degraded connections.
If a device was previously joined to another network, it will usually need a manual factory reset first, because a Zigbee device can only belong to one network at a time. And some devices are simply awkward: the docs note that non-compliant devices, Xiaomi and Aqara among them, may need repeated pairing attempts over 10 to 20 minutes.
7. Rule out the serial link and the host
If everything drops at once rather than device by device, suspect the connection between the host and the coordinator rather than the mesh.
The docs caution against running a coordinator through a serial-to-IP bridge over Wi-Fi, WAN or VPN, because the serial protocols the coordinator uses lack the robustness to tolerate packet loss and latency. A wired Ethernet coordinator is a different proposition from a Wi-Fi one.
On virtual machines and containers, the device path is the usual suspect. /dev/ttyUSB0 is assigned in enumeration order and moves silently after a reboot or a second USB device; pin the radio by its stable /dev/serial/by-id/ path instead. Container installs also need the device mapped in explicitly, and a container that cannot see the dongle produces an error that reads like a coordinator fault. The install method comparison goes through the hardware access differences in detail.
Diagnose before you re-pair
Before changing anything, look at the network topology visualisation in ZHA. It shows which devices route through which, and it is the fastest way to see that a “broken” sensor is actually orphaned behind a bulb somebody switched off. Debug logging is available for the harder cases.
Then work the order above: cable and placement, routers, Wi-Fi channel, firmware, batteries, pairing location, serial link. Re-pairing sits at the bottom of that list for a reason. It is the step most likely to lose your device configuration and least likely to fix the cause.
What not to do
- Do not add a mains-powered “repeater” on a switched circuit. A router that loses power is worse than no router, because the mesh keeps trying to route through it.
- Do not change the Zigbee channel first. Set a static Wi-Fi channel first; it is the more flexible side.
- Do not mix router brands blindly if you run Aqara or Xiaomi end devices.
- Do not run the coordinator over a Wi-Fi serial bridge and then troubleshoot the mesh.
- Do not skip the extension cable because the coordinator “seems fine”. It is the cheapest step and the docs put it first on both Zigbee and Z-Wave.
See also
- Home Assistant hardware for hub choices and where the coordinator should physically sit.
- Zigbee vs Z-Wave vs Thread for when the answer is a different band, not a better antenna.
- Home Assistant OS vs Container for USB passthrough and serial path handling per install type.
Sources
Related
ZHA vs Zigbee2MQTT: Differences and Tradeoffs
This comparison explains how ZHA and Zigbee2MQTT differ in setup, device support, interfaces, MQTT requirements, migration, and best-fit use cases.
Zigbee vs Z-Wave vs Thread: Which Mesh to Build
Zigbee, Z-Wave and Thread differ in spectrum, routing and what controls them. A documentation-level comparison to help you commit to one backbone.
Best Zigbee Coordinator Stick for Home Assistant: 4 Picks
Home Assistant Connect ZBT-2 suits ZHA, while SONOFF and SMLIGHT coordinators offer options for Zigbee2MQTT, Docker, and difficult server locations.