Programación de recursos de Home Assistant: por qué las interrupciones de Internet cambian el comportamiento del control local

Una interrupción de Internet no hace que las automatizaciones locales de Home Assistant fallen automáticamente. Las integraciones locales de Zigbee, Z-Wave, Matter, ESPHome, MQTT y LAN pueden seguir funcionando mientras la WAN está caída. Lo que cambia es la carga de trabajo que las rodea: las solicitudes a la nube agotan el tiempo de espera, las integraciones reintentan, las búsquedas DNS fallan, las conexiones remotas desaparecen y las tareas de recuperación pueden llegar en ráfagas cuando vuelve la conectividad.

Por eso, la programación de recursos importa durante una interrupción incluso cuando la ruta de control local sigue intacta. La pregunta no es «¿Home Assistant necesita Internet?», sino si el trabajo remoto fallido permanece aislado o empieza a consumir tiempo del bucle de eventos, hilos del ejecutor, capacidad de DNS, E/S de registro o recargas de integraciones que se solapan con el control local.

Las solicitudes fallidas a la nube convierten las rutas rápidas de éxito en rutas de espera

Cuando la WAN funciona correctamente, una solicitud a la nube puede completarse rápidamente. Durante una interrupción, la misma llamada puede ocupar su ventana de tiempo de espera, reintentar y registrar un error antes de devolver el control. Unas pocas llamadas son inofensivas; muchas integraciones haciendo esto al mismo tiempo crean un perfil de programación distinto al funcionamiento normal.

El ciclo de vida de las entradas de configuración de Home Assistant tiene un estado explícito de setup retry para dependencias que no están listas, y el intervalo entre intentos automáticos aumenta con el tiempo. El modo exacto de fallo sigue dependiendo de cada integración, pero el trabajo de reintento es una parte definida del funcionamiento degradado, no un caso límite excepcional.

Evita que las automatizaciones críticas esperen una API remota antes de ejecutar la acción local. Envía la notificación, la actualización en la nube o el webhook externo después de la acción física cuando ese resultado remoto no sea necesario para decidir qué debe hacer la casa.

Los tiempos de espera de red pueden retener recursos incluso sin un uso elevado de la CPU

Una operación de red bloqueada puede mostrar poco uso de CPU y, aun así, ocupar una tarea, conexión, hilo o presupuesto de tiempo de espera. Por eso, que «la CPU esté solo al 10 %» no demuestra que una interrupción no tenga ningún coste.

Un caso de Home Assistant de 2026 atribuyó los tiempos de espera repetidos de una integración y las recargas en cascada a una ruta IPv6 defectuosa que permitía que las conexiones esperaran en lugar de fallar rápidamente. El síntoma era un retraso de programación alrededor de las llamadas de red, no un agotamiento de la capacidad de cálculo.

Observa las tareas de red pendientes, las advertencias de las integraciones, los fallos de DNS y el tiempo entre el disparador y la llamada al servicio local. Si las acciones locales siguen siendo rápidas mientras las entidades en la nube dejan de estar disponibles, la interrupción está correctamente aislada. Si la latencia local aumenta junto con las llamadas remotas fallidas, identifica la integración o el código personalizado que está ocupando el entorno de ejecución compartido.

El trabajo bloqueante es más peligroso que la espera asíncrona

El núcleo de Home Assistant es asíncrono, por lo que las integraciones bien diseñadas pueden suspenderse mientras esperan E/S y permitir que se ejecuten otras tareas. El caso peligroso es el trabajo bloqueante que ocupa el propio bucle de eventos o el código personalizado que realiza operaciones de red síncronas en el lugar equivocado.

La guía para desarrolladores de Home Assistant explica que una operación bloqueante en el bucle de eventos impide que se ejecute otro trabajo hasta que termina. Una interrupción de Internet puede dejar al descubierto esta debilidad porque una llamada que normalmente devuelve el control de inmediato puede esperar de repente durante un tiempo de espera prolongado.

Por eso, una integración personalizada puede hacer que una interrupción parezca una ralentización de toda la plataforma aunque las integraciones locales nativas sigan estando bien diseñadas. Compara el comportamiento con los componentes personalizados desactivados antes de culpar al hardware.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

La recuperación puede crear un segundo pico de carga de trabajo

Cuando vuelve la conectividad a Internet, varias integraciones pueden reconectarse, actualizar el estado, volver a autenticarse, actualizar entidades y escribir nuevo historial casi al mismo tiempo. Por tanto, la ventana de recuperación puede estar más ocupada que la parte central de la interrupción.

No consideres que un pico de CPU, red o escrituras del Recorder inmediatamente después de que vuelva la WAN demuestra que la capacidad normal sostenida es insuficiente. Mide cuánto dura el pico y si la latencia del control local vuelve después a su nivel de referencia.

El artículo de ZimaSpace sobre los mensajes retenidos, en cola, de descubrimiento y de disponibilidad después de una reconexión muestra el mismo principio de recuperación: la reconexión de componentes distribuidos puede reproducir estados y crear trabajo que no existía mientras la conexión era estable.

Programa el modo degradado, no solo el modo normal

Durante una pérdida de la WAN, las rutas locales de movimiento a iluminación deben seguir funcionando sin un requisito remoto. El sondeo en la nube puede pasar a reintentos acotados, las notificaciones remotas pueden fallar o ponerse en cola, los servicios que dependen de DNS deben fallar de forma predecible y el restablecimiento de la conectividad puede crear una breve ráfaga de actualización.

El objetivo de diseño es una degradación selectiva: el trabajo remoto opcional se vuelve más lento o desaparece, mientras el control local se mantiene dentro de su intervalo de tiempo normal. La prueba más completa de una interrupción consiste en desconectar la WAN durante una carga doméstica normal, medir algunas automatizaciones locales críticas, volver a conectarla y medir tanto la ráfaga de recuperación como el tiempo necesario para regresar al nivel de referencia.

Preguntas frecuentes

¿Una interrupción de Internet hace que las automatizaciones locales de Home Assistant sean más lentas?

No necesariamente. Una automatización completamente local puede continuar a la velocidad normal. Se vuelve más lenta cuando el trabajo fallido de la nube, DNS, las integraciones personalizadas o la red compartida consume recursos en la misma ruta crítica.

¿Debo añadir reintentos agresivos para que las integraciones en la nube se recuperen más rápido?

No. Los reintentos agresivos pueden amplificar una interrupción y crear trabajo innecesario. Es preferible utilizar un comportamiento de reintento acotado y mantener la recuperación de la nube fuera de la ruta temporal de las automatizaciones locales críticas.