Ya cubrimos cómo un relé o contactor enciende físicamente un equipo y cómo un actuador LoRaWAN entrega esa orden hasta el sitio. La pregunta que queda pendiente —y la que más confunde a quien automatiza por primera vez— es más básica: ¿qué decide cuándo se envía esa orden? En la práctica, casi toda automatización rural se reduce a tres lógicas distintas: un horario fijo, un evento medido por un sensor, o un modelo que intenta anticipar lo que va a pasar. No son intercambiables, y elegir la que no corresponde es la causa más común de un sistema que “automatiza” pero sigue gastando de más, fallando en silencio o generando alarmas que nadie atiende.
Horario fijo: la lógica más simple y la más subestimada
Un control por horario enciende y apaga un equipo a una hora predeterminada, sin leer ningún sensor en el momento de decidir. Es la forma de automatización más simple de implementar y, precisamente por eso, la más fácil de despreciar como “poco inteligente”. No lo es: en control industrial se le llama control por tiempo (time-based control), y su ventaja real no es la eficiencia sino la previsibilidad —el equipo siempre hace lo mismo a la misma hora, sin depender de que un sensor esté calibrado, con batería, o dentro de cobertura ese día—.
Esa previsibilidad es exactamente lo que se necesita como piso de seguridad: un horario base que cubre el consumo previsible de la noche —de oxígeno en una piscina camaronera, de riego en un lote— funciona aunque el sensor de umbral falle, se descargue o pierda enlace LoRaWAN esa noche. Ya documentamos esta combinación en el caso concreto de aireadores automáticos: un horario conservador que cubre el riesgo previsible, más una capa por umbral que ajusta lo que el horario no anticipó. El error común es usar el horario como única lógica cuando la carga real —biomasa, humedad, demanda— cambia de un día a otro: ahí el horario fijo no ahorra ni protege, solo reproduce siempre el mismo patrón sin importar si hacía falta.
Evento (umbral): reacciona a lo que el sensor mide ahora
Un control por evento —también llamado control por umbral o event-based control— no revisa el reloj: espera a que una variable medida cruce un límite (oxígeno disuelto bajo 3.5 mg/L, humedad de suelo bajo el punto de agotamiento permisible, corriente de un motor fuera de rango) y solo entonces dispara la orden. Es más eficiente que un horario fijo porque solo actúa cuando hace falta, pero introduce dos problemas que un horario no tiene.
El primero es el ruido de sensor: sin una banda de histéresis (deadband), un valor que oscila justo alrededor del umbral enciende y apaga el equipo varias veces por minuto. La práctica estándar en sistemas de alarma industrial —documentada para deadbands de DCS/SCADA— es fijar esa banda entre 0.5% y 1% del rango de la variable, de modo que el equipo no apague hasta que el valor baje del umbral menos la histéresis, no apenas lo cruce en sentido contrario. Ya cubrimos esta misma lógica de deadband y agrupación de alarmas aplicada a energía eléctrica en alarmas configurables sin ruido operativo; el principio es idéntico para cualquier variable de campo, no solo eléctrica.
El segundo problema es la latencia del radio: en una red LoRaWAN Clase A —la más común en nodos de batería—, el nodo solo puede recibir un comando en las ventanas RX1/RX2 que se abren justo después de que el nodo transmite, como explicamos en la nota de actuadores LoRaWAN. Si el evento se dispara en el servidor un segundo después de que el nodo transmitió, la orden espera hasta el siguiente ciclo de transmisión —típicamente varios minutos— antes de poder entregarse. Un control por evento reacciona más rápido que un horario, pero no es instantáneo, y diseñar el intervalo de transmisión del nodo (cada cuánto reporta) es tan parte del diseño del control por evento como el umbral mismo.
IA / predictivo: anticipa antes de que el umbral se cruce
Un modelo predictivo no espera a que la variable cruce el límite: proyecta hacia dónde va la curva en las próximas horas y actúa antes. El ejemplo documentado en nuestra propia plataforma es Oxígeno Inteligente, que combina una capa convolucional (CNN) —que reconoce patrones de forma en la ventana reciente de datos— con una capa recurrente LSTM —que aprende dependencias temporales largas, como el hecho de que el mínimo de oxígeno siempre llega justo antes del amanecer—, con un horizonte de pronóstico de hasta 10 horas, como detallamos en qué puede predecir y qué no.
La ganancia real de un modelo así frente a un umbral no es “más inteligencia” en abstracto, sino dos cosas concretas: horas de margen para actuar antes de que el problema ya esté ocurriendo, y menos falsas alarmas, porque el modelo distingue una caída normal del ciclo día/noche de una caída anómala. El costo también es concreto y casi nunca se menciona en la venta: un modelo predictivo necesita meses de histórico de la variable específica de ese sitio para entrenarse con algo de confianza, no funciona bien desde el primer día de una instalación nueva, y sigue fallando exactamente donde fallan los modelos de series temporales en general —eventos sin precedente en el histórico (una falla mecánica súbita, una piscina recién sembrada sin datos previos)—, razón por la cual el umbral de seguridad nunca debe eliminarse, solo complementarse.
Cómo elegir: cuatro preguntas antes de automatizar
No hay una lógica “superior” en abstracto; hay una que corresponde a cada situación. Cuatro preguntas ayudan a elegir:
- ¿La carga es previsible o varía día a día? Si el consumo o la demanda cambian poco (un horario de iluminación, un ciclo de bombeo fijo), el horario alcanza y agregar sensores solo suma puntos de falla. Si varía con el clima, la biomasa o el cultivo, hace falta al menos un evento.
- ¿Qué tan caro es un falso negativo frente a un falso positivo? Si no actuar a tiempo cuesta una pérdida de producción (oxígeno, riego en floración), conviene sesgar el umbral hacia el lado conservador y aceptar más falsas alarmas. Si el costo real es solo desperdicio de energía, se puede ajustar el umbral hacia menos alarmas y tolerar algo más de riesgo.
- ¿Existe histórico suficiente de esa variable, en ese sitio, para entrenar un modelo? Sin al menos varios meses de datos de la instalación específica, un modelo predictivo no tiene con qué aprender el patrón local; en ese caso, empezar por horario + evento y migrar a predictivo cuando el histórico exista es el camino que de verdad funciona en campo.
- ¿Cuánto tiempo de anticipación se necesita realmente? Si actuar con minutos de margen basta (abrir una válvula, encender un aireador), un evento con buena histéresis es suficiente y más barato de mantener que un modelo. Si se necesitan horas de margen para movilizar una decisión operativa —convocar personal, ajustar una cosecha—, ahí un modelo predictivo justifica su costo.
Las tres capas trabajando juntas, no una sola
En la práctica, un sistema maduro no elige una sola lógica: las apila, cada una cubriendo el punto ciego de la anterior. Un horario base conservador que garantiza un mínimo de seguridad aunque falle todo lo demás; un umbral por evento que ajusta ese mínimo a lo que realmente está pasando esa noche; y, cuando el histórico lo permite, un modelo predictivo que adelanta la decisión unas horas antes de que el umbral se cruce. Esta misma arquitectura de capas —reactivo (feedback) más predictivo (feedforward)— es la que documentamos para riego en sensores, clima y decisiones automáticas: ninguna capa reemplaza a la anterior, cada una reduce el margen de error que deja la otra.
Centralizar las tres capas en un mismo dashboard —no en la lógica interna de cada nodo por separado— es lo que permite ajustar el horario base, el umbral de evento y, cuando aplica, el modelo predictivo, sin tener que reprogramar el firmware de cada actuador Air Control en campo cada vez que cambia la temporada o el cultivo.
Conclusión
Horario, evento e IA no son tres niveles de sofisticación creciente donde el objetivo es “llegar” al más avanzado: son tres herramientas con costos y garantías distintas, y la automatización que de verdad funciona en campo casi siempre combina las tres, con el horario como piso de seguridad, el evento como ajuste en tiempo real y el modelo predictivo —cuando el histórico lo justifica— como margen adicional de anticipación. ¿Necesita definir qué combinación de horario, umbral o modelo predictivo conviene para su operación? Conversemos sobre su caso concreto.