Réseau Zigbee instable : diagnostic de 50 appareils

# Diagnostic et stabilisation d'un réseau Zigbee avec 50 appareils : Étude de cas réelle

Dans un petit appartement citadin bondé de 50 appareils Zigbee (lumières, capteurs, relais, volets), les problèmes classiques ont surgi : qualité de liaison médiocre (0–20 sur 20–30 appareils), délais dans les groupes d’éclairage (0,5–3 secondes), commandes perdues, performances dégradées la nuit, et événements de capteurs de mouvement manqués. L’installation comptait de nombreux routeurs maillés, un coordinateur WBE2R-R-ZIGBEE v.2 planqué dans un coin, un routeur Wi-Fi à 3 mètres, et des réseaux voisins en 2,4 GHz. Au départ, tous les appareils se connectaient directement (Permit join = all, z2m v2.5.1), mais le maillage ne s’équilibrait pas tout seul.

Reconstruction de la topologie : Du chaos à une structure arborescente propre

Première étape : passer à une structure arborescente — routeurs les plus proches directement sur le coordinateur, 1–2 par pièce, les autres en chaîne derrière eux. Cela a déchargé le coordinateur des connexions directes et des tables de routage, boostant la fiabilité. La carte réseau z2m montrait des améliorations modestes visuellement, mais les symptômes ont chuté brutalement.

Les ajustements physiques (comme une porte de placard métallique) ont à peine bougé les lignes — qualité de liaison améliorée de 1–4 points seulement.

Débusquage des goulots d’étranglement en traitement de données

En creusant plus loin, on a découvert que le CPU du contrôleur Wiren Board était surchargé à 380–400 % à cause des wb-rules et scripts système (/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js). Cela bloquait le traitement MQTT, causant délais et événements perdus, indépendamment de la qualité de liaison.

Supprimer ces scripts a normalisé la charge CPU et résolu les bugs dans les automatisations Node-RED.

Optimisation du canal radio et du matériel

Les scans Wi-Fi montraient les canaux 1, 6 et 11 saturés. Passer Zigbee sur le canal 26 (haut de la bande 2,4 GHz) avec tx_power 20 dBm a un peu aidé — les interférences n’étaient pas le principal coupable.

Mettre à jour le firmware du coordinateur selon les guides Wiren Board a donné des gains minimes, mais les forums le considèrent indispensable (avec sauvegarde des paramètres).

Le gros upgrade : passage à un Sonoff Dongle Plus E (EFR32MG21) sur Raspberry Pi 5 avec Zigbee2MQTT v2.9.2. Coordinateur placé au centre, canal 11, transmit_power : 127. Node-RED sur le Pi gère les automatisations basées sur MQTT.

Config 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

La carte réseau en v2.9.2 est devenue super claire, et l’EFR32MG21 s’est révélé bien plus stable que le CC2652P.

Étapes clés de stabilisation

• Topologie : Structure arborescente plutôt que connexions directes au coordinateur.
• Gestion des données : Abandonner les scripts wb-rules, migrer vers Pi avec Node-RED.
• Matériel : Placement central, Sonoff Dongle E, dernier firmware z2m v2.9.2.
• Radio : Canal 26/11, tx_power max, scans Wi-Fi.
• Suivi : Surveiller qualité de liaison, charge CPU, logs MQTT.

Leçons principales

• La surcharge CPU due aux scripts wb-rules masque les problèmes radio en instabilité Zigbee.
• Placer le coordinateur dans un coin crée trop de sauts maillés « longs ».
• La topologie arborescente décharge le coordinateur au-delà de 50 appareils.
• EFR32MG21 (Sonoff) surpasse le CC2652P dans un environnement encombré.
• z2m 2.9.2 + Pi5 surmonte les limites du matériel legacy.

La vraie stabilité vient de la combinaison d’ajustements topologiques, upgrades matériels et débouchage des goulots logiciels.

— Editorial Team