Inicio/Blog/IoT agrícola con ESP32
Arquitectura de IoT Agrícola

IoT agrícola con ESP32: sensores de suelo, riego y alertas predictivas

Un sensor económico ayuda a programar riego solo cuando la lectura está calibrada para el suelo, instalada en la zona radicular, combinada con clima y evidencia hidráulica, y conectada a un controlador que sigue siendo seguro sin cloud ni red.

Mide una zona, no un campo abstracto

El suelo varía con textura, compactación, pendiente, raíces, sombra, equipo y cultivo. Una sonda no representa toda la finca. Define zonas y sensores en lugares y profundidades representativos.

Guarda cultivo, etapa, perfil, raíz, capacidad de campo, threshold, sensor, instalación, calibración, método, caudal nominal y operador.

Evidencia del sueloHumedad o potencial por profundidad, temperatura, salinidad, calibración, calidad y edad.
Demanda climáticaLluvia, temperatura, humedad, viento, radiación, forecast, ET, coeficiente y lluvia efectiva.
Evidencia hidráulicaComando/estado de válvula, bomba, presión, caudal, depósito, filtro, runtime y volumen.
Policy operacionalVentana, threshold, objetivo, runtime/volumen máximo, cooldown, override, interlocks y fail-safe.

Calibra el sensor en la instalación real

Las sondas capacitivas baratas exponen valor eléctrico, no humedad volumétrica universal. ADC, tensión, cable, salinidad, temperatura, edad y contacto afectan la lectura. Calibra referencias seca/húmeda para sensor, suelo, profundidad y electrónica.

Registra raw y valor calibrado con calibration ID para interpretar historia tras reemplazo.

Mantén el loop de seguridad local

Cloud recomienda y compara; no puede ser el único componente capaz de detener válvula atascada, bomba seca, tubería rota, depósito vacío o riego largo. El control local impone runtime/volumen, presión/caudal, cooldown y emergencia.

El comando incluye ID, zona, inicio, expiración, objetivo, precondiciones, policy, issuer y auth. ESP32 revalida y reporta estados.

Construye el loop campo-dashboard

Loop de control campo-dashboard
01 MuestrearLee la zona radicularDespierta, estabiliza, muestrea, rechaza imposible, agrega, timestamp y batería.
02 DecidirAplica policy localThreshold, horario, lluvia, depósito, presión, runtime, expiración y modo manual.
03 ActuarAcciona con seguridadDrivers aislados, default-off, watchdog, interlock, runtime máximo y override físico.
04 VerificarObserva aguaVálvula, aumento de caudal, presión, volumen, no-flow, fuga y apagado.
05 BufferizarPersiste eventosSecuencia, sensores, comando, estados, fallas, calibración, firmware y cola.
06 TransmitirUsa ruta disponibleWi-Fi, gateway celular, LoRaWAN, MQTT, store-and-forward, retries y expiración.
07 ModelarCalcula balance hídricoSuelo, agua, lluvia, ET, etapa, forecast, anomalías y mantenimiento.
08 OperarMuestra decisiones y alertasGráfico, freshness, recomendación, estado, agua, owner y control manual.

Muestra thresholds y respuesta

Tendencia de humedad en zona radicular
Threshold de reposición
06h
09h
12h
15h
18h
21h
00h
03h

Muestra también freshness, calibración, profundidad, intervalo, lluvia y volumen. Un porcentaje aislado da falsa seguridad.

Usa múltiples muestras y flags

Energiza la sonda solo al medir cuando sea posible, estabiliza, lee varias veces, usa mediana y guarda variación. Marca desconectado, saturado, fuera de rango, inestable, stale, no calibrado y estimado.

No suavices respuesta real o firma de fuga. Guarda raw por ventana corta.

La conectividad depende de la geometría

Wi-Fi sirve en invernadero; LoRaWAN para baja tasa y área amplia; celular para gateways; satélite o sync tardío para sitios aislados. Elige por payload, alcance, energía, terreno, costo y downlink.

El control permanece local. La telemetría usa secuencia/event time. Los comandos expiran.

MQTT necesita semántica de dominio

QoS no vuelve exactly-once una válvula. Cada lectura/comando tiene ID. Deduplica y separa desired command, observed state y resultado.

Un retained command stale es peligroso. Usa expiración y chequeo actual. Status incluye firmware, boot, cola, calibración, batería, señal y fault.

La demanda necesita suelo y atmósfera

El sensor muestra agua local; evapotranspiración estima demanda. FAO combina ET de referencia y coeficiente. Úsalo como input y calibra con sensores, lluvia, riego y observación agronómica.

El forecast puede retrasar una recomendación, pero su incertidumbre no oculta estrés crítico.

Alertas predictivas empiezan con física

Calcula caída de humedad, tiempo al threshold, residual de balance, caudal, presión, batería, packet loss y desacuerdo. Son explicables.

ML puede predecir necesidad, falla, obstrucción, fuga o mantenimiento, devolviendo horizonte, confianza y evidencia, no comando directo.

Matriz operacional

CondiciónEvidenciaRespuestaGateAlerta
Zona bajo thresholdMuestras, perfil, ET/lluvia, etapa y freshness.Recomendar o programar riego acotado.Ventana, depósito, presión, runtime y manual.Estrés próximo sin ventana.
Válvula comandada sin caudalComando, feedback, caudal y presión.Detener tras timeout y marcar fault.No extender para “ver si inicia”.Inspección de válvula, cable, bomba o línea.
Caudal inesperado con válvulas offCaudal, comandos, presión y depósito.Cerrar master o parar bomba por policy.Emergencia física y override.Fuga de alta severidad.
Humedad no sube tras volumenVolumen, calidad, atraso, profundidad y peers.No repetir; abrir anomalía.Límite diario y cooldown.Sensor, fuga, runoff, obstrucción o canal.
Lluvia prevista y suelo adecuadoPerfil, ET, probabilidad/volumen y deadline.Retrasar dentro de policy.Humedad mínima y demora máxima.Incertidumbre con riesgo de estrés.
Sensor stale/driftLast seen, variación, peers, calibración y batería.Excluir y usar fallback seguro.Sin acción de una sonda inválida.Orden de mantenimiento.

La energía determina confiabilidad

Usa deep sleep, duty cycle, regulador eficiente, batería medida y presupuesto para radio, retries, frío y envejecimiento. Solar considera nubes y suciedad.

Brownout puede corromper estado o activar relés. Usa drivers, flyback, decoupling, watchdog, outputs seguros y storage con writes limitados.

Hardware exterior necesita metadata

Enclosure, UV, condensación, insectos, prensaestopas, corrosión, rayos, tierra, reemplazo y etiquetas afectan uptime. Registra serial, instalación, profundidad, calibración, batería, firmware y mantenimiento.

El dashboard debe guiar la visita técnica.

Secure boot y OTA necesitan recovery

Usa firmware firmado, secure boot/flash encryption cuando corresponda, credenciales protegidas, identidad por device y transporte autenticado. OTA por revisión/zona con rollback.

No actualices todos juntos. Conserva schedule local seguro y manual.

Observa agronomía e infraestructura

Dashboard combina perfil, threshold, ET, lluvia, recomendación, riego, caudal, presión, volumen, energía, freshness, batería, señal, firmware, cola y fallas. Compara respuesta del suelo.

Outcomes: agua por hectárea, eficiencia, stress-hours, fugas, visitas, energía, productividad contextual y reparación.

Prueba campo, radio y backend

Prueba calibración, drivers, no-flow, overcurrent, watchdog, brownout, manual, expiry, offline queue, duplicados, clock drift, storage, batería, pérdida, gateway y OTA rollback.

Haz piloto por zonas y compara con referencias y agrónomo antes de automatizar.

Qué construiría

Construiría nodos ESP32 calibrados, controlador local, gateway LoRaWAN/Wi-Fi, MQTT, time series raw, digital twin de zona, balance hídrico, recommendations, anomalies, command service y dashboard.

Empezaría en advisory mode y avanzaría a automatización acotada con verificación, límites, expiry, interlocks, audit y override.

El principio de diseño

Riego inteligente no es “humedad bajo 30%, activa relé”. Es sistema medido: evidencia calibrada, policy, seguridad local, entrega verificada, telemetría resiliente, predicción explicable y ownership humano.