Zigbee-Netzwerk ist instabil: Diagnose von 50 Geräten

Zigbee-Netzwerk mit 50 Geräten diagnostizieren und stabilisieren: Praxisbeispiel

In einer engen Stadtwohnung mit 50 Zigbee-Geräten (Lampen, Sensoren, Relais, Rollläden) traten klassische Probleme auf: schlechte Verbindungsqualität (0–20 bei 20–30 Geräten), Verzögerungen in Lichtgruppen (0,5–3 Sekunden), verlorene Befehle, Leistungsabfall nachts und verpasste Bewegungsereignisse. Die Konfiguration umfasste viele Mesh-Router, einen WBE2R-R-ZIGBEE v.2-Koordinator in der Ecke, Wi-Fi-Router 3 Meter entfernt und benachbarte 2,4-GHz-Netze. Zunächst verbanden sich alle Geräte direkt (Permit join = all, z2m v2.5.1), aber das Mesh balancierte sich nicht selbst aus.

Topologie neu aufbauen: Vom Chaos zur sauberen Baumstruktur

Erster Schritt: Umstellung auf eine baumartige Struktur – nächste Router direkt am Koordinator, 1–2 pro Raum, andere darüber gekettet. Das entlastete den Koordinator von direkten Verbindungen und Routing-Tabellen und steigerte die Zuverlässigkeit. Die z2m-Netzwerkkarte zeigte optisch leichte Verbesserungen, aber die Symptome nahmen stark ab.

Physische Anpassungen (z. B. eine Metalltür eines Schranks) brachten kaum etwas – Verbindungsqualität verbesserte sich nur um 1–4 Punkte.

Engpässe bei der Datenverarbeitung aufdecken

Tieferes Graben enthüllte: Der CPU des Wiren Board Controllers war bei 380–400 % ausgelastet durch wb-rules und Systemskripte (/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js). Das blockierte die MQTT-Verarbeitung und führte zu Verzögerungen und verlorenen Events – unabhängig von der Verbindungsqualität.

Die Skripte abzuschaffen normalisierte die CPU-Last und behebt Glitches in Node-RED-Automatisierungen.

Funkkanal und Hardware optimieren

Wi-Fi-Scans zeigten Kanäle 1, 6 und 11 überlastet. Zigbee auf Kanal 26 (oberer 2,4-GHz-Bereich) mit 20 dBm tx_power zu schalten half etwas – Störungen waren nicht der Hauptschuldige.

Firmware-Update des Koordinators nach Wiren Board-Anleitung brachte marginale Gewinne, Foren raten aber dringend dazu (mit Einstellungs-Backup).

Das große Upgrade: Wechsel zu Sonoff Dongle Plus E (EFR32MG21) auf Raspberry Pi 5 mit Zigbee2MQTT v2.9.2. Koordinator zentral platziert, Kanal 11, transmit_power: 127. Node-RED auf dem Pi übernimmt MQTT-basierte Automatisierungen.

Zigbee2MQTT-Konfig:

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

Die Netzwerkkarte in v2.9.2 wurde extrem aufschlussreich, und der EFR32MG21 war deutlich stabiler als der CC2652P.

Wichtige Stabilisierungs-Schritte

• Topologie: Baumstruktur statt direkter Koordinator-Verbindungen.
• Datenverarbeitung: wb-rules-Skripte streichen, auf Pi mit Node-RED migrieren.
• Hardware: Zentrale Platzierung, Sonoff Dongle E, aktuelles z2m v2.9.2.
• Funk: Kanal 26/11, maximale tx_power, Wi-Fi-Scans.
• Überwachung: Verbindungsqualität, CPU-Last, MQTT-Logs tracken.

Wichtigste Erkenntnisse

• CPU-Überlast durch wb-rules-Skripte tarnt Funkprobleme als Zigbee-Instabilität.
• Koordinator in der Ecke erzeugt zu viele 'lange' Mesh-Hops.
• Baum-Topologie entlastet den Koordinator bei über 50 Geräten.
• EFR32MG21 (Sonoff) schlägt CC2652P in überlasteter Luft.
• z2m 2.9.2 + Pi5 überwindet Limitierungen alter Hardware.

Wahre Stabilität entsteht durch Kombination aus Topologie-Anpassungen, Hardware-Upgrades und Beseitigung von Software-Engpässen.

— Editorial Team