¿Por qué un router Zigbee fallido puede desconectar dispositivos de un servidor doméstico?

Un enrutador Zigbee fallido puede desconectar dispositivos seleccionados porque el enrutador puede estar haciendo más que extender el alcance de radio. Puede reenviar mensajes entre partes distantes de la malla y actuar como el padre que retiene mensajes para dispositivos finales alimentados por batería. Por lo tanto, eliminarlo puede romper una ruta, una relación padre-hijo o ambas.

El servidor doméstico puede continuar funcionando normalmente durante la falla. Home Assistant, Zigbee2MQTT y el coordinador pueden permanecer en línea mientras un sensor de movimiento, sensor de contacto o interruptor se vuelve inaccesible. Si esos dispositivos se recuperan depende de la topología de radio restante y de cómo cada pila Zigbee maneja la reparación de rutas o la reconexión.

Un enrutador Zigbee fallido rompe un camino de la malla, no el servidor doméstico

Un servidor doméstico inteligente local ejecuta la plataforma de automatización, integraciones, paneles y lógica de aplicaciones. El coordinador Zigbee es la interfaz de radio que forma una red Zigbee y conecta esa red al host. Un enrutador es otro nodo Zigbee, usualmente alimentado por la red eléctrica, que retransmite el tráfico y puede extender la cobertura más allá del alcance directo del coordinador.

La documentación oficial ZHA de Home Assistant distingue el hardware del coordinador de los roles de enrutador y dispositivo final. Esa separación explica el síntoma selectivo: un enrutador fallido puede eliminar la conectividad para una rama de la malla sin bloquear el host, detener el software de automatización o necesariamente desconectar el coordinador.

Los coordinadores, enrutadores y dispositivos finales fallan de manera diferente

El patrón de falla sigue el rol que desempeña un nodo. Un coordinador es la interfaz de radio central de la red, un enrutador participa en el reenvío de mensajes, y un dispositivo final normalmente se comunica a través de un padre en lugar de reenviar el tráfico de otros nodos. Estos roles deben identificarse antes de interpretar una lista de dispositivos fuera de línea.

La tabla describe roles de red, no una regla inflexible de producto. Algunos productos alimentados por corriente pueden no implementar el rol de router, y el firmware determina el comportamiento real. La pregunta práctica no es si un dispositivo parece un enchufe o una bombilla, sino si la red lo reconoce como router y si otros nodos dependen actualmente de él.

Los dispositivos de enrutamiento solo pueden reparar un camino roto cuando existe otra ruta

Cuando un mensaje unicast reconocido no llega a su destino, una pila Zigbee puede reintentar la entrega e iniciar la reparación de la ruta. La documentación oficial de enrutamiento Zigbee de Silicon Labs describe la reparación como un nuevo proceso de descubrimiento en el que el nodo dañado ya no participa. Si es accesible una secuencia diferente de routers, las tablas de enrutamiento pueden actualizarse para usar esa ruta.

La autocuración es, por lo tanto, un intento de encontrar conectividad válida, no una promesa de que cada dispositivo se reconecte inmediatamente. Si el router fallido era el único puente utilizable a través de una pared, piso o larga distancia, la red mallada no puede calcular un camino a través de radios que están fuera de alcance. La pila informa de la entrega fallida cuando no hay un camino alternativo disponible.

Los dispositivos finales en modo de suspensión pueden perder a su padre, no solo una ruta

Un dispositivo final Zigbee alimentado por batería puede estar en modo de suspensión durante la mayor parte de su ciclo operativo. Mientras duerme, su dispositivo padre permanece activo, almacena mensajes entrantes y responde a sondeos periódicos de datos. Silicon Labs explica esta relación de sondeo del padre: el hijo solicita mensajes retenidos de un solo padre en lugar de estar disponible continuamente para recibirlos directamente.

Si ese padre falla, la reparación normal de ruta entre enrutadores no restaura por sí sola la relación con el hijo. El dispositivo final primero debe reconocer fallos repetidos en la consulta y luego iniciar el comportamiento de reingreso implementado por su pila. Una implementación conforme puede buscar un nuevo padre adecuado, pero los intervalos de consulta, los umbrales de reintento, el comportamiento del firmware y cuándo el dispositivo despierta afectan la rapidez con que la recuperación se hace visible.

La cobertura redundante determina si la auto-reparación tiene éxito

La recuperación depende de varias condiciones que se resumen fácilmente en la vaga frase “la malla se auto-reparará.” La ubicación afectada debe seguir teniendo cobertura de radio, la red debe poder formar una ruta usable y un dispositivo final desplazado debe poder establecer una nueva relación con un padre.

Otro enrutador debe ser accesible desde la ubicación afectada

La redundancia existe solo cuando otro enrutador tiene un enlace confiable donde se necesita. Dos enrutadores junto al coordinador no proporcionan dos rutas a un sensor detrás de varias paredes densas. El nodo sobreviviente debe estar dentro de un camino de radio funcional de la rama afectada y conectado al resto de la malla.

Un padre restante debe tener una entrada libre en la tabla de hijos

Las tablas de padres y vecinos usan memoria finita. El número exacto de hijos directos lo determina la pila de radio, el firmware y la configuración del dispositivo, por lo que no se debe aplicar un límite universal de hijos a todos los coordinadores o enrutadores. Un enrutador accesible puede no ser adecuado como nuevo padre si su tabla de hijos no tiene entradas utilizables o si el enlace no cumple con los criterios de selección de la pila.

El dispositivo final debe iniciar o completar la reconexión

Los sensores en modo de suspensión no se registran todos en el mismo horario. Algunos se comunican con frecuencia; otros pueden permanecer en silencio hasta que cambie una medición o sea necesario un informe periódico. La red puede tener un padre de reemplazo disponible mientras el servidor aún no recibe un mensaje nuevo porque el dispositivo afectado no ha completado la reconexión ni enviado un informe.

El servidor puede permanecer en línea mientras los dispositivos Zigbee parecen no estar disponibles

“No disponible” en un panel de control es un juicio de la aplicación basado en la comunicación observada, no una medición directa de cada enlace de radio en cada momento. Un dispositivo puede perder a su padre antes de que expire el tiempo de espera del servidor, por lo que el último estado conocido puede permanecer visible aunque no se puedan transmitir nuevos comandos o informes. También es posible lo contrario después de un reinicio: un dispositivo puede ser accesible pero permanecer marcado como desconectado hasta que vuelva a registrarse.

Zigbee2MQTT documenta comportamientos de disponibilidad separados para dispositivos activos y pasivos. Los dispositivos activos pueden ser pingueados después de registros perdidos, mientras que los dispositivos pasivos con batería no pueden y se juzgan por un tiempo de espera de registro más largo. Aumentar ese tiempo de espera puede evitar etiquetas prematuras de fuera de línea, pero no puede reconstruir una ruta fallida ni darle a un sensor huérfano un nuevo padre.

La falla del coordinador y la interferencia RF pueden imitar un router perdido

Un grupo de dispositivos fuera de línea sugiere una dependencia compartida, pero no prueba que un router haya fallado. Compare el alcance, la geografía y el momento de la interrupción antes de cambiar la malla.

La falla del coordinador generalmente afecta a toda la red Zigbee

Si la plataforma de automatización es accesible pero casi todas las entidades Zigbee dejan de actualizarse juntas, inspeccione el coordinador y su conexión al host. Home Assistant señala que un coordinador necesita una conexión serial local estable porque la pérdida de paquetes y la latencia en un camino serial a IP inestable pueden interrumpir la comunicación. Ese límite de falla es diferente a perder un solo router descendente.

La interferencia de 2.4 GHz puede degradar varios enlaces a la vez

Zigbee, Wi-Fi y otras radios pueden compartir la banda ISM de 2.4 GHz. La guía de coexistencia de Silicon Labs indica que la operación simultánea puede degradar uno o más protocolos y aumentar la latencia o los reintentos. Un nuevo punto de acceso, un cambio de canal Wi-Fi o una mala ubicación del coordinador pueden hacer que varios dispositivos sean poco fiables sin que ningún router se apague.

Eliminar varios dispositivos alimentados por corriente puede colapsar la redundancia

Un evento de mantenimiento puede eliminar varios routers a la vez. Apagar un circuito de iluminación, desconectar un grupo de enchufes inteligentes o mover equipos puede eliminar tanto la ruta principal como su respaldo. Una red que se recuperó de un router perdido durante las pruebas puede fallar cuando varios nodos de enrutamiento cercanos desaparecen juntos.

Use el patrón de fallos para localizar la dependencia perdida en la malla

Comience con la correlación en lugar de un procedimiento universal de reinicio. Registre qué dispositivos dejaron de reportar, cuándo ocurrió el cambio y si los nodos afectados comparten una habitación o dirección física desde el coordinador. Luego compare ese patrón con los dispositivos Zigbee alimentados por corriente que perdieron energía o fueron movidos al mismo tiempo.

• Identifique dispositivos que dejaron de actualizarse al mismo tiempo.
• Verifique si las fallas se agrupan por habitación, piso o dirección.
• Busque un router Zigbee alimentado por red que haya sido apagado, desconectado o retirado.
• Separe las fallas de routers de las fallas de dispositivos finales con batería.
• Confirme que el coordinador y su conexión anfitriona siguen saludables.
• Revise la topología y los registros para entregas fallidas, reingresos o verificaciones repetidas de disponibilidad.

No asuma que emparejar un sensor cerca de un router fija permanentemente su ruta, ni cambie los temporizadores de disponibilidad para ocultar una pérdida real de comunicación. Si la cobertura es el factor limitante, agregue capacidad de enrutamiento confiable y siempre alimentada donde exista la rama débil y verifique la topología con el tiempo. Para la relación más amplia entre el software de automatización local y los servicios del servidor doméstico, vea esta visión general de la arquitectura de servidor inteligente local.

Preguntas frecuentes

¿Una malla Zigbee siempre se recupera después de que un router falla?

No. La reparación de ruta solo puede seleccionar un nuevo camino cuando existe una alternativa usable. Los dispositivos finales en modo de suspensión también pueden necesitar detectar la pérdida del padre y volver a unirse a través de otro padre adecuado. La cobertura de radio, la capacidad de la tabla, el comportamiento del firmware y el tiempo de registro pueden impedir o retrasar la recuperación.

¿Agregar más routers Zigbee siempre previene desconexiones?

No. Los routers adicionales mejoran la resiliencia solo cuando son confiables, están siempre alimentados, bien ubicados y son compatibles con la red circundante. Más routers cerca del coordinador pueden aportar poca protección a una zona muerta lejana, y los problemas de tabla o interferencia no se solucionan solo con la cantidad de dispositivos.

¿Aumentar el tiempo de espera de no disponible reconecta un dispositivo Zigbee?

No. El tiempo de espera cambia cuando el servidor etiqueta un dispositivo como desconectado; no repara la cobertura RF, no descubre una nueva ruta ni establece un nuevo padre. Un valor más largo puede reducir etiquetas falsas de desconexión para sensores de batería silenciosos, pero también puede retrasar la notificación de una interrupción real.

¿Es un router Zigbee lo mismo que un router Wi-Fi?

No. Un router Zigbee es un nodo dentro de una malla Zigbee que retransmite mensajes Zigbee y puede ser el padre de dispositivos finales. Un router Wi-Fi o punto de acceso sirve a un protocolo y red diferentes. Ambos pueden influenciarse mutuamente a través de interferencias de 2.4 GHz, pero no realizan el mismo papel de enrutamiento.