Caso de estudio
SmartPot
Plataforma IoT que vigila cultivos hidropónicos y deja que un asistente actúe sobre ellos
Los sensores ESP32 publican por MQTT con TLS, una API en Spring Boot guarda y controla cada cultivo, y un servicio en FastAPI diagnostica y pronostica. En septiembre de 2026 reconstruí la plataforma después de que producción se cayera.
El problema
Un cultivo hidropónico se pierde rápido cuando la temperatura, el pH o los nutrientes se desvían, y nadie puede vigilarlo todo el día. SmartPot nació como un proyecto universitario para monitorear cultivos a distancia y actuar sobre ellos.
En septiembre de 2026 producción estaba caída. La API rechazaba todas las peticiones tras un cambio en el prefijo de sus rutas, el contenedor de la base de datos no existía, el broker MQTT que la API esperaba nunca se había desplegado y varios servicios internos quedaban expuestos a internet.
Restricciones
- Los dispositivos están en redes de hogar, así que el broker tiene que ser accesible desde internet y aun así autenticar cada dispositivo.
- Cinco estudiantes con horarios distintos y un solo servidor.
- La demo tiene que funcionar sin hardware real.
Lo que construí
- Un repositorio por componente, cada uno con una imagen endurecida en GHCR, para la API, la web, el servicio de IA, el broker, la base de datos, la caché, el correo, el firmware y el simulador.
- Un contrato MQTT versionado (smartpot/v1/{cropId}/…) sobre Mosquitto 2.1 con seguridad dinámica, TLS 1.2 o superior en el puerto 8883 con su propia autoridad certificadora, y WebSockets detrás de Nginx para el navegador.
- Una API en Spring Boot 4 con Java 21, MongoDB, Redis y JWT, que verifica la propiedad de cada cultivo y cada dispositivo.
- Un asistente en FastAPI que combina un sistema experto, lógica difusa y modelos de scikit-learn. Pronostica las horas que faltan para que una variable salga de su rango (Theil-Sen), agrupa los cultivos con el mismo problema (K-Means) y sugiere una sola acción para todos.
- Un simulador de dispositivos por MQTT, con un modo de clima alimentado por Open-Meteo, para que la demo y las comprobaciones de punta a punta corran sin hardware.
- Despliegue desde el repositorio de la organización, con Docker Compose en producción y manifiestos de Kubernetes.
Arquitectura
Del sensor a la pantalla
Los datos van en ambos sentidos entre columnas vecinas, porque las lecturas van a la derecha y las órdenes regresan.
Campo
- Firmware ESP32 en MicroPython
- Simulador de dispositivos con clima real
Mensajería
- Broker Mosquitto 2.1
- TLS en 8883 y WebSockets detrás de Nginx
- Credenciales por dispositivo
Plataforma
- API en Spring Boot 4 con Java 21
- MongoDB y Redis
- Asistente en FastAPI con scikit-learn
Personas
- PWA en React 19
- Alertas por Telegram
Entrega
- Imágenes endurecidas en GHCR
- Despliegue central con Docker Compose
- Manifiestos de Kubernetes
Decisiones y sus costos
MQTT con credenciales por dispositivo
Los dispositivos están en redes de hogar. Envían lecturas, reciben órdenes de la API y cada uno tiene que autenticarse.
El simulador como componente de verdad
La demo tiene que funcionar sin hardware real.
Reglas expertas junto a los modelos
Los modelos necesitan datos antes de ayudar, y al principio no hay lecturas.
Resultados
- De vuelta en producción el 26 de septiembre de 2026, con siete contenedores sanos y TLS verificado en el broker.
- 139 pruebas en la API y 35 comprobaciones de punta a punta.
- Escribí 2.273 de los 2.446 commits no automatizados de los 11 repositorios.
Pendientes
- Respaldos automáticos de la base de datos antes de que lleguen más cultivadores.
- Correr los manifiestos de Kubernetes en un clúster real.
Stack
Elige una tecnología para ver qué proyectos la usan.