¿Qué causa el retraso del control local en Home Assistant durante las interrupciones de Internet?

El control local retrasado de Home Assistant durante una interrupción de Internet suele significar que una ruta supuestamente local todavía espera una dependencia de la WAN o trabajo acumulado.

Empieza separando la llegada del disparador de la finalización de la acción: si el sensor de movimiento cambia de inmediato, pero la luz actúa tarde, la ruta del evento está activa y el retraso se encuentra más adelante en la cadena. Si la entidad objetivo deja de estar disponible, el problema está en una capa inferior de la ruta del dispositivo; trata la interrupción como una variable controlada e identifica la primera etapa cuya latencia cambia.

La causa raíz suele ser una dependencia oculta en la ruta de control

Una instalación de Home Assistant puede ser local a nivel del servidor, mientras que determinadas entidades, nombres, notificaciones o servicios auxiliares siguen dependiendo de Internet. El usuario percibe una sola pulsación de botón, pero esa solicitud puede atravesar un panel local, un resolvedor de nombres, el bucle de eventos de Home Assistant, una integración, una API del proveedor y, finalmente, un dispositivo físico. Basta con una sola etapa dependiente de la WAN para retrasar toda la acción visible.

Un artículo sobre arquitectura local por defecto señala lo mismo al distinguir el control esencial del hogar de las funciones WAN opcionales; las rutas de control con prioridad local solo siguen siendo fiables cuando la cadena del sensor a la acción permanece dentro del hogar. Las notificaciones remotas, el tiempo y los servicios de los proveedores pueden fallar por separado sin bloquear la luz o la cerradura.

No empieces cambiando la CPU, la base de datos o los ajustes de automatización. Primero registra con una marca de tiempo el estado del sensor, el inicio de la automatización, cada paso de la acción, la llamada al servicio objetivo y la confirmación del estado del dispositivo. El primer intervalo que se amplía únicamente cuando la WAN no está disponible identifica la clase de dependencia que merece investigación.

Las cuatro causas del retraso local relacionado con una interrupción

La división más útil distingue entre una acción en la nube lenta, un nombre o una ruta local que depende en secreto de la infraestructura WAN, una integración de dispositivo mediada por la nube y una cola creada por trabajos fallidos anteriores. Estas causas pueden parecer idénticas desde el panel, porque las cuatro terminan produciendo un resultado local tardío.

Una investigación de la comunidad observó que Home Assistant se volvía lento cuando las integraciones en la nube tenían conexiones deficientes o inexistentes, lo que ofrece un ejemplo real de cómo un fallo de la nube afecta a la capacidad de respuesta. La observación es útil porque separa la presencia de Core local del comportamiento de las integraciones a las que Core está esperando.

Usa las señales siguientes como hipótesis, no como etiquetas definitivas. Reproduce la misma acción local con la WAN activa y desconectada, y después elimina solo una dependencia sospechosa cada vez. Una causa queda confirmada cuando la etapa modificada y el retraso visible para el usuario cambian conjuntamente, mientras el resto de la ruta de control permanece constante.

Causa 1: Una acción en la nube mantiene abierta la ejecución

• Mecanismo: un disparador local llega a una acción dependiente de la nube que espera a que se agote el tiempo de espera o a que se reintente.
• Señal: los cambios de estado locales llegan a tiempo, pero el registro de la automatización se detiene en una llamada remota.
• SI–ENTONCES: si eliminar esa llamada restablece el tiempo de respuesta durante la misma interrupción, el paso en la nube retrasado es la causa.

Causa 2: La resolución del nombre o de la ruta local también depende de la WAN

• Mecanismo: los clientes o las integraciones utilizan rutas de DNS, proxy o enrutamiento que terminan saliendo de la LAN.
• Señal: el acceso directo mediante IP local es rápido, mientras que el nombre de host habitual o la ruta enrutada se detienen.
• SI–ENTONCES: si un nombre y una ruta completamente locales eliminan el retraso, la lógica de control era local, pero la ruta de acceso no.

Causa 3: Un dispositivo local en realidad está mediado por la nube

• Mecanismo: la entidad mostrada en Home Assistant representa una API del proveedor en lugar de un punto final directo de la LAN o de radio.
• Señal: la automatización se activa, pero la entidad objetivo deja de estar disponible o solo se actualiza después de recuperar Internet.
• SI–ENTONCES: si un objetivo local Zigbee, Z-Wave, ESPHome u otro sigue respondiendo mientras este dispositivo no lo hace, la causa está en el límite de la integración.

Causa 4: El trabajo acumulado durante la interrupción retrasa las ejecuciones locales posteriores

• Mecanismo: el trabajo en cola o paralelo creado durante la interrupción consume los mismos recursos de automatización o del host después del primer fallo.
• Señal: las acciones totalmente locales solo se retrasan después de que se hayan acumulado varios intentos remotos fallidos.
• SI–ENTONCES: si vaciar o impedir la acumulación restablece la latencia local, el retraso secundario se debe a la espera en cola y no al protocolo local.

Distingue la pérdida de Internet de la pérdida de la red local

Una interrupción de Internet no debe confundirse con la pérdida del router, el punto de acceso Wi-Fi, el conmutador Ethernet, el DNS local, el coordinador Zigbee o el host de Home Assistant. Si la LAN está degradada, el control local puede fallar aunque el diseño no contenga ninguna dependencia de la nube. La prueba de interrupción debe mantener encendida y accesible la infraestructura local, eliminando únicamente la ruta de Internet ascendente.

Una guía reciente sobre Home Assistant con prioridad local describe exactamente esta separación y destaca que el control local es un diseño de dependencias, no simplemente el hecho de que Home Assistant se ejecute en casa. Las radios locales, las API de la LAN, el DNS y el controlador también deben sobrevivir de forma independiente de la WAN.

Si el acceso directo mediante IP local, los dispositivos de radio y los servicios locales siguen siendo rápidos mientras solo el nombre de host habitual funciona lentamente, prueba la resolución DNS y del proxy antes de modificar las automatizaciones. Si el propio Home Assistant pierde accesibilidad desde la LAN, el problema no es una interrupción exclusiva de Internet y debe trasladarse a la capa de red local o del host.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Realiza una prueba de aislamiento con cuatro marcas de tiempo

Elige una automatización sencilla con un sensor local y un actuador local. Un flujo de depuración basado en registros actual puede capturar el disparador, las condiciones, los datos de acción procesados y el tiempo de cada paso; combínalo con la confirmación observada del estado del dispositivo. Repite la prueba diez veces con Internet disponible y después diez veces con la WAN bloqueada mientras la LAN permanece intacta, comparando la mediana y las ejecuciones más lentas en lugar de una sola pulsación anecdótica.

ZimaSpace muestra cómo una aplicación aparentemente rápida en la LAN puede detenerse antes de la ruta de la aplicación porque la latencia del DNS puede aparecer antes del inicio de la conexión. El mismo principio de aislamiento se aplica aquí: cronometra cada etapa para no confundir un retraso de resolución de nombres con un retraso en la ejecución de la automatización.

Da por válido el diseño de control local cuando eliminar la WAN no cambie de forma significativa el intervalo entre el disparador y el dispositivo local, y las tareas en la nube fallidas no puedan crear una acumulación que bloquee después la ruta local. Si una marca de tiempo se amplía, corrige primero esa dependencia. No aumentes la concurrencia, cambies las bases de datos ni sustituyas el hardware hasta que las pruebas de tiempo demuestren que esos recursos están realmente implicados.