Publicado originalmente en iot.gripe, como parte 1 de la serie "Domótica con ESP32 y AWS desde cero".
La mayoría de tutoriales de domótica con ESP32 terminan en un LED que se enciende desde el celular. Los problemas aparecen después: cuando tienes diez dispositivos, cuando otra persona de la casa quiere usarlos, cuando quieres controlarlos por voz o cuando un corte de luz desordena todo.
En esta serie construimos, paso a paso, un proyecto de ejemplo de domótica con ESP32 y AWS. Cada parte explica una pieza (firmware, nube, app o seguridad) con código mínimo y nombres genéricos, para que la adaptes a tu propio proyecto. Esta primera parte es el mapa: qué piezas hay, cómo se hablan y qué opciones tienes en cada capa.
Un ESP32-S3 (arriba) y dos ESP32-C3 (abajo): el hardware típico de un proyecto así.
La arquitectura en una imagen
Las tres capas del proyecto de ejemplo. La caja punteada es la alternativa: cada ESP32 conectado directo a la nube.
Casi todos los sistemas de domótica conectados a la nube tienen estas tres capas:
- Dispositivos en la casa: placas ESP32 que mueven relés o leen sensores.
- Nube: un broker MQTT que recibe y reparte los mensajes, un servicio de login, una base de datos y alguna API.
- Apps: una web app o app móvil, y quizá control por voz.
Con AWS, todo puede ser serverless: no hay servidores propios que mantener, y con uso doméstico el costo es de centavos al mes.
Capa 1: cómo se conectan los dispositivos
La primera decisión es si cada dispositivo habla con la nube o si uno solo lo hace por todos.
| Cada dispositivo conectado a la nube | Un hub y nodos locales | |
|---|---|---|
| Conexiones TLS abiertas | Una por dispositivo | Una por casa |
| Certificados que administrar | Uno por dispositivo | Uno por hub |
| Clientes conectados al router | Todos | Solo el hub |
| Memoria que necesita cada placa | TLS + MQTT + JSON en todas | Los nodos necesitan muy poca |
| Si el hub falla | No aplica | Los nodos pierden el control remoto |
| Complejidad | Menor: un solo firmware | Mayor: dos firmwares y un protocolo local |
Conexión directa es lo más simple para empezar, y lo que hace la mayoría de enchufes comerciales: cada placa con su Wi-Fi, su certificado y su conexión MQTT.
Hub y nodos escala mejor cuando hay muchos dispositivos pequeños. El hub (un ESP32-S3, con más memoria) es el único con Wi-Fi e internet; los nodos (ESP32-C3, más baratos) reciben órdenes por un protocolo local. Para el protocolo local hay varias opciones: ESP-NOW (de Espressif, sin router), Bluetooth LE, Zigbee o Thread. Las comparo en la guía de comunicación entre dispositivos.
El proyecto de ejemplo usa un hub con nodos ESP-NOW porque así la serie cubre las dos cosas: la conexión de un ESP32 con AWS (parte 3) y la comunicación entre placas (parte 4). La elección de placas para cada papel está en la parte 2.
Un interruptor físico que no depende de internet
Sea cual sea la arquitectura, conviene que cada luz tenga un interruptor de pared que funcione en local: el dispositivo cambia el estado al instante y después avisa a la nube. Si se cae internet, la luz sigue funcionando como siempre. Lo construimos en la parte 18.
Capa 2: la nube en AWS
| Servicio | Para qué sirve |
|---|---|
| AWS IoT Core | Broker MQTT gestionado. Autentica cada dispositivo con un certificado X.509 |
| Device Shadow | Un documento JSON por dispositivo con el estado deseado y el reportado. Guarda el estado aunque el dispositivo esté desconectado |
| Cognito | Login de usuarios (User Pool) y credenciales temporales de AWS para la app (Identity Pool) |
| DynamoDB | Base de datos para usuarios, dispositivos o lecturas de sensores |
| Lambda | Funciones para las APIs: por ejemplo, la que recibe una orden de voz |
| AWS CDK | Toda la infraestructura definida como código |
Si es tu primer contacto con AWS IoT, empieza por la guía de AWS IoT Core.
Cómo viaja una orden con el Device Shadow
El patrón más usado con AWS IoT es separar lo que el usuario quiere de lo que el dispositivo confirma:
{
"state": {
"desired": { "sala": "on", "cocina": "off" },
"reported": { "sala": "off", "cocina": "off" }
}
}
- La app escribe el estado deseado (
desired). - AWS IoT calcula la diferencia entre deseado y reportado (el
delta) y se la envía al dispositivo. - El dispositivo aplica el cambio (o se lo pasa al nodo que corresponde) y espera la confirmación.
- Con el cambio confirmado, publica el nuevo estado reportado (
reported). - La app, suscrita a los cambios, actualiza el botón.
La regla de oro: el dispositivo solo reporta lo que de verdad aplicó. Si un nodo está desconectado, la app no debe mostrar un estado falso. Lo implementamos en la parte 5.
Capa 3: las apps
La web app puede ser un sitio estático con React y Vite que se conecta a AWS IoT Core por MQTT sobre WebSocket (parte 10) y que se instala en el celular como una app (parte 15). Un sitio estático se puede alojar gratis.
La voz no necesita un altavoz inteligente: un Atajo de iOS puede llamar a una API HTTPS y Siri lo ejecuta con una frase (parte 9).
Cuánto cuesta
Para una casa, centavos de dólar al mes: AWS IoT Core cobra por conexión y por mensaje, Cognito tiene una capa gratuita amplia, DynamoDB y Lambda en modo bajo demanda cobran por uso, y la web app se puede alojar gratis. Cómo estimarlo con números está en la parte 22.
Los límites que conviene conocer
- ESP-NOW admite un máximo de 20 *peers* registrados por dispositivo (menos si usas cifrado). Es un límite del SDK de Espressif.
- El control remoto depende de internet. Sin conexión, la app y la voz no funcionan; los interruptores físicos sí.
- Un dispositivo apagado no recibe órdenes. El Shadow guarda el estado deseado y se lo entrega cuando vuelve, pero la app debe mostrar que está desconectado (parte 19).
Preguntas frecuentes
¿Por qué no usar Home Assistant?
Home Assistant es excelente para domótica local: todo funciona dentro de tu red y tiene miles de integraciones. Una arquitectura en la nube tiene sentido si quieres control remoto sin abrir puertos ni mantener un servidor encendido en casa, o si quieres aprender a construir cada pieza. Comparo las dos opciones en un artículo aparte.
¿ESP-NOW o Wi-Fi para todos los dispositivos?
Con pocos dispositivos, Wi-Fi directo es más simple. Con muchos, o con nodos a batería, ESP-NOW reduce memoria, consumo y conexiones al router. La parte 4 explica ESP-NOW paso a paso.
¿Necesito AWS para seguir la serie?
Para las partes de la nube, sí. Las partes de firmware (ESP-NOW, NVS, portal cautivo, interruptor físico) sirven para cualquier proyecto con ESP32, uses otra nube o ninguna.
¿Qué viene en la serie?
El hardware (parte 2), la conexión con AWS IoT Core (parte 3), ESP-NOW (parte 4) y, después, la base de datos, las APIs, la web app, la seguridad y los costos. El índice completo está en la página de la serie.
Top comments (0)