Domótica sin internet: 11 reglas de 10 años de un experto

Una casa que deja de funcionar cuando se cae la nube

Once reglas y diez años de prueba y error: ese es el resumen que publicó un desarrollador de software sobre cómo mantener su casa automatizada en pie cuando se corta internet. La regla número uno es tajante: si un interruptor de luz necesita el servidor de otra empresa para funcionar, no entra en la casa.

Para cualquier founder que esté construyendo un producto conectado, esa frase es una advertencia de arquitectura, no una preferencia personal. La dependencia de la nube no es un detalle de infraestructura: es una decisión de producto que determina si tu cliente puede usar lo que le vendiste.

¿Qué pasa cuando el fabricante apaga el servidor?

El caso más documentado es el de Google. El 18 de agosto de 2026, una falla del lado del servidor dejó los Nest Hub, Nest Mini y pantallas de terceros con Google Assistant inoperativos durante casi 12 horas, según TechTimes. El hardware estaba encendido y conectado a la red local; simplemente no podía procesar nada, porque cada comando de voz viaja a los servidores de Google antes de ejecutarse.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El detalle que más incomoda: Google no tiene una página de estado pública para su ecosistema de casa inteligente, a diferencia de Workspace o Google Cloud. Durante esa caída, los usuarios tuvieron que reconstruir qué estaba pasando con reportes en Reddit y Downdetector, que registró un pico de 300 reportes según el mismo medio.

Google empezó a corregir esto en enero de 2025, cuando lanzó Home Runtime para habilitar el control local de dispositivos certificados con Matter en hubs compatibles, según TechTimes. Pero esa solución parcial no cubre los comandos de voz ni la mayoría de las rutinas, que siguen procesándose en la nube. El contraste con Apple es estructural: HomeKit procesa las automatizaciones localmente a través de un hub, y Alexa ha introducido cierto grado de procesamiento de voz local en sus dispositivos Echo, según el mismo medio.

El autor del post original vivió su propia versión de esto: su integración con Nest funcionó hasta que Google cambió la API. Su nevera Samsung muestra un error de certificado TLS en su propia pantalla. Su controlador de parrilla necesita Wi-Fi para decirle la temperatura.

Las 11 reglas de una casa que funciona sin internet

El post lista las reglas que el autor fue acumulando. Las primeras cinco salieron del primer año; las seis siguientes, después del año cinco, cuando más gente vivía en la casa.

Sin internet, sin problema. Todo lo esencial de la casa tiene que funcionar con el cable desenchufado.
No quites la forma vieja mientras introduces la nueva. El interruptor de pared pegado con cinta en posición de encendido es el síntoma clásico de saltarse esta regla.
Sé ágil. Las habitaciones se usan distinto con el tiempo y la gente entra y sale: todo tiene que ser barato de cambiar.
Revisa tus automatizaciones. El autor llegó a tener cuatro disparadores programados apuntando a la misma bomba del jardín.
Las excepciones tienen que ser excepcionales. Se puede romper una regla, pero solo por una razón que seguirías defendiendo seis meses después.
Un dispositivo de nube necesita una API con logs, o no se instala.
La configuración vive en un solo lugar, no en cinco apps de cinco fabricantes.
Más de una forma de entrar: una app, un asistente de voz, un código QR o una etiqueta NFC.
Toda secuencia de acciones que se repite se convierte en rutina.
Los dispositivos hablan pub/sub sobre MQTT, no punto a punto.
Sin baterías, salvo que el dispositivo aguante un año o más sin cambio.

El stack que sostiene todo esto es deliberadamente aburrido: firmware Tasmota sobre placas ESP, un broker MQTT y Node-RED corriendo en una Raspberry Pi. Los servicios de nube, incluidos Alexa y algunos de AWS, son complementos, no la base.

El patrón se repite en toda la industria

No es un caso aislado. Un editor de XDA Developers documentó cómo cinco dispositivos de su casa inteligente lo llevaron a la misma conclusión: los que parecían más inteligentes al comprarlos eran los que más fricción agregaban después. Sus parlantes inteligentes terminaron siendo un temporizador glorioso; sus enchufes necesitaban cuatro apps con cuatro inicios de sesión distintos; su aspiradora robot consultaba los servidores del fabricante antes de empezar a limpiar.

Su salida fue migrar a Home Assistant como plataforma local, flashear los enchufes con ESPHome, reemplazar el hub propietario de sus luces por un coordinador Zigbee USB y mover la grabación de su videoportero a Frigate en una mini PC. La conclusión que saca es simple: antes de comprar el próximo dispositivo, pregúntate si necesita el servidor del fabricante para funcionar.

Los lectores del post original aportaron su propia lista de absurdos: un televisor que no puede cambiar de entrada cuando no hay internet, un termómetro de carne que dejó de funcionar cuando la empresa cerró, auriculares con cancelación de ruido que se quedan buscando un dispositivo Bluetooth para siempre. El termómetro es el caso más citado: el hardware sobrevivió a la empresa y dejó de servir igual.

¿Qué significa esto para tu startup?

Si vendes hardware conectado o software que depende de APIs de terceros, la discusión no es filosófica. Es la diferencia entre un producto que aguanta una caída y uno que genera una ola de reclamos.

Diseña para el modo degradado, no solo para el caso ideal. La pregunta operativa es qué sigue funcionando cuando tu backend o el de tu proveedor se cae. Un lector del post lo formuló bien: la acción central funciona offline o desde caché, y solo los extras esperan conexión.

Decide explícitamente qué debe funcionar sin red. El autor tiene su propia respuesta: encender y apagar cosas, controles de temperatura y seguridad, y todo lo que un invitado tenga que usar sin aprender una app. Si un visitante no puede subir la calefacción sin crear una cuenta, el diseño falló.

Trata cada dependencia de terceros como un riesgo con fecha de vencimiento. Las APIs cambian, se deprecan o se apagan. Si tu producto depende de una, ten un fallback local o un modo degradado documentado.

Publica una página de estado. El caso de Google muestra el costo reputacional de no tenerla: casi 12 horas de silencio oficial mientras los usuarios reiniciaban dispositivos que no estaban rotos.

Cómo empezar sin rehacer todo

No hace falta tirar lo que ya tienes. El post original y los comentarios de sus lectores sugieren un camino incremental:

Usa protocolos locales donde puedas. Varios lectores recomiendan Zigbee y Z-Wave sobre Wi-Fi para dispositivos que deben comportarse igual año tras año.
Mantén el control físico. Un interruptor de pared que sigue funcionando es la red de seguridad más barata que existe.
Resuelve el acceso remoto sin exponer los dispositivos. El autor usa Tailscale en el router y deja los dispositivos individuales fuera de la red.
Limpia cuando descartas hardware. Un dispositivo conectado que regalas o tiras sigue vinculado a tu cuenta, y eso es una puerta de entrada.
Mira el firmware alternativo. Para los termostatos Nest de primera y segunda generación existe No Longer Evil, un firmware open source que devuelve el control local.

Conclusión

La regla del autor no es una postura anti-tecnología: sigue usando Alexa y servicios de AWS donde aportan valor. La diferencia es que la lógica que gobierna la casa vive en hardware que controla él. Para un founder, la traducción es directa: la conectividad es una función, no un requisito de funcionamiento. Un producto que sigue sirviendo cuando la nube falla construye una confianza que ningún feature nuevo compra.