Zigbee network is unstable: diagnosing 50 devices

Diagnosing and Stabilizing a Zigbee Network with 50 Devices: Real-World Case Study

In a cramped city apartment packed with 50 Zigbee devices (lights, sensors, relays, blinds), classic issues cropped up: poor link quality (0–20 on 20–30 devices), delays in lighting groups (0.5–3 seconds), dropped commands, worsening performance at night, and missed motion sensor events. The setup featured plenty of mesh routers, a WBE2R-R-ZIGBEE v.2 coordinator tucked in the corner, Wi-Fi router 10 feet away, and neighboring 2.4 GHz networks. Initially, all devices connected directly (Permit join = all, z2m v2.5.1), but the mesh didn't self-balance.

Rebuilding the Topology: From Chaos to a Clean Tree Structure

First step: switch to a tree-like structure—closest routers directly to the coordinator, 1–2 per room, others chained through them. This offloaded the coordinator from direct connections and routing tables, boosting reliability. The z2m network map showed modest improvements visually, but symptoms dropped off sharply.

Physical tweaks (like a metal cabinet door) barely moved the needle—link quality shifted just 1–4 points.

Uncovering Data Processing Bottlenecks

Digging deeper revealed the Wiren Board controller's CPU overloaded at 380–400% from wb-rules and system scripts (/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js). This jammed MQTT processing, causing delays and lost events regardless of link quality.

Ditching those scripts normalized CPU load and fixed glitches in Node-RED automations.

Optimizing the Radio Channel and Hardware

Wi-Fi scans showed channels 1, 6, and 11 clogged. Switching Zigbee to channel 26 (top of the 2.4 GHz band) with 20 dBm tx_power helped a bit—interference wasn't the main culprit.

Updating the coordinator firmware per Wiren Board guides gave marginal gains, but forums call it a must-do (with settings backup).

The big upgrade: swapped to a Sonoff Dongle Plus E (EFR32MG21) on a Raspberry Pi 5 running Zigbee2MQTT v2.9.2. Placed the coordinator dead center, channel 11, transmit_power: 127. Node-RED on the Pi handles MQTT-based automations.

Zigbee2MQTT config:

version: 4
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://localhost:1883
serial:
  port: /dev/ttyUSB0
  adapter: ember
  baudrate: 115200
  rtscts: false
advanced:
  log_level: info
  channel: 11
  network_key: GENERATE
  pan_id: GENERATE
  ext_pan_id: GENERATE
  transmit_power: 127
frontend:
  enabled: true
  port: 8080
  dashboard: false
homeassistant:
  enabled: false

The network map in v2.9.2 became super insightful, and the EFR32MG21 proved way more stable than the CC2652P.

Key Stabilization Steps

• Topology: Tree structure over direct coordinator links.
• Data Handling: Ditch wb-rules scripts, migrate to Pi with Node-RED.
• Hardware: Central placement, Sonoff Dongle E, latest z2m v2.9.2 firmware.
• Radio: Channel 26/11, max tx_power, Wi-Fi scans.
• Monitoring: Track link quality, CPU load, MQTT logs.

Key Takeaways

• CPU overload from wb-rules scripts hides radio issues as Zigbee instability.
• Corner-placing the coordinator creates too many 'long' mesh hops.
• Tree topology unburdens the coordinator beyond 50 devices.
• EFR32MG21 (Sonoff) outperforms CC2652P in crowded airwaves.
• z2m 2.9.2 + Pi5 overcomes legacy hardware limits.

True stability comes from combining topology tweaks, hardware upgrades, and clearing software bottlenecks.

— Editorial Team