La razón por la que muchas fincas siguen regando por calendario, con un operario que abre y cierra válvulas a mano, no es que desconfíen de la tecnología. Es que ya vieron —o escucharon de un vecino— el caso de un sistema automatizado que se quedó regando toda la noche por un sensor descalibrado, o que no abrió cuando debía porque la señal no llegó. Automatizar aspersores no es solo mandar una orden de apertura por radio; es diseñar el sistema para que, cuando algo falle —y algo va a fallar—, el error sea barato y visible, no una piscina inundada o un lote seco tres días. Esta guía cubre esa parte del diseño que casi nadie documenta.
De qué automatización estamos hablando
Antes de hablar de fallas, conviene distinguir tres niveles de automatización, porque no todos exigen la misma robustez:
- Por calendario: el controlador abre la válvula a una hora fija, sin leer ningún sensor. Es el nivel más simple y el más ciego: riega igual un día nublado que uno de sequía extrema.
- Por umbral de sensor: la válvula se abre cuando la humedad de suelo cruza el umbral de agotamiento permisible (MAD) que calculamos en nuestra guía de humedad de suelo, o cuando el balance hídrico basado en evapotranspiración —cubierto en nuestro artículo sobre ETo— indica déficit.
- Por reglas combinadas: el umbral dispara el riego, pero una lluvia reciente, una alerta de helada o un límite de caudal pueden vetarlo. Este es el nivel donde vale la pena invertir, porque es el que realmente ahorra agua sin regalar control.
Automatizar el primer nivel es fácil y arriesgado a la vez: sin retroalimentación, un controlador por calendario no sabe si la válvula realmente abrió, ni si ya llovió. El resto de este artículo se enfoca en los mecanismos que hacen seguro pasar del nivel 1 al nivel 3.
La arquitectura: de la orden en el dashboard a la válvula abierta
Un sistema de riego automatizado sobre LoRaWAN tiene, típicamente, esta cadena: sensor de suelo o estación meteorológica → gateway LoRaWAN → servidor de red → motor de reglas en el dashboard → comando de bajada (downlink) → actuador de campo → electroválvula.
El eslabón que suele faltar en proyectos improvisados es el actuador: un relé de grado industrial que convierte el comando digital en una señal de 24 VAC sobre la bobina del solenoide. Nuestro Air Control es justamente ese nodo: un actuador LoRaWAN para riel DIN que controla hasta 4 circuitos con relés OMRON o PANASONIC, alimentado normalmente desde la red eléctrica del cuadro de riego —no a batería—, lo que es relevante para el siguiente punto.
Electroválvulas latch vs. mantenidas. La mayoría de proyectos de riego a batería o solar usan válvulas solenoide tipo latch (biestables): un pulso breve, de apenas unos 100 ms, las abre; otro pulso las cierra, y no consumen corriente mientras permanecen en esa posición. Eso las hace compatibles con nodos de bajo consumo. Las válvulas “mantenidas” (las más comunes en riego residencial con 24 VAC continuo) exigen que el actuador sostenga la señal todo el tiempo que la válvula debe estar abierta, lo que en la práctica obliga a un nodo alimentado de la red o con una batería de mayor capacidad, como el caso típico de Air Control en el cuarto de bombeo.
Latencia de radio: por qué la clase de dispositivo LoRaWAN importa aquí
En sensado, que un dato llegue con 10-15 minutos de retraso no cambia una decisión de riego. En control de válvulas, la latencia del comando sí importa, y depende de la clase de dispositivo LoRaWAN del actuador:
- Clase A: el nodo solo puede recibir un downlink justo después de transmitir un uplink. Si el actuador reporta su estado cada 5-10 minutos, el comando de apertura puede tardar hasta ese mismo intervalo en llegar —aceptable para riego programado con antelación, no para una orden de “cerrar ya” ante una fuga.
- Clase C: la ventana de recepción permanece abierta casi todo el tiempo, así que el servidor puede enviar el comando de forma casi inmediata (normalmente por debajo de 1 segundo en una red bien configurada). El costo es un consumo de energía sustancialmente mayor, razón por la que los nodos Clase C casi siempre están conectados a la red eléctrica, no a batería —de nuevo, el escenario típico de un actuador de válvulas en el cuarto de bombeo.
La recomendación práctica: sensores de suelo y estaciones meteorológicas —que solo informan— trabajan bien en Clase A para maximizar autonomía de batería; el actuador que ejecuta la orden de apertura/cierre debería operar en Clase C, alimentado de red, para que la orden de emergencia (cerrar por fuga, cerrar por lluvia) no quede atrapada esperando el próximo uplink. Esta misma lógica de ventanas de recepción y consumo la explicamos con más detalle en nuestro artículo sobre duty cycle y time on air en LoRaWAN.
El principio que no es negociable: falla segura
Todo diseño de automatización de válvulas parte de una pregunta: ¿qué hace el sistema si pierde comunicación, energía, o si el sensor se descalibra? La respuesta correcta, casi sin excepción, es normalmente cerrada: una electroválvula que se cierra por defecto cuando se le retira la energía, no que se queda abierta.
- Un corte de energía en el cuadro de riego cierra la válvula automáticamente, sin necesidad de que llegue ningún comando: es una propiedad física del solenoide, no lógica de software.
- Una pérdida de señal LoRaWAN —un gateway caído, interferencia— deja la válvula en su último estado, que solo es seguro si ese estado por defecto es cerrado.
- El controlador, además, debería implementar un tiempo máximo de riego por evento (por ejemplo, 45 o 60 minutos) que fuerce el cierre aunque nunca llegue el comando de cierre, como respaldo ante cualquier falla de comunicación en el camino de vuelta.
Diseñar al revés —normalmente abierta, “por si acaso falla el cierre hay que regar igual”— invierte el riesgo: cambia una posible sequía de unas horas, que se corrige regando al día siguiente, por una inundación de un lote completo o una factura de agua desproporcionada durante un fin de semana sin nadie mirando el dashboard.
Confirmar, no asumir: el rol del sensor de caudal
El comando de apertura que sale del dashboard confirma que la orden se envió, no que la válvula realmente abrió. Una bobina quemada, un solenoide atascado por sedimento o una válvula manual dejada cerrada aguas abajo son fallas mecánicas comunes que ningún log de comandos detecta por sí solo.
Un sensor de flujo (de efecto Hall para diámetros pequeños, o ultrasónico en líneas principales de mayor diámetro) instalado después de la válvula cierra ese ciclo:
- Confirma apertura real: si el comando de apertura se envió pero el caudal medido es cero después de unos segundos, el sistema puede alertar de una válvula atascada en vez de asumir que el riego está en curso.
- Detecta fugas y roturas: un caudal muy por encima del rango esperado para esa zona —una tubería rota, una válvula que no cerró bien— dispara un cierre de emergencia antes de que el problema se vuelva una pérdida de agua de horas.
- Mide el volumen real aplicado, que es el dato que debería quedar en el registro de riego, no el tiempo que estuvo “supuestamente” abierta la válvula.
No perder el control: override manual y niveles de permiso
La automatización que genera desconfianza es la que no se puede intervenir. Tres mecanismos resuelven eso:
- Interruptor manual local en el actuador. Air Control, como la mayoría de actuadores industriales de este tipo, permite operación manual directa en el relé, independiente de si hay señal LoRaWAN o no. Un operario en el cuarto de bombeo siempre puede forzar apertura o cierre sin depender de la red.
- Override remoto con jerarquía clara. En el dashboard, un comando manual del agrónomo o del jefe de campo debe poder anular temporalmente la regla automática (por ejemplo, “no regar hoy, hay lluvia pronosticada”), y esa anulación debe expirar sola después de un tiempo definido —no quedar activa por accidente una semana entera silenciando la automatización.
- Registro de auditoría. Cada apertura y cierre, automático o manual, con su origen (regla, usuario, botón físico) y el volumen confirmado por el sensor de caudal, debería quedar en el historial del dashboard. Sin ese registro, un desacuerdo sobre “por qué se regó el lote 3 anoche” no tiene forma de resolverse.
Un ejemplo de regla combinada, con números
Una regla operativa razonable para una zona de aspersión, combinando lo anterior:
Abrir la válvula de la zona 4 si la humedad de suelo ponderada cruza el umbral de MAD y no se registró lluvia mayor a 5 mm en las últimas 12 horas y no hay una anulación manual activa. Confirmar apertura por caudal dentro de 10 segundos; si el caudal es cero, cerrar y generar alerta. Cerrar automáticamente a los 45 minutos como respaldo, incluso si no llega el comando de cierre. Si el caudal medido supera 1.3 veces el caudal nominal de la zona, cerrar de inmediato y alertar por posible fuga.
Ninguna de esas condiciones exige inteligencia artificial ni hardware exótico: es lógica de reglas simple sobre datos que ya existen —humedad de suelo, lluvia, caudal— apoyada en un actuador con falla segura y un canal de comunicación con la latencia adecuada para el rol que cumple.
Conclusión
Automatizar aspersores sin perder control no depende de un solo componente, sino de que el diseño completo —válvula normalmente cerrada, actuador en la clase LoRaWAN correcta, sensor de caudal que confirma en vez de asumir, override manual disponible siempre, y un registro de auditoría— trate cada falla previsible como parte del sistema, no como una excepción. Hecho así, automatizar deja de ser un salto de fe y se convierte en una mejora medible: menos horas de operario recorriendo válvulas, menos agua perdida por exceso o por fuga no detectada, y decisiones de riego basadas en datos en vez de en calendario.
En Yubox integramos sensores de suelo y clima, actuadores Air Control para válvulas y bombas, y soluciones completas de agricultura de precisión sobre red LoRaWAN, con las reglas de falla segura y confirmación que describimos aquí ya incorporadas al diseño. Si quiere automatizar el riego de su finca sin perder el control sobre él, conversemos sobre su proyecto.