# Diagnóstico y estabilización de una red Zigbee con 50 dispositivos: Estudio de caso real
En un apartamento urbano pequeño repleto de 50 dispositivos Zigbee (luces, sensores, relés, persianas), surgieron los problemas clásicos: baja calidad de enlace (0–20 en 20–30 dispositivos), retrasos en grupos de luces (0,5–3 segundos), comandos perdidos, peor rendimiento por la noche y eventos de sensores de movimiento omitidos. La configuración incluía varios routers mesh, un coordinador WBE2R-R-ZIGBEE v.2 en una esquina, router Wi-Fi a 3 metros y redes vecinas en 2,4 GHz. Inicialmente, todos los dispositivos se conectaban directamente (Permit join = all, z2m v2.5.1), pero el mesh no se equilibraba solo.
Reconstruyendo la topología: Del caos a una estructura arbórea limpia
Primer paso: cambiar a una estructura en árbol —routers más cercanos directamente al coordinador, 1–2 por habitación, los demás encadenados a través de ellos. Esto alivió al coordinador de conexiones directas y tablas de enrutamiento, mejorando la fiabilidad. El mapa de red de z2m mostró mejoras visuales modestas, pero los síntomas se redujeron drásticamente.
Ajustes físicos (como una puerta de armario metálico) apenas movieron la aguja: la calidad de enlace varió solo 1–4 puntos.
Descubriendo cuellos de botella en el procesamiento de datos
Al indagar más profundo, se reveló que el CPU del controlador Wiren Board estaba sobrecargado al 380–400% por wb-rules y scripts del sistema (/usr/share/wb-rules-system/rules/wb-zigbee2mqtt.js). Esto atascaba el procesamiento MQTT, causando retrasos y eventos perdidos independientemente de la calidad de enlace.
Eliminar esos scripts normalizó la carga del CPU y corrigió fallos en las automatizaciones de Node-RED.
Optimizando el canal de radio y el hardware
Escaneos Wi-Fi mostraron canales 1, 6 y 11 saturados. Cambiar Zigbee al canal 26 (parte superior de la banda 2,4 GHz) con tx_power de 20 dBm ayudó un poco: la interferencia no era el principal culpable.
Actualizar el firmware del coordinador según las guías de Wiren Board dio ganancias marginales, pero los foros lo consideran imprescindible (con respaldo de configuraciones).
La gran mejora: cambiar al Sonoff Dongle Plus E (EFR32MG21) en una Raspberry Pi 5 con Zigbee2MQTT v2.9.2. Colocar el coordinador en el centro, canal 11, transmit_power: 127. Node-RED en la Pi maneja automatizaciones basadas en MQTT.
Configuración de 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: falseEl mapa de red en v2.9.2 se volvió muy revelador, y el EFR32MG21 demostró ser mucho más estable que el CC2652P.
Pasos clave para la estabilización
- Topología: Estructura en árbol en lugar de enlaces directos al coordinador.
- Manejo de datos: Eliminar scripts wb-rules, migrar a Pi con Node-RED.
- Hardware: Colocación central, Sonoff Dongle E, firmware z2m v2.9.2 más reciente.
- Radio: Canal 26/11, tx_power máximo, escaneos Wi-Fi.
- Monitoreo: Rastrear calidad de enlace, carga CPU, logs MQTT.
Lecciones clave
- La sobrecarga de CPU por scripts wb-rules enmascara problemas de radio como inestabilidad Zigbee.
- Colocar el coordinador en una esquina genera demasiados saltos mesh 'largos'.
- La topología en árbol alivia al coordinador con más de 50 dispositivos.
- EFR32MG21 (Sonoff) supera al CC2652P en entornos con aire saturado.
- z2m 2.9.2 + Pi5 supera los límites del hardware legacy.
La verdadera estabilidad surge de combinar ajustes de topología, mejoras de hardware y eliminación de cuellos de botella en software.
— Editorial Team
Aún no hay comentarios.