Zigbee Device Keeps Dropping Off: an Honest Case Study

Honestly, my Zigbee network is tiny. ZHA has exactly one device on it: a battery-powered SONOFF water valve in a pit outside that switches the misting line on the terrace. The Hue lights in the dining and living room run through the Hue Bridge — their own Zigbee network, nothing to do with ZHA.

And still — or precisely because of that — this one device kept me busy for a whole summer. It was there, then gone, then back. If that sounds familiar: in my case the cause was not the valve. It was the topology, and mine was as thin as a topology can get.

The symptom

The valve shows up in Home Assistant as a plain switch, switch.garden_sonoff_water_valve. The automation behind it is simple: every ten minutes, check whether it’s sunny and above 28 °C, open for two minutes, close again.

In practice it looked like this: the first two or three switch cycles of the day went through. After that the log said “device did not respond” — not a clean error, just a timeout. The valve stayed in HA on its last known state, sometimes on, which is the reason the failsafe automation exists at all. A few hours later it was often reachable again on its own. So not a total outage, but the annoying kind: intermittent.

What I got wrong first

My first reflex was the battery. It sat at 100 %. My second reflex was the classic: “cheap Zigbee crap, right?” Both wrong.

Zigbee has two device classes, and the difference is the whole point:

• End devices are battery powered, sleep almost all the time and forward nothing. My valve is one of those. It wakes up, checks in with its parent, does its thing, goes back to sleep.
• Routers are mains powered, forward packets and form the mesh. Smart plugs, bulbs, repeaters.

An end device needs a parent within radio range. In my network there is not a single router. The only possible parent is the coordinator itself — and that was in the basement.

The topology that could never work

My Home Assistant server lives in the utility room in the basement, inside a metal cabinet, next to a USB 3 enclosure. The pit with the valve is in the garden. In between: three concrete ceilings and an exterior wall.

So the valve had exactly one link — straight to the coordinator, through the entire house. No hop via a router, no second route. Whenever that one path was too poor at that moment, the device was gone. And a sleeping end device that fails to reach its parent a few times goes looking for a new one — there just wasn’t one.

That’s the pattern I recognize in almost every “Zigbee is unreliable” story: one or more battery devices, zero routers, and the coordinator wherever it was convenient rather than where it’s useful. The surprising part isn’t that such a network drops out. The surprising part is that it ever worked.

Attempt 1: USB extension on the server

The well-known tip, and it isn’t wrong: USB 3 ports and their cables emit broadband noise right around 2.4 GHz. A Zigbee stick plugged straight into the host next to a USB 3 enclosure is sitting inside that noise.

So I put the dongle on an active USB 2.0 extension and pulled it out of the cabinet. Specifically the active USB 2.0 extension* I still use today.

Honest result: better, but not good. Dropouts became rarer but didn’t disappear. Three concrete ceilings are three concrete ceilings. If your coordinator is on the same floor as your devices, the extension is probably all you need. For me the underlying problem was distance, not noise at the port.

Attempt 2: Move the coordinator to where the network is

What worked in the end was the blunt instrument: the dongle no longer hangs off the server. It sits on a Raspberry Pi Zero 2 W on the ground floor, and Home Assistant talks to it over the LAN — serial over IP with ser2net. The details are in a separate article, including the mistakes that cost me weeks.

For this article, what matters is the outcome: since the coordinator is one ceiling from the pit instead of three, the valve has not dropped off. No “did not respond”, no stuck state. Same hardware, same valve, same automation.

What I didn’t do — and why you probably should

The textbook fix for my problem would not have been the ser2net rebuild but a mains-powered Zigbee router near the valve: a Zigbee smart plug on the terrace. The end device would then have a parent ten meters away instead of three floors, and the coordinator could have stayed in the basement.

Why I did it differently anyway: I wanted to physically separate the HA host from the Zigbee network regardless, and there is no outlet out by the pit. For most readers the smart plug is the cheaper and simpler answer. Add one router, wait 48 hours, check under Devices → Visualization in ZHA whether the end device has adopted the new parent. Only then buy more.

The thing about the Hue Bridge

A detail I only noticed later: with the Hue Bridge and ZHA I’m running two separate Zigbee networks in the same house. Both transmit on 2.4 GHz, each has its own channel, and then there’s Wi-Fi on top.

I haven’t tuned the channels against each other, because the problem was gone after relocating the coordinator. But if your network still misbehaves after the topology fix and you have a Hue Bridge or a second Zigbee base in the house, that’s the next suspect: check which channel is active in ZHA and in the Hue app, and spread the two networks plus Wi-Fi apart. One warning — a Zigbee channel change usually means re-pairing devices. With one device that’s nothing. With thirty, schedule an evening.

What does NOT help

• Buying a new valve. The device was never the problem.
• Replacing the battery at 100 %. It only matters below ~2.7 V.
• Restarting the coordinator. Masks the symptom for a few hours and still feels like a fix every single time.
• Re-pairing. Without a topology fix the device lands on the same, too-distant parent again.

What I’d tell someone today

1. Check in ZHA which parent the problem device has. If it’s the coordinator and the coordinator is far away: that’s your cause.
2. USB 2.0 extension on the dongle, away from USB 3 and the case. Costs almost nothing, may be enough.
3. If not: a mains-powered router near the device. Not five. One. Then wait 48 hours.
4. Only if host and Zigbee network have to stay physically apart: bring the coordinator to the devices with ser2net.
5. After that, check channels if Hue or a second Zigbee network is in play.

For me step 4 won, because step 3 wasn’t possible without an outdoor outlet. That’s the honest order — not the order I tried them in.