Hacer que un ESP32 encienda una luz desde el celular lleva un fin de semana. Hacer que cien ESP32 funcionen en cien casas distintas, configurados por otras personas, con usuarios que no conoces y sin que tengas que visitar a nadie, es otro proyecto.
Esta guía reúne lo que cambia en ese camino: los problemas que no existen en un prototipo y que aparecen en cuanto los dispositivos salen de tu escritorio.
1. Un solo firmware para todos
En un prototipo, el Wi-Fi, el certificado y la configuración suelen estar escritos en el código. Con clientes, eso significa compilar un firmware distinto por dispositivo, a mano, con una llave privada copiada entre ventanas.
Lo que cambia: un firmware genérico, igual para todos, y la configuración propia de cada dispositivo se entrega después de instalarlo y se guarda en su memoria (parte 6).
2. Aprovisionamiento sin visita técnica
Alguien que no eres tú tiene que poder poner en marcha el dispositivo.
Lo que cambia:
- un portal de configuración: el dispositivo nuevo levanta su propia red Wi-Fi con un formulario (parte 16);
- aprovisionamiento en la nube, para que cada dispositivo obtenga su propio certificado sin quemarlo en el firmware (parte 17);
- confirmación humana para emparejar dispositivos nuevos, para que nadie pueda colarse en un sistema ajeno;
- una forma de instalar el firmware sin herramientas, como un botón en el navegador (parte 20).
3. Aislamiento entre clientes
Con un solo usuario, los permisos pueden decir el nombre de tu dispositivo. Con varios clientes, la pregunta es: ¿qué impide que uno controle la casa de otro?
Lo que cambia: el aislamiento tiene que estar en los permisos de la nube, no solo en el código de la app. Cada dispositivo limitado a sus tópicos con políticas de IoT con variables (parte 13), y cada usuario limitado a sus datos por la API o por IAM, a partir de un token verificado.
4. Usuarios, roles y permisos
Lo que cambia:
- registro por invitación y contraseña propia desde el primer login (parte 11);
- separar los roles de la plataforma (quien la opera) de los roles dentro de cada casa (quien usa los dispositivos);
- permisos aplicados en el servidor y una forma rápida de revocarlos.
5. Actualizaciones a distancia
Un error en el firmware de un prototipo se corrige con el cable. En casa de un cliente, no.
Lo que cambia: actualizaciones OTA con despliegue gradual (primero tus dispositivos, después unos pocos clientes, luego el resto), retraso aleatorio para no saturar el servidor y vuelta automática a la versión anterior si la nueva falla. Lo explico en la guía de instalación de firmware de este blog.
6. La infraestructura, en código
En un prototipo, crear un rol o una función en la consola "solo para probar" es normal. Con clientes, cada cambio manual es algo que nadie podrá reconstruir si se borra.
Lo que cambia: la infraestructura definida en código (AWS CDK, Terraform), revisable y reproducible. Pasar a código lo que se creó a mano suele destapar permisos desactualizados y otros que sobran (parte 12).
7. Seguridad revisada, no supuesta
Lo que cambia: auditorías periódicas de lo que existe de verdad en la cuenta, no de lo documentado. Es habitual encontrar funciones públicas olvidadas y roles con comodines heredados de prototipos (parte 21).
8. Saber cuánto cuesta cada cliente
Lo que cambia: el costo por cliente es lo que decide el precio. Con una arquitectura serverless, el costo de la nube por casa puede quedar en centavos; lo que más lo mueve es la frecuencia de la telemetría (parte 22).
9. Lo que no es código
- Certificaciones de radio. Un dispositivo con Wi-Fi o Bluetooth que se vende necesita cumplir la normativa de radio y seguridad eléctrica de cada país (por ejemplo, el marcado CE en la Unión Europea). Usar módulos ya certificados ayuda, pero el producto final suele requerir sus propias pruebas. Consulta con un laboratorio antes de vender.
- Privacidad. Si guardas datos de personas, la normativa de protección de datos aplica (en Europa, el RGPD): qué guardas, para qué y por cuánto tiempo.
- Soporte. ¿Qué pasa cuando alguien pierde el acceso a su cuenta o un dispositivo deja de responder? Decide el proceso antes de tener el primer caso.
- Correo. Enviar contraseñas o avisos por correo requiere un servicio configurado para enviar a cualquier dirección; en AWS, SES empieza en un modo de pruebas.
Lista de comprobación
| Área | ¿Lo tienes? |
|---|---|
| Firmware | Un solo binario; configuración después de instalar |
| Aprovisionamiento | El cliente pone en marcha el dispositivo sin ti |
| Identidad | Certificado propio por dispositivo, entregado de forma segura |
| Aislamiento | Permisos de la nube que separan a cada cliente |
| Usuarios | Roles, permisos en el servidor y revocación |
| Actualizaciones | OTA gradual con vuelta atrás |
| Infraestructura | Definida en código |
| Seguridad | Auditoría periódica |
| Costos | Costo por cliente conocido |
| Normativa | Radio, seguridad eléctrica y privacidad revisadas |
Preguntas frecuentes
¿Cuándo debería empezar a pensar en esto?
Cuando el segundo dispositivo va a una casa que no es la tuya. Antes, optimiza para aprender rápido; después, cada atajo se paga con interés.
¿Necesito una plataforma como AWS para vender dispositivos?
No necesariamente, pero alguien tiene que resolver identidad, permisos, disponibilidad y actualizaciones. Una plataforma administrada te ahorra mantener servidores.
¿Qué suele ser lo más difícil?
Los permisos. Que cada cliente solo vea lo suyo y que eso lo garantice la nube, no la interfaz. Conviene diseñarlo desde el primer cliente, no después.