Un controlador de invernadero no es solo una sonda y un relé. La posición del sensor, etapa del cultivo, sustrato, riego y fallos de red afectan la utilidad de una alerta. Trata el ESP32 como nodo de medición y control local, SQL como historial operativo y el riego como decisión acotada, visible y reversible.
Calibra los sensores en el sustrato real: un valor analógico bruto no equivale universalmente al contenido volumétrico de agua. Sonda, profundidad, salinidad, temperatura y mezcla cambian la relación. Coloca sensores donde las raíces absorben agua y considera varias profundidades. La FAO destaca la zona radicular y el uso de mediciones junto con un plan de riego, no un umbral universal.
Publica mediciones y salud con identidad por dispositivo. Incluye hora UTC de muestra, recepción del servidor, secuencia, versión de calibración, unidad e indicadores de calidad. En el ESP32, desacopla adquisición de las reconexiones; usa una cola limitada y registra huecos si se llena. La caída de red no debe bloquear un límite local ni reutilizar una lectura antigua en silencio.
Empieza como sistema consultivo: crea alerta o recomendación y pide aprobación humana. Si luego automatizas bomba o válvula, agrega duración máxima, volumen diario limitado, detección de funcionamiento en seco, respuesta a fugas, parada manual y estado seguro al encender. Una regla en la nube nunca debe ser la única barrera contra bombeo continuo.
Un modelo relacional sencillo puede separar devices, locations, sensors, readings, irrigation_events y alerts. Guarda valores normalizados con unidades y valores brutos si cambia la calibración. Usa una clave única como dispositivo, sensor y secuencia para idempotencia. Restringe campos y rangos, indexa consultas por tiempo y ubicación y conserva procedencia para explicar qué mediciones y regla generaron la recomendación.
No sobrescribas lecturas antiguas cuando cambie la calibración; registra su versión y aplícala en ingesta o transformación reproducible. Conserva dato crudo y normalizado para recalcular tendencias sin borrar evidencia.
Una sola lectura baja no debería iniciar el riego. Exige persistencia por debajo de un umbral específico del cultivo y sustrato, añade histéresis, intervalo mínimo entre ciclos y validación de vigencia. Combina humedad con etapa de cultivo y previsión cuando los datos sean fiables. La FAO describe la programación como una combinación de humedad del suelo, clima y apoyo a decisiones; los umbrales adecuados son agronómicos, no constantes universales del firmware.
| Entrada/estado | Comportamiento | Protección |
|---|---|---|
| Humedad bajo objetivo | Crear candidato de riego | Exigir lecturas recientes repetidas |
| Sensor obsoleto o imposible | Pausar recomendación automática | Avisar; no asumir suelo seco |
| Riego reciente | Esperar infiltración prevista | Evitar ciclos seguidos |
| Override o fuga | Detener o inhibir el actuador | Interbloqueo local con motivo registrado |
Alerta por una zona persistentemente seca, sensor sin reportar, válvula abierta más de lo esperado o falta de respuesta tras el riego. Incluye ubicación, último valor, antigüedad, versión de regla y siguiente comprobación sugerida. Deduplica incidentes y resuélvelos solo ante una condición definida. El gráfico debería alinear lecturas, riegos, huecos y bandas objetivo en el tiempo.
Simula sensor abierto/cortocircuitado, valor fijo, reloj desviado, pérdida de Wi-Fi, broker/base caída, cola llena, relé atascado, depósito vacío y corte eléctrico. El histórico debe distinguir “suelo seco”, “sensor averiado” y “sin datos recientes”. Empieza con una parcela pequeña y compara recomendaciones con la experiencia de cultivo antes de ampliar zonas o especies.
Un invernadero útil con ESP32 combina sensores calibrados, historial contextual en SQL, gestión de datos obsoletos, reglas del cultivo y límites de actuación seguros. Explica cada recomendación y limita, observa y permite anular cualquier acción de la bomba. El objetivo no es “riego IoT”, sino un flujo de decisión que respeta plantas, agua y equipos.