Antes de empezar a comprar dispositivos o montar servidores, debemos tomar la decisión de ingeniería más crítica de todo nuestro despliegue domótico: dónde va a residir la inteligencia del sistema.
A nivel de topología de red, un dispositivo “inteligente” (ya sea un enchufe, una bombilla o un sensor) no es más que un nodo ejecutor. La lógica que decide cuándo y cómo ese nodo debe actuar requiere procesamiento. Dependiendo de dónde se realice ese procesamiento de datos, dividimos la domótica en dos grandes arquitecturas diametralmente opuestas: la arquitectura basada en la Nube (Cloud) y la arquitectura de control Local.
Comprender cómo fluye la información en ambos modelos es fundamental para diseñar un sistema rápido, privado y tolerante a fallos. No es una discusión filosófica, es una decisión técnica que condiciona todo lo que venga después.
Domótica en la nube
La arquitectura Cloud es el modelo predominante en la mayor parte del hardware comercial de consumo. En este modelo, el dispositivo físico es “tonto”. Su única función es conectarse al router de nuestra casa para establecer un túnel o conexión persistente (generalmente vía MQTT o WebSockets) con los servidores del fabricante en Internet (WAN).
El cerebro de la casa, la base de datos y el motor de reglas no están en nuestro domicilio; están alojados en un centro de datos externo (en AWS, Azure o servidores propietarios).
Flujo de comunicación en la nube
Para entender la ineficiencia técnica de este modelo en operaciones básicas, analicemos qué ocurre cuando pulsamos el botón de “Encender” en la aplicación móvil de nuestro teléfono estando en el salón:
- El teléfono envía una petición HTTP a través del router hacia los servidores del fabricante.
- El servidor procesa la orden, busca el identificador de nuestro dispositivo en su base de datos y genera el comando.
- El servidor envía la orden de vuelta a nuestra casa, cruzando de nuevo los nodos de nuestro proveedor de Internet (ISP).
- El router recibe el paquete y se lo entrega al enchufe inteligente.
Estamos forzando a que una señal viaje miles de kilómetros para encender una bombilla que está físicamente a dos metros de nosotros.
La gran ventaja comercial: acceso remoto y ecosistema
Llegados a este punto, es lógico preguntarse: si enviar los datos a miles de kilómetros es ineficiente, ¿por qué lo hace toda la industria? La respuesta es que el modelo Cloud soluciona el mayor problema de las redes domésticas: la conectividad exterior.
Al delegar la infraestructura en el fabricante, este pone a nuestra disposición sus servidores, sus desarrolladores y sus bases de datos de forma aparentemente gratuita. Esto nos regala dos características extremadamente potentes:
- Acceso remoto transparente (Fuera de casa): Da igual si estás conectado al WiFi de tu salón o a una red 5G en el extranjero. Tu aplicación móvil simplemente habla con el servidor del fabricante en la nube, y este habla con tu enchufe. Funciona instantáneamente, sin que tú tengas que abrir puertos en tu router ni saber qué es una dirección IP pública.
- Integración con terceros y Asistentes de voz: Si quieres decirle a Google Assistant o Alexa que “encienda la luz”, el fabricante ya ha programado y mantenido la API (Cloud-to-Cloud) para que los servidores de Google se comuniquen con los suyos. Es un servicio complejo que el fabricante asume por nosotros para que funcione simplemente “sacándolo de la caja”.
Inconvenientes y riesgos del modelo en la nube
A cambio de esta enorme comodidad, entregamos el control total de nuestra casa a una empresa externa, lo que genera problemas críticos:
- Latencia: Inevitablemente, el viaje a la red exterior introduce un retraso (delay). Una orden puede tardar desde cientos de milisegundos hasta varios segundos en ejecutarse.
- Dependencia de la conexión a Internet: Este es el Single Point of Failure (SPOF). Si nuestro proveedor de fibra óptica sufre una avería, o nuestro router pierde la conexión, la casa entera se queda incomunicada.
- Privacidad y Obsolescencia programada: Enviamos telemetría constante a servidores de terceros. Además, si el fabricante quiebra o apaga los servidores de un modelo antiguo, nuestro dispositivo dejará de funcionar permanentemente (lo que se conoce como bricking).
Domótica local
Frente a la vulnerabilidad de la nube, la ingeniería de sistemas nos ofrece la arquitectura Local. Este modelo aplica los principios del Edge Computing (computación en el borde): llevar el procesamiento de los datos lo más cerca posible de donde se generan.
Cortamos la dependencia externa introduciendo en nuestra red de área local (LAN) un Servidor o Controlador Central (como un Mini PC ejecutando Home Assistant).
Flujo de comunicación local
Si repetimos la acción de encender una bombilla, el flujo cambia drásticamente:
- El teléfono se comunica directamente con el servidor de Home Assistant a través de la red WiFi interna.
- Home Assistant procesa la regla y envía la orden al dispositivo por la propia red WiFi, o mediante un protocolo de radiofrecuencia directo (como Zigbee o RF).
En este caso, el paquete de datos no necesita salir de nuestra red local.
Ventajas del modelo local
- Latencia baja: Las órdenes no tienen que hacer el viaje hasta los servidores del fabricante, por lo que la respuesta suele ser mucho más rápida.
- Tolerancia a fallos de Internet: Si la conexión exterior se cae, las funciones locales siguen disponibles. Los servicios meteorológicos, notificaciones y otras integraciones externas sí pueden dejar de funcionar.
- Independencia y Privacidad: El hardware nos pertenece de verdad. Ninguna empresa externa puede “apagar” nuestros enchufes, y la telemetría se almacena en nuestro propio disco duro.
El reto del modelo local: el acceso externo
Renunciar a los servidores del fabricante tiene un precio arquitectónico alto. Si la casa está aislada de Internet por diseño para proteger nuestra privacidad y garantizar la velocidad, acceder a ella desde la calle o conectarla a Google Assistant se vuelve un reto técnico bastante más serio.
Para replicar esa comodidad de forma segura, tendremos que configurar una VPN, un túnel cifrado o un proxy inverso con HTTPS. Soluciones como Tailscale o Cloudflare Tunnel evitan abrir directamente el puerto de Home Assistant al exterior.
Es un proceso que abordaremos detalladamente en la sección de “Operación” de este curso, pero es fundamental entender desde el principio que la independencia tecnológica exige mantenimiento y aprendizaje.
En la práctica, muchos sistemas robustos acaban siendo híbridos. Mantienen la lógica crítica en local, pero usan servicios externos para tareas concretas, como una copia de seguridad fuera de casa, la previsión meteorológica o la integración con asistentes de voz.
Qué debería quedarse siempre en local
No todos los elementos de una casa tienen la misma importancia. Que la previsión meteorológica venga de una API externa no es ningún drama. Si falla, como mucho no se bajará un toldo automáticamente (tampoco vamos a llorar demasiado).
Lo que sí debería funcionar siempre en local es todo lo que afecta a seguridad, confort básico y control manual: luces principales, calefacción, alarmas, sensores de fuga de agua, persianas críticas o cualquier cosa que, si se queda bloqueada, convierta la casa en un pequeño infierno.
Una forma sencilla de decidirlo es hacerse esta pregunta: si mañana se cae Internet durante 24 horas, ¿esto debería seguir funcionando? Si la respuesta es sí, esa lógica no debería depender de la nube.
Nuestro objetivo arquitectónico
Nuestra postura a la hora de diseñar el sistema es clara: todo componente crítico de la casa debe poder funcionar en local.
A lo largo de este curso utilizaremos Home Assistant precisamente para aplicar este principio. Intentaremos integrar en local los dispositivos comerciales que lo permitan y reduciremos su dependencia de servidores externos siempre que sea posible.
Una vez comprendida la diferencia entre dejar que nuestra casa sea controlada desde fuera o controlarla desde dentro, en el siguiente artículo bajaremos al mercado real para ver qué nos ofrecen los principales fabricantes (Tuya, Sonoff, Shelly) y cómo encaja cada uno en estas dos arquitecturas.
