Medir con hardware propio, actuar con piezas simples, conversar con el resto

Una operación produce datos todo el día: temperatura, humedad, CO₂, humedad del producto o del sustrato, el estado de cada equipo. La pregunta no es si esos datos existen, sino si se puede confiar en ellos lo suficiente como para dejar que una regla actúe sola a las tres de la mañana. Una planilla y un enchufe inteligente no llegan a eso. Un termómetro que redondea, tampoco.

Growcast se construyó sobre tres capas, y cada una vale lo que vale la de abajo. Hardware propio que mide bien. Reglas simples que actúan sobre lo medido, dentro del mismo equipo. Y una capa de abstracción arriba, que se programa o se le habla, y que es confiable justamente porque las dos de abajo son aburridas y deterministas.

1. 01
   El dato

   Sensores propios y sondas de referencia de cada industria, leídos por un dispositivo que registra solo. Sin suavizar, sin carga manual.

2. 02
   La acción

   Reglas y alarmas que corren en el equipo, cada una con su estado de seguridad. Siguen funcionando sin internet.

3. 03
   La abstracción

   Plantillas, editor, agente en lenguaje natural, simulador y un servidor MCP para el asistente que se prefiera.

Capa 1: medir bien, o nada de lo demás sirve

Cada lectura es el último valor real, sin suavizar. La temperatura es 28, no «alrededor de 28». Ese es el punto de partida, y sólo se sostiene si el hardware es propio y se sabe exactamente qué mide, con qué sensor y con qué error.

Un dispositivo Growcast —Growcast, Growcast + o Growcast Industria— lee módulos sensores y comanda módulos de control. Un módulo sensor suele reportar varias variables a la vez —temperatura, humedad, CO₂, presión, humedad de sustrato, pH y conductividad eléctrica, según el módulo—; los de control exponen salidas: ventilación, bombas, extracción, climatización, lo que se conecte. Cada módulo se diseña y se fabrica con el elemento sensor elegido por su precisión y su estabilidad en el tiempo, no por su costo. Un sensor que deriva medio grado por temporada convierte cada umbral en una adivinanza.

Y donde una industria ya tiene un sensor de referencia, no lo reinventamos: lo integramos. El caso más claro es el cultivo de precisión, donde el riego se decide por lo que pasa en el sustrato. Para eso Growcast lee la sonda TEROS 12 de METER Group, que mide contenido volumétrico de agua, conductividad eléctrica y temperatura en el mismo cuerpo: la sonda que los laboratorios y esa industria ya probaron, y contra la que se compara todo lo demás. Cuando una regla decide regar porque el sustrato bajó del 45 %, ese 45 % viene de un instrumento en el que la industria ya confía. La misma lógica vale para cualquier rubro: si existe el instrumento de referencia, la plataforma lo lee como una variable más.

• Precisión y estabilidad del elemento sensor antes que costo: la regla que corre a las tres de la mañana vale lo que vale la lectura.
• Sondas de referencia donde existen, integradas como cualquier otra variable.
• Un módulo reporta cada una de sus variables con su unidad, su rango y su tipo. Un módulo nuevo se ve, se grafica, se alarma y se automatiza el mismo día que se conecta.

Todo lo que entra o sale del equipo se representa igual: como una variable con unidad, rango y tipo, analógica o digital. Esa abstracción única es lo que permite que una sonda y una bomba se traten con las mismas herramientas, sin una pantalla a medida.

El registro es automático. Las últimas 24 horas quedan con un dato por minuto; el historial más viejo se guarda como promedios de 15 minutos. No hay carga manual y no hay un «me parece que ayer estaba en 65».

Dos detalles de infraestructura. Cada dispositivo tiene su propio certificado y una política que limita a qué canales puede publicar: el equipo de una organización no puede ver ni escribir el de otra, y eso se aplica en la capa de transporte, no sólo en la aplicación. Y cada salida digital puede llevar una característica operativa —potencia nominal, caudal, dosis— con la que el sistema aproxima consumo sin medidor: el tiempo encendido por la característica da kWh o litros.

Capa 2: reglas que corren en el equipo

Actuar es comunicarse, no apretar un botón. Cuando se da una orden desde la app no se está tocando la salida: se le está hablando al dispositivo. La orden viaja, el dispositivo la ejecuta y recién ahí la confirma. En Actividad se ve cada acción con su estado, y se sabe si realmente llegó.

Las reglas siguen la misma lógica, con una diferencia: viven en el hardware. Una automatización se arma en la nube, se compila a un formato compacto y se envía al dispositivo, que la evalúa en su propio ciclo de control. Si se cae internet, la regla sigue corriendo. Cuando vuelve la conexión, se sincronizan los estados y los eventos. La nube sirve para enviar reglas nuevas y mostrar lo que pasa, no para decidir en cada segundo.

Las alarmas funcionan igual: se evalúan en el equipo, disparan un evento cuando una variable sale de su umbral o de su rango, y ese evento llega por push, Telegram o correo. Suena una vez, con claridad, y queda pendiente hasta que alguien la reconoce. El estado normal es silencio.

Para armar una regla no hace falta empezar de cero. Los casos conocidos ya están resueltos como plantillas: se elige la salida, se completa un formulario y se guarda. El catálogo trae nueve:

• Por variable: enciende una salida según el valor de otra variable, mayor o menor a una referencia.
• Encendido programado: enciende y apaga dentro de un rango horario.
• Intervalos múltiples: hasta 8 horarios en el día, cada uno con su duración, en los días que se elijan.
• Temporizador cíclico: tanto tiempo encendido y tanto apagado, repetido a lo largo del día.
• Multi-rango: la misma variable con otra referencia según el horario, hasta 6 rangos.
• Por pulsos: encendidos y apagados cortos, repetidos.
• Super ciclo: ciclos de encendido y apagado que duran más de 24 horas.
• Riego: pulsos en dos fases, desde un horario o junto con la luz.
• Riego con sensor: pulsos guiados por la humedad del sustrato.

Así se ve una, el temporizador cíclico: cuánto tiempo encendido y cuánto apagado, desde qué hora y cuántas veces por día, en qué días, y si además tiene que cumplirse una condición sobre una variable.

Las reglas que dependen de un sensor declaran además un estado seguro: en qué queda la salida si ese sensor deja de reportar. Es la decisión más importante de una regla, porque es la que corre justo cuando algo falló.

El control manual convive con las reglas: si se comanda una salida a mano, la automatización vuelve a tomar el control la próxima vez que se cumpla su condición. Para bloquearla, se pausa desde su ficha.

Capa 3: la capa que se programa o se le habla

Sobre esas dos capas se apoya todo lo demás, y por eso todo lo demás puede permitirse ser flexible.

Las plantillas no son cajas cerradas: lo que arma cada una se puede abrir después en el editor avanzado. Y cuando el caso no entra en ninguna, ahí se escribe una regla a medida, a mano o describiéndola en palabras al Agente, que la arma. Antes de mandarla al equipo, el Simulador la prueba contra curvas inventadas. La nota de automatizaciones avanzadas lo cuenta en detalle.

Y hay una capa más afuera. Growcast expone un servidor MCP, el estándar con el que una aplicación le abre sus datos y sus acciones a una IA. Se le conecta Claude, ChatGPT o Gemini y se trabaja hablándole: lee ambientes, variables con su valor actual y su historial, lotes, ciclos, tareas y el manual de usuario; escribe tareas, lotes, alarmas y automatizaciones. Trabaja con su propia cuenta y su propio rol, así que en Actividad se distingue qué hizo el asistente y qué hizo cada persona. Las acciones sobre hardware van marcadas para que pida confirmación, y requieren un dispositivo conectado.

Con tiempo suficiente, esa capa permite operar el proceso desde una conversación. Sin tiempo, permite pedir «una bomba 10 minutos a las 8» y revisar la regla que armó.

Qué significa para el control de un proceso

Un ejemplo corto. A las 03:10 la humedad de un ambiente cae por debajo de la banda definida. La automatización del humidificador lo ve en el equipo y actúa en segundos, sin esperar a la nube. La alarma dispara un único evento y llega al celular de quien está de guardia. A la mañana, el panel muestra la dinámica de la noche con el momento exacto en que se salió y en que volvió. Y si se le pregunta al asistente qué pasó, lee el mismo historial y lo cuenta.

Nada en esa cadena depende de que alguien haya estado despierto. Depende de que el dato fuera real, de que la regla corriera donde está el sensor, y de que la capa de arriba tuviera algo confiable que leer.

Las dos notas siguientes entran en detalle en las herramientas que más se usan sobre estas capas: el constructor de automatizaciones avanzadas, con el crop steering como ejemplo completo, y los paneles, con tres perspectivas distintas sobre la misma operación.

Seguir con las automatizaciones→