Publicado el 05/09/2026 · Última revisión: 05/09/2026

Home Assistant sin internet: qué sigue funcionando y qué preparar antes del corte

Si tu casa domótica se apaga cuando se cae Internet, no es que dependas de la nube: es que tu instalación entera es una nube con otro nombre. La diferencia entre una casa local-first y un juguete conectado se nota justo en el corte: qué luces sigues pudiendo apagar y cuáles se quedan encendidas hasta que la operadora vuelva.

Esquema de un corte de WAN: la nube queda inaccesible pero la red local con Home Assistant, los dispositivos Zigbee y el altavoz siguen comunicándose entre sí

Qué sigue funcionando sin WAN

La regla general es simple: lo que habla por tu red local sigue vivo; lo que necesita un servidor fuera de casa, no. Pero dentro de esa regla hay trampas que conviene ver antes del corte, no durante.

Componente	¿Funciona sin WAN?	Por qué
Automatizaciones con trigger local	Sí	Se ejecutan dentro de Home Assistant. No necesitan servidor externo.
Zigbee, Z-Wave, Matter local y ESPHome	Sí	Toda la comunicación es por tu red local (coordinador, IP LAN o radio).
Luces y enchufes con integración local	Sí, con matiz	Una bombilla Hue por API local del bridge funciona; la misma bombilla si depende del cloud de Philips, no.
App del móvil dentro de casa	Depende	Si entras por Nabu Casa o un túnel cloud, no. Si apuntas a la IP local de tu instancia, sí.
Notificaciones push, Telegram, WhatsApp	No	Todas acaban saliendo a un servidor externo. Llegan cuando vuelve la conexión.
Asistente de voz con motor en nube	No	Si el reconocimiento o la síntesis ocurre fuera, el asistente se queda mudo. Un motor local tipo Piper sigue respondiendo.
Pronóstico del tiempo, precios de energía, actualizaciones	No	Son datos que vienen de fuera. No rompen nada: se quedan con el último valor.
Control desde fuera de casa	Depende	Nabu Casa es cloud y cae con la WAN de tu casa. Una VPN propia al revés: funciona si el sitio desde el que te conectas tiene internet.

El matiz de las integraciones es donde más gente se lleva la sorpresa. “Tengo todo en Home Assistant” no significa “todo es local”: si añadiste la bombilla por el cloud de la marca, el día del corte esa bombilla depende de un servidor que no puedes tocar. El test que hago con cada integración nueva es sencillo y está en el YAML: ¿esta entidad cambia de estado aunque tire el cable del router? Si no, es cloud y la trato como tal.

El fallo que casi nadie ha probado hasta que ocurre

Escenario típico, reconstruido a partir de casos que se repiten en foros: un corte de fibra a las nueve de la mañana que la operadora dice que durará “unos minutos” y dura una hora. En una casa con Home Assistant bien montado, lo que ocurre es esto: las luces del salón siguen respondiendo al interruptor físico, la automatización del pasillo se dispara a su hora porque el trigger es local, el sensor de presencia sigue encendiendo la luz del baño. Lo que no ocurre es que puedas avisar por Telegram, ni preguntar el tiempo por voz, ni abrir la app fuera de casa si entrabas por Nabu Casa.

El fallo silencioso es otro. Si tu coordinador Zigbee cuelga de un stick USB enchufado al mismo router que recibe la fibra, un corte de luz o un reinicio del router se lleva por delante la red Zigbee entera, aunque Home Assistant esté en una máquina con batería. La topología de la red importa más que el software: el día del corte descubres qué alimentación tenía cada pieza. Por eso, si tu red depende de un USB en el router, la migración a un coordinador de red con alimentación propia deja de ser comodidad y pasa a ser plan de contingencia.

Un sensor local de “sin internet”

Lo primero es poder medir el corte sin depender de servicios externos que también pueden caerse. Un binary_sensor con la plataforma ping es lo más directo: Home Assistant hace ping a una IP y te dice si hay WAN.

Un detalle de diseño: no uses como única sonda tu propio router. Tu router puede estar vivo y respondiendo sin tener WAN, y entonces tu sensor de internet te dirá “todo bien” mientras la casa está aislada. Es mejor hacer ping a una IP fuera de tu red, y si quieres evitar falsos positivos, a dos:

binary_sensor:
  - platform: ping
    name: "Internet (1.1.1.1)"
    host: 1.1.1.1
    count: 2
    scan_interval: 60
  - platform: ping
    name: "Internet (8.8.8.8)"
    host: 8.8.8.8
    count: 2
    scan_interval: 60

template:
  - binary_sensor:
      - name: "Internet caída"
        unique_id: internet_caida
        device_class: connectivity
        state: >
          {{ is_state('binary_sensor.internet_1_1_1_1', 'off')
             and is_state('binary_sensor.internet_8_8_8_8', 'off') }}
        availability: >
          {{ not is_state('binary_sensor.internet_1_1_1_1', 'unavailable')
             and not is_state('binary_sensor.internet_8_8_8_8', 'unavailable') }}

El sensor plantilla solo se pone en on cuando las dos sondas fallan a la vez. Así un microcorte en una ruta o un proveedor que bloquea un ping puntual no te dispara la automatización entera.

Qué hacer cuando salta

El error típico es querer avisar con una notificación push. Da igual lo bonito que sea el mensaje: si la notificación necesita la nube, no llegará hasta después del corte, que es justo cuando ya no hace falta. El aviso de un corte tiene que ser local, por un canal que no dependa de la WAN.

automation:
  - alias: "Aviso de corte de internet prolongado"
    triggers:
      - trigger: state
        entity_id: binary_sensor.internet_caida
        to: "on"
        for: "00:05:00"
    actions:
      - action: tts.speak
        data:
          media_player_entity_id: media_player.salon
          message: "Se ha caído la conexión a internet. La domótica local sigue funcionando."
    mode: single

El for: "00:05:00" es clave: sin él, cualquier microcorte de treinta segundos te suelta el aviso por los altavoces. Con cinco minutos de margen solo habla cuando el corte es de verdad. Si no tienes un motor de voz local, la alternativa igual de válida es encender una luz de un color distinto cinco minutos después del corte: menos espectacular, pero igual de informativo y sin depender de nada externo.

Checklist antes del próximo corte

Separa alimentaciones: Home Assistant, router y coordinador de red no deberían compartir el mismo transformador si quieres que algo sobreviva a un apagón con corte.
Prueba el acceso local desde el móvil: desactiva el Wi-Fi del móvil, actívalo solo en tu red y abre la app apuntando a la IP local. Si nunca lo has probado, el día del corte no vas a aprenderlo.
Revisa qué integraciones son cloud de verdad: cada entidad cuyo estado dependa de un servidor externo es una candidata a sustituirse por una versión local. No hace falta cambiarlas todas hoy; hace falta saber cuáles son.
Monta la sonda y la automatización antes de necesitarlas: el YAML de arriba se instala en diez minutos. La alternativa es enterarte del corte porque algo deja de funcionar.

El objetivo no es vivir sin internet. Es que cuando internet falle, lo que decidas que tiene que funcionar en tu casa siga siendo decisión tuya.