Alarmas que se escuchan: rangos, umbrales y avisos que no cansan

Una alarma que suena todo el día deja de ser una alarma. El manual lo dice sin vueltas: demasiadas alarmas son peor que ninguna, porque el equipo se insensibiliza y deja pasar las importantes. Si todo es crítico, nada es crítico.

Esta nota trata sobre el tiempo real de una operación: qué se mide, qué se dispara, qué queda registrado y, sobre todo, qué llega al teléfono de quién. Son cuatro decisiones: en qué valores poner las alarmas, cuáles se ven y cuáles suenan, quién recibe qué, y cuánto esperar antes de avisar.

Evento, alarma y notificación no son lo mismo

Conviene separar tres cosas que suelen tratarse como una sola.

• Un evento es algo que pasó y quedó registrado: un equipo se conectó, alguien pasó una salida a manual, se aplicó una automatización, se completó una tarea. Todo va a Actividad, una sola lista cronológica con qué fue, cuándo y quién lo hizo.
• Una alarma vigila una variable contra un valor. Si la condición se cumple, se dispara, queda registrada y espera a que alguien la reconozca. Reconocer deja constancia de que alguien la leyó; no soluciona la causa.
• Una notificación es el aviso que sale de la plataforma hacia una persona, por correo, Telegram o push. Cada usuario elige sus canales y de qué eventos quiere enterarse.

El error habitual es crear una alarma y asumir que tiene que sonar. No tiene por qué. Una alarma puede existir solo para verse, y esa distinción es la que permite armar un sistema de avisos que no canse.

Los valores correctos

Una alarma analógica puede ser de tres tipos: por encima de un umbral, por debajo de un umbral o fuera de un rango. Para las variables digitales se define por el estado esperado: si la salida debería estar Encendida y aparece Apagada, la alarma se dispara, o al revés.

El valor de una alarma no es el valor de trabajo. Una alarma puesta sobre la consigna se dispara con cada oscilación normal del control, varias veces por hora, y en una semana nadie la mira. El valor correcto sale del historial: la dinámica de la variable durante una semana buena muestra hasta dónde llega sola, y la alarma va por fuera de eso. Las alarmas configuradas se dibujan sobre las gráficas de la variable, en su valor de activación, así que alcanza con mirar la curva para saber cuántas veces la habría cruzado.

El manual suma dos criterios: umbrales por ambiente y no globales, y pocas alarmas bien elegidas. Y una señal de diagnóstico: reconocer varias veces la misma alarma indica que el umbral está mal calibrado o que el problema es estructural.

Rango más umbral: el sobrerrango

Un solo valor obliga a elegir entre enterarse tarde y enterarse demasiado. La salida es usar dos alarmas sobre la misma variable, una de cada tipo, y darles destinos distintos.

1. 01
   Rango

   Fuera de 22 – 27 °C. Es la banda donde la variable debería vivir. Salir de ella es una desviación: conviene verla, no hace falta que despierte a nadie.

2. 02
   Umbral

   Por encima de 30 °C, más allá del rango. Eso es un sobrerrango: el control ya no alcanza y alguien tiene que actuar.

3. 03
   Notificaciones

   En Mi cuenta > Notificaciones, dentro de Alarmas, se desmarca «fuera de rango» y se dejan marcados los umbrales. El rango sigue existiendo; solo deja de sonar.

El resultado son dos niveles. La salida de rango es una alerta visual: aparece en el widget de alarmas del panel, sobre la curva del indicador, en Actividad y en la insignia del menú. El sobrerrango es el que hace sonar el teléfono. Y como suena poco, cuando suena se lo atiende.

Si los dos extremos son críticos, el esquema es el mismo con dos umbrales: uno por encima y otro por debajo, los dos por fuera del rango.

El filtro es de cada usuario, no de la organización. Quien está en planta puede querer también los rangos en el teléfono; quien supervisa varias plantas, solo los sobrerrangos. La alarma es la misma y cada uno decide cuánto quiere escuchar. Si alguien apaga todos los canales no le llega nada, pero las alarmas se siguen registrando en Actividad.

Nadie recibe aviso de lo que hizo

Las autonotificaciones están desactivadas por diseño. Si alguien pasa una salida a manual y la enciende, el resto del equipo suscripto a ese evento recibe el aviso. Esa persona no: lo acaba de hacer, ya lo sabe, y un teléfono que suena por las acciones propias enseña a ignorarlo.

La regla vale para los eventos que tienen autor: comandar una salida, aplicar una automatización, crear, editar o borrar una alarma, agregar un equipo. Las alarmas y los eventos de conexión no tienen autor, así que les llegan a todos los que los tengan marcados.

Los agentes, con cuenta propia

La segunda y la tercera fila de la tabla son la razón de este apartado. Growcast expone un servidor MCP, así que un asistente de IA puede leer lo mismo que se ve en la app y también actuar: crear tareas, crear alarmas, comandar salidas, aplicar automatizaciones. Si ese asistente se conecta con la cuenta de una persona, para la plataforma es esa persona. Lo que haga por su cuenta no le avisa a su dueño, porque nadie recibe aviso de sus propias acciones, y en Actividad no se distingue qué hizo cada uno.

El manual recomienda lo contrario: crearle al asistente su propia cuenta de Growcast e invitarla a la organización. Desde ahí cada cosa que haga queda a nombre de esa cuenta, en Actividad, en las tareas y en cada registro. Y como es otro usuario, todo el equipo recibe el aviso cuando actúa, incluido quien lo configuró. Un agente que trabaja solo tiene que poder ser escuchado.

La cuenta propia también resuelve los permisos. El asistente trabaja con el rol de su cuenta: si esa cuenta no puede crear un lote, el asistente tampoco, y conviene invitarla con el rol mínimo que necesite. No elimina nada ni administra usuarios, y las acciones sobre el hardware van marcadas para que pida confirmación antes de ejecutarlas. Si algo sale mal, alcanza con quitarle el acceso a esa cuenta.

Conexiones que parpadean

Un enlace de internet inestable produce el peor ruido de todos: desconectado, conectado, desconectado, conectado. Cada parpadeo dura segundos, no afecta nada, porque las reglas corren en el equipo y siguen funcionando sin internet, y aun así cada uno puede ser un aviso en el teléfono.

Para eso existe la demora de desconexión: en las notificaciones de conexión, cada usuario fija cuántos minutos esperar antes de recibir el aviso, entre cero y quince. Cuando el plazo se cumple, la plataforma vuelve a mirar el estado: si el equipo ya volvió, no envía nada. Solo avisa una desconexión que sigue siendo una desconexión.

El valor de la demora se elige por cuánto tiempo puede la operación quedar sin ser vista, no por cuánto molesta el aviso. Mientras tanto el estado en vivo no se pierde: el widget de estado del hardware muestra por sí solo cuando un dispositivo o un módulo se desconecta.

Las alarmas, siempre a la vista

Todo lo anterior saca ruido del teléfono y lo pasa a la pantalla. Para que funcione, la pantalla tiene que mostrarlo: cualquier panel, responda la pregunta que responda, lleva las alarmas a la vista.

• El widget de alarmas activas, filtrado al ambiente del panel, con el botón de reconocer. Su estado normal es una tarjeta vacía, y por eso una tarjeta con texto se lee desde lejos.
• El estado del hardware al lado. Si un módulo está caído, ninguno de los números del panel vale, y eso se tiene que ver antes que los números.
• Indicadores analógicos con la línea de alarma dibujada sobre la curva. Se ve qué tan cerca está la variable del valor que dispara, antes de que dispare.
• La insignia de Actividad en el menú, que suma las alarmas y los eventos sin reconocer, las órdenes en curso y las tareas pendientes. Cuando llega a cero, no hay nada esperando.

Los valores en vivo llegan al navegador por MQTT, sin sondeo: un indicador cambia cuando cambia la variable y una alarma aparece en el panel cuando se dispara. La alerta visual no es un aviso de segunda: es el primero en llegar.

Cierre

• Valores sacados del historial, por fuera de la oscilación normal, por ambiente.
• Rango para ver, umbral para sonar: el rango queda fuera de las notificaciones y el sobrerrango llega al teléfono.
• Nadie recibe aviso de lo propio; por eso cada agente trabaja con su cuenta y con el rol mínimo.
• Una demora de desconexión acorde al enlace, para que un parpadeo no sea una noticia.
• Alarmas y estado del hardware visibles en todos los paneles.

La pantalla avisa primero. El teléfono suena solo cuando hace falta, y por eso se lo atiende.

Ver la plataforma→