Domótica Local vs Nube: Diferencias y Qué Pasa Sin Internet (2026)
Descubre qué sigue funcionando cuando se va internet: comparativa entre domótica local, cloud e híbrida con análisis de latencia, privacidad, seguridad y ejemplos prácticos.
En este artículo:
- Domótica local vs nube en 30 segundos
- ¿Por qué esta decisión es más importante de lo que parece?
- ¿Qué es la domótica local? El cerebro dentro de casa
- ¿Qué es la domótica en la nube? El cerebro en un servidor lejano
- ¿Qué es el modelo híbrido? Lo mejor de dos mundos
- Domótica local vs nube vs híbrida: tabla comparativa
- Cómo funciona por dentro: el viaje de los datos
- ¿Qué funciona sin internet? Tabla resumen
- ¿Qué significa realmente que un dispositivo sea local?
- Privacidad y seguridad: matices importantes
- ¿Qué pasa si el fabricante desaparece? El riesgo de la obsolescencia
- Zigbee, Z-Wave, Matter, Thread y Wi-Fi: ¿son locales?
- Errores comunes al elegir entre local y nube (ordenados por gravedad)
- Cómo saber si un dispositivo es realmente local (test en 5 minutos)
- ¿Qué arquitectura elegir según tu caso? Tabla de decisión
- Recomendaciones de productos (con criterio editorial)
- Ejemplo práctico de migración: de la nube al local
- Nuestra metodología y experiencia
- FAQ: respuestas a las dudas más frecuentes
- Conclusión
Respuesta rápida: la domótica local puede seguir ejecutando automatizaciones aunque se pierda Internet; la domótica cloud depende de servidores externos para las funciones que gestionan esos servidores. La arquitectura híbrida combina ambas: mantiene las funciones críticas en local y utiliza la nube para servicios como acceso remoto, voz o determinadas funciones de IA.
La clave no es si el dispositivo utiliza Wi-Fi, Zigbee, Thread o Matter, sino dónde se ejecuta la lógica y de qué servicios externos depende.
Domótica local vs nube en 30 segundos
- Local: las automatizaciones se ejecutan dentro de casa. Siguen funcionando sin internet.
- Cloud: las órdenes se procesan en servidores externos. Sin internet, muchas funciones dejan de responder.
- Híbrida: las funciones críticas son locales; las adicionales (voz, notificaciones, acceso remoto) pueden usar la nube.
- Sin internet: un sistema local bien diseñado puede seguir funcionando, pero no necesariamente todas sus integraciones (ej. asistentes de voz, APIs externas).
- Privacidad: local puede reducir el envío de datos a terceros, pero no garantiza por sí solo una red segura.
- Matter, Zigbee y Wi-Fi: el protocolo no determina por sí mismo si un sistema es local o cloud. Depende de cómo esté implementado.
¿Por qué esta decisión es más importante de lo que parece?
Cuando alguien empieza en domótica suele fijarse solo en el precio del dispositivo. El error típico —y lo hemos visto en muchas consultas de lectores— es comprar varios dispositivos de una marca sin comprobar si funcionan en local o solo en la nube del fabricante.
El problema aparece más tarde: cuando el fabricante cierra su servidor, cuando sube el precio de la suscripción, cuando cambian los términos de privacidad o simplemente cuando se va la conexión un rato. En ese momento, la arquitectura elegida (local, nube o híbrida) determina si tu casa sigue “viva” o se apaga parcialmente.
En nuestras consultas, la primera pregunta que hacemos siempre a quien empieza es: “¿qué pasa si mañana este fabricante desaparece?“. Si la respuesta es “mi casa deja de funcionar”, ahí ya tenemos un problema de diseño, no de mala suerte.
¿Qué es la domótica local? El cerebro dentro de casa
La domótica local es aquella en la que el cerebro que toma las decisiones —encender una luz cuando detecta movimiento, bajar la persiana a según qué hora— vive físicamente dentro de tu casa, normalmente en un hub, un mini PC o un servidor tipo Raspberry Pi o NUC. No necesita salir a internet para ejecutar la automatización.
Ejemplos típicos: Home Assistant instalado en local, sistemas cableados como KNX o Loxone, y buena parte del ecosistema Zigbee cuando se usa con un coordinador local (ejemplo: Zigbee2MQTT o ZHA en Home Assistant).
¿Qué es la domótica en la nube? El cerebro en un servidor lejano
La domótica en la nube (“cloud”) envía la orden desde tu móvil a los servidores del fabricante; ese servidor la procesa y luego manda la instrucción de vuelta al dispositivo. Todo el “pensamiento” ocurre fuera de tu casa. Es el modelo que usan la mayoría de apps genéricas tipo Tuya/Smart Life, muchos robots aspiradores y buena parte de los altavoces inteligentes de serie.
Esa facilidad inicial —descargas la app, escaneas un código QR y en dos minutos tienes el dispositivo funcionando— es la gran baza de la nube, y también su mayor punto débil a largo plazo.
¿Qué es el modelo híbrido? Lo mejor de dos mundos
En una instalación doméstica es perfectamente posible combinar funciones locales y cloud. Por ejemplo, Home Assistant puede ejecutar las automatizaciones localmente y utilizar servicios cloud solo para determinadas funciones, como asistentes de voz, acceso remoto o determinados servicios de IA.
Nuestra regla práctica: todo lo crítico (luces, calefacción, alarma) en local; todo lo accesorio (reconocimiento de voz avanzado, notificaciones enriquecidas) puede vivir en la nube.
💡 Ejemplo concreto: en nuestra instalación de pruebas, las luces, calefacción y alarma van por Home Assistant local. Usamos un altavoz con Alexa en la nube solo para el reconocimiento de voz. Si se cae internet, la casa sigue siendo totalmente habitable; solo perdemos la comodidad de pedirle cosas a Alexa.
Domótica local vs nube vs híbrida: tabla comparativa
| Criterio | Local | Cloud | Híbrida |
|---|---|---|---|
| Funciona sin internet (automatizaciones básicas) | ✅ Sí | ⚠️ Depende de las funciones y del fabricante | ✅ Sí (lo crítico) |
| Latencia | Generalmente menor y más predecible | Puede aumentar por conexión y servidor | Variable (local para crítico, cloud para accesorio) |
| Privacidad de datos | Se quedan en tu red (si está bien configurada) | Salen a servidores externos | Parcial (crítico local, accesorio cloud) |
| Dependencia del fabricante | Baja si utiliza protocolos e integraciones abiertas; puede seguir existiendo dependencia del fabricante en algunos componentes | Total | Media (solo para funciones cloud) |
| Configuración inicial | Curva de aprendizaje media/alta | Muy fácil (app + QR) | Media (requiere configurar ambos lados) |
| Coste de entrada | Hub/servidor propio (30‑150 €) | Bajo o sin hardware propio; algunos servicios requieren suscripción | Similar al local + posibles suscripciones |
| Riesgo de perder funciones si desaparece el servicio | Bajo (solo si usas APIs propietarias) | Alto (puede dejar inoperativo el dispositivo) | Medio (solo las funciones cloud) |
| Automatizaciones avanzadas y multi-marca | Excelente (Home Assistant, Node‑RED) | Limitado a su ecosistema | Excelente (local + integraciones cloud) |
| Mantenimiento | El usuario actualiza el hub/servidor | Automático (pero depende del fabricante) | El usuario mantiene la parte local |
Cómo funciona por dentro: el viaje de los datos
Para entender la diferencia, hay que ver dónde se procesa la orden.
🔵 Flujo Local: Sensor → (Red local) → [Hub Local] → [Actuador]
🔴 Flujo en la Nube: Sensor → (Internet) → [Servidor Nube] → (Internet) → [Actuador]
🟡 Flujo Híbrido: Automatización crítica → Local Voz / IA / acceso remoto → Cloud
Dónde vive la lógica de automatización
En un sistema local, el hub guarda las reglas (“si el sensor detecta movimiento y son más de las 22:00, enciende la luz al 30%”) y las ejecuta él mismo. No hay salto a internet.
En un sistema en la nube, esa misma regla suele estar guardada en el servidor del fabricante. El sensor manda el aviso a internet, el servidor decide, y de vuelta envía la orden a la bombilla. Dos viajes de ida y vuelta a un centro de datos que puede estar a miles de kilómetros.
En un sistema híbrido, la lógica crítica reside en el hub local, pero ciertas funciones (como el reconocimiento de voz o las notificaciones push) se delegan a servicios externos.
Latencia: ejemplo orientativo
El retraso —ese pequeño desfase entre que ocurre el evento y que se ejecuta la acción— es generalmente mayor en la nube porque cada orden depende de la velocidad de tu conexión, la carga del servidor del fabricante y el enrutamiento de internet. En local, ese trayecto se reduce a la propia red doméstica.
Ejemplo orientativo de latencia: en una arquitectura local, el recorrido de una automatización dentro de la LAN suele ser mucho más corto que uno que depende de un servicio cloud. Los valores concretos varían según el dispositivo, red y servidor, por lo que no deben interpretarse como una medición universal.
En otras palabras: una automatización local no tiene que esperar a que una petición salga de casa, llegue a un servidor externo y vuelva. Por eso, el tiempo de respuesta registrado en el sistema suele ser menor y más predecible en una arquitectura local que en una cloud. Estos son valores orientativos y dependen del hardware y la configuración concretos.
¿Qué ocurre realmente cuando se cae internet?
- Local: las automatizaciones internas siguen funcionando porque el hub no necesita salir de casa. Solo se pierde el control remoto desde fuera (por ejemplo, encender la calefacción antes de llegar) y las integraciones que sí dependan de un servicio externo (como el asistente de voz en la nube).
- Nube: normalmente se pierde la mayor parte. La app no puede hablar con el servidor, el servidor no puede hablar con el dispositivo, y las automatizaciones que dependían de la nube no se disparan. Algunos dispositivos pueden conservar funciones básicas (ej. encendido manual), pero pierden toda la lógica.
- Híbrida: las funciones críticas siguen operativas; las que dependen de la nube (voz, notificaciones, acceso remoto) dejan de funcionar.
¿Qué funciona sin internet? Tabla resumen
| Función | Local | Cloud | Híbrida |
|---|---|---|---|
| Automatizaciones locales | ✅ Sí | ⚠️ Depende | ✅ Sí |
| Control desde app dentro de casa | ✅* | ⚠️ Depende del fabricante | ✅/⚠️ Depende de la integración |
| Control remoto desde fuera | ❌ Sin conexión a Internet | ❌ Sin conexión a Internet | ❌ Sin conexión a Internet |
| Zigbee local | ✅ | Depende del hub | ✅ |
| Voz Alexa / Google | ❌ | ❌ | ❌ |
| Cámara con almacenamiento local (SD/NVR) | ✅ | Depende | ✅ |
| Notificaciones push | ❌ | ❌ | ❌ |
| APIs externas (clima, etc.) | ❌ | ❌ | ❌ |
- Siempre que la app y el sistema permitan conexión local.
- En una arquitectura local, el acceso remoto puede configurarse mediante VPN o servicios como Home Assistant Cloud, pero ambos necesitan conectividad entre el teléfono y la vivienda. Esto no significa que las automatizaciones locales dependan de Internet.
¿Qué significa realmente que un dispositivo sea local?
Un dispositivo es realmente local cuando la función que necesitas puede ejecutarse sin que la orden tenga que viajar a un servidor externo. Que tenga Wi-Fi, Zigbee, Matter o una API local no significa automáticamente que todas sus funciones sean locales.
| Función | ¿Puede ser local? | Comentario |
|---|---|---|
| Encender/apagar | Depende del dispositivo y de cómo se controle | Muchos dispositivos Wi-Fi pueden controlarse localmente si su API no requiere nube. |
| Automatización (reglas) | Depende del hub/integración | Home Assistant ejecuta reglas localmente; las apps de los fabricantes suelen usar la nube. |
| Control remoto fuera de casa | Normalmente requiere algún servicio externo (como Nabu Casa o DDNS) | Puede hacerse local con VPN o túneles, pero no es trivial. |
| Notificaciones push | Normalmente dependen de servicios externos (Firebase, APNS) | Difícil de hacer 100% local sin un servidor propio. |
| Reconocimiento de voz | Frecuentemente cloud (Alexa, Google, Siri) | Existen asistentes locales (Rhasspy, Willow), pero son menos comunes. |
| Grabación de cámara | Puede ser local (NVR, SD) o cloud | Depende del modelo y la configuración. |
| Actualizaciones de firmware | A veces | El dispositivo puede funcionar localmente, pero descargar firmware normalmente requiere internet. |
Privacidad y seguridad: matices importantes
Local no significa automáticamente “privado”
Un sistema local puede reducir considerablemente la cantidad de datos que necesitan salir de tu red, pero no garantiza por sí solo que ningún dato se transmita a terceros. Muchos sistemas locales aún usan servicios externos para:
- Actualizaciones de firmware
- Consultas meteorológicas
- Asistentes de voz
- Geolocalización
- Notificaciones push
- Integraciones con servicios externos (IFTTT, etc.)
Local no significa automáticamente “seguro”
La seguridad depende también de la configuración de red, actualizaciones, autenticación, exposición a internet y aislamiento de dispositivos IoT. Un sistema local mal configurado (contraseñas débiles, puertos abiertos, firmware obsoleto) puede ser tan vulnerable como uno en la nube mal gestionado.
Recomendación: si buscas máxima privacidad, elige un sistema local con control total sobre qué datos salen de tu red. Pero también protege tu red con contraseñas fuertes, VLAN para IoT y actualizaciones regulares.
¿Qué pasa si el fabricante desaparece? El riesgo de la obsolescencia
Uno de los mayores riesgos de la domótica en la nube es la dependencia del fabricante. Si la empresa cierra, cambia su política de precios o decide dejar de dar soporte a modelos antiguos, el dispositivo puede perder funcionalidades críticas.
Los cierres de servicios como los que afectaron a Insteon o Wink muestran el riesgo de depender de una infraestructura cloud propietaria: cuando el servicio deja de estar disponible, los dispositivos pueden perder parte o toda su funcionalidad. (Referencia sobre Insteon)
En un sistema local con Home Assistant y dispositivos que utilizan estándares e integraciones locales (Zigbee, Z-Wave, Matter), el riesgo es mucho menor, ya que la lógica reside en tu propio hub y el dispositivo puede seguir funcionando incluso si el fabricante desaparece.
Zigbee, Z-Wave, Matter, Thread y Wi-Fi: ¿son locales?
El protocolo no determina por sí mismo si un sistema es local o cloud. Es una confusión muy habitual.
- Zigbee: los dispositivos Zigbee se comunican mediante una red Zigbee independiente de Internet y pueden intercambiar datos con el coordinador aunque no exista conexión WAN. Importante: que Zigbee no necesite Internet no significa que toda la instalación sea independiente de la red local. Home Assistant, el coordinador y otros componentes pueden necesitar la LAN para comunicarse entre sí. Zigbee ≠ LAN ≠ Internet.
- Z-Wave: funciona de manera similar a Zigbee: forma su propia red de malla y no depende de internet para la comunicación básica.
- Thread: proporciona la red de comunicación; no es el sistema de automatización en sí. Para controlar dispositivos Thread desde un ecosistema Matter, normalmente intervienen componentes como un Thread Border Router y un controlador Matter.
- Matter: es un estándar de aplicación e interoperabilidad que puede utilizar Wi-Fi, Ethernet o Thread como transporte. El control de un dispositivo Matter puede realizarse localmente y no necesita Internet para las operaciones básicas. Sin embargo, el fabricante puede añadir servicios cloud, cuentas, funciones propietarias o integraciones externas que sí dependan de Internet.
- Wi-Fi: un dispositivo Wi-Fi puede tener una API local (como los enchufes Tasmota o ESPHome) o depender completamente de la nube del fabricante (como muchos dispositivos Tuya). El hecho de que use Wi-Fi no lo hace automáticamente “de nube”.
Conclusión: lo importante es dónde se ejecuta la lógica y qué funciones dependen de servicios externos, no el protocolo de comunicación.
Errores comunes al elegir entre local y nube (ordenados por gravedad)
- Comprar dispositivos de nube sin alternativa local. No comprueban si tienen firmware personalizado (como Tasmota o ESPHome) o integración nativa en Home Assistant.
- Confundir “compatible con Alexa/Google” con “funciona en local”. Muchas integraciones con asistentes de voz siguen pasando por la nube del fabricante aunque el dispositivo use Zigbee.
- Montar un sistema 100% local sin backup. Si el hub se estropea y no tienes copia de la configuración, pierdes meses de trabajo.
- No revisar la política de privacidad antes de meter cámaras o cerraduras en la nube de una marca desconocida.
- Pensar que “local” significa “sin app ni móvil”. Hoy en día Home Assistant y similares tienen apps tan cuidadas como cualquier sistema de nube.
- No probar la compatibilidad cruzada antes de comprar. Ejemplo: un sensor Zigbee de la marca X puede no funcionar con el hub de la marca Y.
- Asumir que Zigbee = local. Un hub propietario de Zigbee puede depender de la nube del fabricante para ciertas funciones.
Cómo saber si un dispositivo es realmente local (test en 5 minutos)
Este es un método práctico de 5 minutos para identificar qué partes de tu instalación dependen de Internet.
⚠️ Antes de hacer la prueba: no realices el test durante una situación en la que dependas de la domótica para seguridad, calefacción crítica o vigilancia. Si tienes una alarma conectada a una central receptora, comprueba primero cómo gestiona la pérdida de comunicación.
No confundas tres pruebas distintas:
- Cortar internet manteniendo la LAN (la red doméstica sigue activa).
- Apagar el Wi-Fi (los dispositivos Wi-Fi pueden perder conexión, pero Zigbee/Z-Wave/Thread pueden continuar).
- Apagar completamente el router (toda la infraestructura de red desaparece).
Cada prueba mide una dependencia diferente. El test descrito arriba corresponde al punto 1.
Cómo comprobar si tu domótica funciona sin internet
Test rápido de 5 minutos para saber si tus dispositivos siguen funcionando cuando se cae la conexión.
Desconecta la conexión WAN, no la red doméstica
Desconecta el cable Ethernet que conecta el router con el módem/ONT o desactiva temporalmente la conexión WAN. Mantén encendido el router para que la red Wi‑Fi/LAN siga funcionando. Antes de empezar, comprueba que Home Assistant (u otro sistema local) sigue accesible desde otro dispositivo conectado a la misma LAN.
Prueba una automatización local
Activa el sensor (ej. movimiento) y comprueba si la acción configurada en tu hub (Home Assistant, etc.) se ejecuta aunque el router no tenga salida a internet.
Prueba también desde la app del fabricante
Si usas una app de nube, comprueba si responde. Lo normal es que se quede cargando o marque error de conexión.
Anota qué falla y qué no
Haz una lista de qué dispositivos siguen funcionando y cuáles no: esa lista es tu mapa real de dependencias de la nube.
Repite la prueba tras reiniciar el router
Algunos sistemas recuperan funciones locales solo después de restablecer correctamente la red. Verifica que todo vuelve a la normalidad.
¿Qué arquitectura elegir según tu caso? Tabla de decisión
| Si tu prioridad es… | Mejor opción | Comentario |
|---|---|---|
| Empezar sin complicaciones | Cloud | Ideal para probar, pero ten en cuenta las limitaciones. |
| Que las luces sigan funcionando sin internet | Local | Asegúrate de que el hub y los dispositivos sean realmente locales. |
| Máxima privacidad | Local | Pero revisa qué datos salen realmente de tu red. |
| Mezclar muchas marcas | Local / Híbrida | Home Assistant es una de las opciones más flexibles para este escenario. |
| Control por Alexa/Google | Híbrida | Mantén las funciones críticas en local y la voz en la nube. |
| Cámaras con máxima independencia | Local | Busca modelos con almacenamiento local y sin necesidad de nube. |
| No mantener un servidor | Cloud | Pero asume el riesgo de dependencia. |
| Automatizaciones complejas | Local | Home Assistant o Node‑RED te dan un control total. |
| Empezar barato | Cloud | Muchos dispositivos económicos son de nube. |
| Equilibrio entre comodidad e independencia | Híbrida | La opción más sensata para la mayoría. |
Recomendaciones de productos (con criterio editorial)
Hemos probado varios dispositivos y aquí tienes nuestra valoración, basada en pruebas reales. La tabla es editorial; los enlaces de compra son afiliados pero no condicionan la recomendación.
| Producto | Para quién | Dependencia cloud | Requiere hub | Nuestra valoración |
|---|---|---|---|---|
| Home Assistant Green | Empezar en local sin montar un Raspberry Pi | Baja (puede usar servicios cloud opcionales) | — | Una de las opciones locales más sencillas. Requiere algo de familiarización. |
| TP-Link Tapo P110 | Probar domótica económica | Depende de la integración: con Home Assistant puede tener control local limitado, pero muchas funciones requieren cuenta y servicios de Tapo | No | Buena puerta de entrada, pero no para funciones críticas. Consulta la integración concreta. |
| Sonoff Zigbee 3.0 USB Dongle Plus | Crear red Zigbee local con Home Assistant | Baja (el coordinador es local) | Sí (necesita un servidor) | Excelente relación calidad-precio para montar un sistema local. |
| Philips Hue (con bridge) | Iluminación inteligente | Local en muchas funciones mediante el Hue Bridge; determinadas funciones e integraciones pueden requerir servicios externos | Sí (bridge) | Buen ecosistema, pero no todo es local. Revisa la documentación. |
| Reolink (modelos con SD/NVR compatibles) | Cámaras de seguridad | Depende del modelo: algunos ofrecen almacenamiento local y acceso local sin necesidad de nube | No (opcional NVR) | Ofrece modelos con almacenamiento local y acceso mediante protocolos/servicios locales, por lo que resulta interesante para instalaciones donde la grabación no debe depender de una suscripción cloud. |
Productos destacados para empezar en domótica local
Si después de leer la guía te decides por una arquitectura local o híbrida, estos son los productos que hemos probado y recomendamos. Los precios y enlaces son de agosto de 2026.
Home Assistant Green - Servidor Local Plug & Play
El servidor oficial de Home Assistant. Ideal para quien quiere control local sin tener que montar un Raspberry Pi desde cero. Bajo consumo, silencioso y con soporte para Zigbee/Z-Wave mediante dongle adicional. Incluye Home Assistant preinstalado y actualizado.
TP-Link Tapo P110 - Enchufe Inteligente con Monitor de Energía
Buen punto de partida si quieres probar domótica sin comprometerte todavía con un hub local: incluye medición de consumo real y es compatible con Alexa y Google Home. Eso sí, su control avanzado depende de la nube de Tapo; para automatizaciones críticas, mejor opta por un modelo con integración local probada.
Sonoff Zigbee 3.0 USB Dongle Plus - Coordinador Local
Si ya tienes un Raspberry Pi o un PC siempre encendido, este dongle (junto con ZHA o Zigbee2MQTT) convierte tu servidor en un potente coordinador Zigbee local por menos de 30 €. Perfecto para reutilizar dispositivos de Ikea, Philips o Xiaomi sin depender de sus hubs de nube.
Philips Hue Bridge - Hub Local para Iluminación
El hub oficial de Philips Hue permite controlar bombillas y tiras LED de forma local a través de Zigbee. La mayoría de funciones básicas (encendido, apagado, escenas) funcionan sin internet, aunque algunas integraciones avanzadas (como la geolocalización) requieren la nube de Philips.
Reolink RLC-510 - Cámara de Seguridad con Almacenamiento Local
Cámara IP con grabación local en tarjeta SD y compatible con NVR. No requiere suscripción ni nube para su funcionamiento básico; puedes acceder a las grabaciones localmente y, si quieres, configurar acceso remoto mediante VPN o el servicio P2P de Reolink (que sí usa su nube).
Nota importante: los precios y disponibilidad pueden variar. Los enlaces son de afiliado y ayudan a mantener este blog. Nuestras recomendaciones se basan en pruebas y documentación, no en comisiones.
Cómo usar estos productos según tu caso
- Si empiezas de cero y quieres local desde el primer día: compra el Home Assistant Green y el dongle Sonoff. Con eso tienes el cerebro y el coordinador Zigbee. Luego añade bombillas y sensores compatibles (Ikea, Aqara, etc.).
- Si ya tienes un servidor (Raspberry Pi, NAS, PC): solo necesitas el dongle Sonoff y ya puedes empezar a migrar dispositivos Zigbee.
- Si solo quieres probar con algo barato y no te importa la nube: el Tapo P110 es perfecto para empezar, pero no lo uses para funciones críticas.
- Para iluminación: el Philips Hue Bridge es una opción muy fiable y con buena integración local.
- Para cámaras: Reolink ofrece modelos con almacenamiento local, ideales para quienes no quieren depender de una suscripción cloud.
Ejemplo práctico de migración: de la nube al local
Este es un ejemplo práctico basado en situaciones habituales que hemos documentado en consultas de lectores. Ilustra el proceso de migración y sus implicaciones.
- Instalación inicial (típica): 3 bombillas Zigbee (Ikea), 2 enchufes Tapo P110, 1 cámara Eufy (modelo que dependía de almacenamiento en la nube para la reproducción de vídeo).
- Problema habitual: el usuario descubre que algunas funciones (acceso remoto, notificaciones, almacenamiento en la nube) dependen de servicios externos. Durante una interrupción de internet, la cámara pierde las funciones que dependían del servicio externo y los enchufes Tapo no responden a las automatizaciones programadas.
- Cambio realizado (ejemplo): migrar las bombillas a un dongle Sonoff con Zigbee2MQTT en Home Assistant (local). Reemplazar la cámara por un modelo con almacenamiento local en SD y NVR. Mantener los enchufes Tapo para usos no críticos (lámparas decorativas) y comprar enchufes Zigbee para la calefacción y el router.
- Resultado esperado: la próxima vez que se vaya la luz (y el internet), las funciones críticas (luces, calefacción, alarma) siguen operativas. Solo se pierde el acceso remoto temporalmente.
- Limitación: la migración requiere volver a emparejar todos los dispositivos Zigbee y reconfigurar las automatizaciones en el nuevo hub. El proceso puede llevar tiempo dependiendo del número de dispositivos.
Nuestra metodología y experiencia
Cómo hemos elaborado esta guía: hemos contrastado el comportamiento de distintas arquitecturas locales, cloud e híbridas, prestando especial atención a qué ocurre al cortar la conexión WAN manteniendo activa la red LAN. Las conclusiones combinan pruebas prácticas, documentación técnica y el comportamiento conocido de las diferentes integraciones. Los resultados pueden variar según el dispositivo, integración y configuración.
| Elemento | Configuración (referencia) |
|---|---|
| Servidor | Raspberry Pi 4 (4 GB) |
| Hub | Home Assistant (instalación estándar) |
| Coordinador Zigbee | Sonoff Zigbee 3.0 USB Dongle Plus |
| Sensor de presencia | Aqara (modelo RTCGQ11LM) |
| Actuador (bombilla) | IKEA TRÅDFRI (modelo LED1624G9) |
| Automatización | Sensor detecta movimiento → enciende bombilla al 30% |
| Escenario cloud (referencia) | Dispositivos Tuya (sensor de movimiento y bombilla compatible) con su hub/gateway oficial |
Análisis de latencia (orientativo): se registró el timestamp del evento del sensor y el timestamp de la orden de actuación en el log del hub (Home Assistant o respuesta de API de Tuya) para comparar el comportamiento general de cada arquitectura. La medición corresponde al tiempo entre el registro del evento y el registro de la orden de actuación; no representa el tiempo físico completo entre detección y encendido.
Estas condiciones permiten reproducir la comparación y entender qué parte de los resultados depende de la arquitectura, el hardware y la red utilizada. Los resultados no deben extrapolarse como valores universales a cualquier instalación.
FAQ: respuestas a las dudas más frecuentes
¿La domótica local necesita internet para funcionar?
No para lo básico. Las automatizaciones internas (luces, sensores, calefacción) se ejecutan dentro de tu red. Solo necesitas internet para el control remoto desde fuera de casa o para integraciones puntuales con servicios externos.
¿La domótica funciona si se va el Wi-Fi?
Depende. Si el hub y los dispositivos se comunican por Zigbee, Z-Wave o Thread, pueden seguir funcionando aunque el Wi-Fi caiga, siempre que el hub tenga energía. Si los dispositivos son Wi-Fi y el router se apaga, perderán la conexión. Wi-Fi e internet no son lo mismo: puedes tener la red Wi-Fi de tu casa funcionando aunque el router haya perdido la conexión a internet.
¿Zigbee necesita internet?
No. Los dispositivos Zigbee se comunican mediante una red Zigbee independiente de Internet y pueden intercambiar datos con el coordinador aunque no exista conexión WAN. Si ese coordinador está conectado a Home Assistant y las automatizaciones son locales, pueden seguir funcionando aunque se pierda internet. Importante: Zigbee ≠ LAN ≠ Internet; la LAN puede ser necesaria para la comunicación entre el coordinador y el servidor.
¿Matter necesita internet?
Matter es un estándar de aplicación e interoperabilidad que puede utilizar Wi-Fi, Ethernet o Thread como transporte. El control de un dispositivo Matter puede realizarse localmente y no necesita Internet para las operaciones básicas. Sin embargo, el fabricante puede añadir servicios cloud, cuentas, funciones propietarias o integraciones externas que sí dependan de Internet.
¿Thread necesita internet?
Thread proporciona la red de comunicación; no es el sistema de automatización en sí. Para controlar dispositivos Thread desde un ecosistema Matter, normalmente intervienen componentes como un Thread Border Router y un controlador Matter. Puede funcionar sin internet si el Border Router y la lógica de automatización son locales.
¿Wi-Fi significa que el dispositivo depende de la nube?
No necesariamente. Un dispositivo Wi-Fi puede tener una API local (ej. Tasmota, ESPHome) que permite controlarlo sin internet. Pero muchos dispositivos Wi-Fi comerciales dependen de la nube del fabricante. Comprueba la documentación.
¿Home Assistant funciona sin internet?
Sí. Las automatizaciones que dependen únicamente de Home Assistant y de dispositivos accesibles localmente pueden ejecutarse sin internet. Las que utilizan servicios externos (ej. APIs de clima, webhooks, TTS) necesitarán esa conexión para la parte correspondiente.
¿Alexa funciona sin internet?
Para el reconocimiento y procesamiento normal de comandos de voz, Alexa depende de los servicios cloud de Amazon. Sin conexión a internet, los comandos de voz habituales no estarán disponibles.
¿Qué dispositivos siguen funcionando si apago el router?
Si apagas completamente el router, no estás realizando una prueba de dependencia de internet, sino de dependencia de la infraestructura de red local. Los dispositivos Zigbee o Z-Wave pueden mantener su propia malla, pero el coordinador, Home Assistant y otros componentes pueden necesitar la red Ethernet/LAN para comunicarse entre sí. Para saber si una automatización depende de internet, es mejor cortar únicamente la conexión WAN y mantener activa la LAN.
¿Cómo saber si un dispositivo tiene control local?
El test de desconectar internet que describimos arriba es el método más fiable. También puedes consultar la documentación del fabricante o buscar en foros especializados (ej. Home Assistant Community) si otros usuarios han verificado el control local.
¿Se puede convertir un dispositivo cloud en local?
En algunos casos, sí. Mediante firmware personalizado (Tasmota, ESPHome) para dispositivos Wi-Fi, o utilizando integraciones locales (ej. Zigbee2MQTT) para dispositivos Zigbee que antes dependían de un hub propietario. No siempre es posible, especialmente en cámaras o cerraduras con cifrado propietario.
¿Qué diferencia hay entre local, cloud e híbrido?
- Local: la lógica principal de automatización se ejecuta dentro de tu red y no depende de un servicio cloud para las funciones críticas.
- Cloud: una o más funciones esenciales dependen de servidores externos del fabricante o proveedor.
- Híbrido: las funciones críticas son locales; las adicionales (voz, notificaciones, acceso remoto) usan la nube.
¿Es más segura la domótica local que la de la nube?
En términos de privacidad, local puede reducir el envío de datos a terceros, pero la seguridad general depende de la configuración de red, actualizaciones y autenticación. Un sistema local mal configurado puede ser tan vulnerable como uno en la nube mal gestionado.
¿Puedo mezclar dispositivos de nube y locales en la misma casa?
Sí, es la opción más común. Mantén las funciones críticas en local y usa la nube para lo accesorio. Asegúrate de ser consciente de las dependencias de cada dispositivo.
¿Qué es mejor: domótica local o en la nube?
No existe una opción universalmente mejor. La domótica local es preferible si priorizas independencia de Internet, privacidad y automatizaciones que deben seguir funcionando aunque falle la conexión. La nube resulta más sencilla de configurar y mantener, pero introduce dependencia de servicios externos. Para muchas viviendas, una arquitectura híbrida ofrece el mejor equilibrio entre autonomía y comodidad.
¿Qué es una domótica híbrida?
La domótica híbrida combina automatizaciones y dispositivos locales con servicios cloud. Por ejemplo, Home Assistant puede controlar luces y sensores localmente mientras utiliza un servicio cloud para Alexa, acceso remoto o determinadas funciones de IA.
Conclusión
Si quieres que tu casa siga funcionando cuando falle Internet, diseña primero las funciones críticas para trabajar en local y utiliza la nube solo donde aporte una ventaja real.
Esta semana, haz esto:
- Desconecta internet 5 minutos (corta la WAN, no el Wi-Fi) y anota qué deja de funcionar en tu casa.
- Clasifica tus dispositivos en:
- ✅ Locales (siguen funcionando).
- ❌ Nube (se apagan por completo).
- ⚠️ Híbridos (funcionan parcialmente).
- Decide: si tienes varias funciones críticas que dependen de internet, plantéate migrarlas progresivamente a una arquitectura local o híbrida. Empieza poco a poco, con un dongle y un par de dispositivos.
¿Ya has probado el test de desconectar internet? Cuéntanos en los comentarios qué dispositivos fallaron en tu casa. Y si te ha gustado esta guía, compártela para que más gente evite depender de servidores externos. ¡Te leemos!
** Módulo 2 — lección anterior :Modulo 2 — Qué es un hub domotico ** ** Módulo 2 — lección siguiente :Modulo 2 —Protocolos domóticos **