Sieć Zigbee niestabilna: diagnostyka 50 urządzeń

Diagnostyka i stabilizacja sieci Zigbee z 50 urządzeniami: praktyczny przypadek

W ciasnym mieszkaniu miejskim z 50 urządzeniami Zigbee (oświetlenie, czujniki, przekaźniki, rolety) wystąpiły typowe problemy: niski linkquality (0–20 u 20–30 urządzeń), opóźnienia w grupach oświetleniowych (0,5–3 s), gubienie komend, pogorszenie wieczorem i utrata zdarzeń z czujników ruchu. Sieć obejmowała wiele routerów mesh, koordynator WBE2R-R-ZIGBEE v.2 w rogu, Wi-Fi w odległości 3 m i sąsiednie sieci 2,4 GHz. Początkowo wszystkie urządzenia połączyły się bezpośrednio (Permit join = wszystkie, z2m v2.5.1), ale mesh nie balansował się samoczynnie.

Przebudowa topologii: od chaosu do struktury drzewa

Pierwszy krok — zmiana na strukturę drzewiastą: najbliższe routery bezpośrednio do koordynatora, po 1–2 na pokój, pozostałe przez nie. To odciążyło koordynator od bezpośrednich połączeń i tabel routingu, zwiększając stabilność. Mapa sieci w z2m słabo wizualizowała poprawy, ale objawy zmalały.

Testy fizyczne (metalowe drzwi szafy) nie dały efektu — linkquality zmieniał się o 1–4 punkty.

Odkrycie wąskich gardeł w przetwarzaniu danych

Analiza wykazała przeciążenie CPU kontrolera Wiren Board do 380–400% przez wb-rules i systemowe skrypty (/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js). To blokowało przetwarzanie MQTT, powodując opóźnienia i utratę zdarzeń niezależnie od linkquality.

Usunięcie skryptów znormalizowało obciążenie, eliminując anomalie w scenariuszach node-red.

Optymalizacja kanału radiowego i sprzętu

Skanowanie Wi-Fi ujawniło obciążenie kanałów 1, 6, 11. Przejście na kanał Zigbee 26 (góra pasma 2,4 GHz) z tx_power 20 dBm dało minimalny efekt — zakłócenia nie były główną przyczyną.

Aktualizacja firmware koordynatora wg instrukcji Wiren Board poprawiła marginalnie, ale fora polecają to jako podstawowy krok (z backupem ustawień).

Ostateczny upgrade: wymiana na Sonoff Dongle Plus E (EFR32MG21) na Raspberry Pi 5 z Zigbee2MQTT v2.9.2. Koordynator w centrum mieszkania, kanał 11, transmit_power: 127. Node-RED na Pi do automatyki via MQTT.

Konfiguracja Zigbee2MQTT:

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

Mapa sieci w v2.9.2 stała się informacyjna, EFR32MG21 pokazał stabilność w porównaniu do CC2652P.

Kluczowe działania stabilizujące

• Topologia: struktura drzewiasta zamiast bezpośrednich połączeń do koordynatora.
• Przetwarzanie danych: usunięcie skryptów wb-rules, migracja na Pi z Node-RED.
• Sprzęt: umieszczenie w centrum, Sonoff Dongle E, świeża wersja z2m v2.9.2.
• Radio: kanał 26/11, maksymalny tx_power, skan Wi-Fi.
• Monitorowanie: linkquality, obciążenie CPU, logi MQTT.

Co najważniejsze

• Przeciążenie CPU przez skrypty wb-rules maskuje problemy radiowe pod niestabilnością Zigbee.
• Umieszczenie koordynatora w rogu wydłuża „długie” trasy w mesh.
• Struktura drzewiasta odciąża koordynator przy >50 urządzeniach.
• EFR32MG21 (Sonoff) jest stabilniejszy od CC2652P w zatłoczonym eterze.
• Wersja z2m 2.9.2 + Pi5 rozwiązuje ograniczenia starszych platform.

Stabilność osiąga się kombinacją: optymalizacja topologii, upgrade sprzętowy i oczyszczenie wąskich gardeł programowych.

— Editorial Team