Cómo convertir reglas y alarmas de ThingsBoard en una respuesta operativa

El aviso llegó; la responsabilidad no

Una temperatura supera el límite durante treinta segundos y llega un correo a tres personas. Una lo ve, otra supone que mantenimiento ya intervino y la tercera no conoce el activo. La variable vuelve a rango y el evento desaparece de la vista principal. La plataforma notificó correctamente, pero el proceso de respuesta quedó abierto.

La diferencia entre evento, alarma y acción debe definirse antes de activar canales de notificación.

Qué hace el Rule Engine

La documentación de ThingsBoard describe al Rule Engine como la columna de procesamiento de datos. Un mensaje puede filtrarse, enriquecerse con atributos, transformarse y dirigirse a acciones como guardar telemetría, crear una alarma o llamar a otro sistema. El recorrido se organiza en *rule chains* y nodos conectados por relaciones de éxito, falla u otros resultados.

Eso permite combinar condiciones. Una corriente elevada puede adquirir otra severidad si el equipo está en marcha, la producción está activa y el valor persiste durante una ventana. El diseño debe evitar reglas que reaccionen a una única muestra cuando el proceso necesita persistencia, histéresis o contexto de operación.

Cada regla se documenta con:

• señal y origen;
• condición de entrada y salida;
• ventana temporal;
• comportamiento ante dato faltante o tardío;
• severidad y destinatario;
• evidencia disponible para diagnosticar;
• criterio de prueba y reversión.

La condición debe indicar además si trabaja con una medición directa, un valor escalado o una variable calculada. Una alarma basada en caudal estimado hereda la validez de la medición de nivel y de la conversión configurada. Si cualquiera de las dos entra en error o queda fuera de servicio, corresponde tratar la calidad antes de comparar el resultado contra un límite.

Ciclo de vida de una alarma

En ThingsBoard una alarma tiene originador, tipo, severidad y estado. Los estados combinan dos dimensiones: activa o resuelta, reconocida o no reconocida. Reconocer indica que alguien vio el evento; no significa que la condición terminó. Limpiar o resolver tampoco borra el historial.

La unicidad por originador y tipo evita crear una fila nueva cada vez que persiste la misma condición activa. Esto ayuda a reducir duplicados, pero exige nombrar los tipos de alarma con criterio. “Falla” es demasiado amplio; “presión de descarga baja durante marcha” ofrece más contexto y permite asociar una respuesta.

Una matriz de alarmas debería incluir al menos:

Falla del dato y falla del proceso

Una regla puede fallar aunque la máquina esté bien. ThingsBoard registra resultados de procesamiento como éxito, falla o timeout y ofrece estadísticas y modo de depuración. Las colas tienen estrategias de envío, orden y reintento. La documentación advierte que ciertos reintentos pueden bloquear una cola cuando un error lógico se repite indefinidamente, y que las estrategias en ráfaga o lote no garantizan orden por entidad.

Estas decisiones afectan alarmas. Si el orden importa, hay que elegir una estrategia adecuada. Si una integración externa está caída, conviene aislarla para que no detenga el procesamiento principal. Si una notificación falla, debe poder distinguirse de la condición industrial que la originó.

La prueba de Nodira cubre caminos normales y fallidos: valor que entra y sale del rango, repetición, dato atrasado, mensaje duplicado, nodo que falla, notificación no disponible y acumulación de cola. La observabilidad debe permitir localizar el nodo y el mensaje que causaron un problema.

Para probar sin forzar el proceso puede utilizarse una señal simulada, identificada de forma inequívoca y limitada a usuarios autorizados. El ensayo debe comprobar activación, persistencia, reconocimiento, resolución y rutas de error. Después se repite con el origen real; una simulación aprobada no valida montaje, calibración ni comunicación del instrumento.

Notificar con una responsabilidad explícita

ThingsBoard puede mostrar alarmas en dashboards y activar notificaciones por distintos canales según configuración y edición. El canal no define la responsabilidad. Una alarma crítica enviada a un grupo sin guardia puede tener menos efecto que una alarma mayor asignada a un responsable con procedimiento.

Antes de activar el flujo hay que confirmar destinatarios, horarios, escalamiento y sistema de registro. Si la acción pertenece a un CMMS o mesa de ayuda, la integración debe preservar identificador, estado y cierre para evitar dos historiales inconexos.

Una guía de diagnóstico breve puede organizar la respuesta por síntoma, causas probables y acciones verificables. Ese formato ayuda a diferenciar una condición de proceso de una falla de instrumento, parametrización o comunicación. No convierte una alarma en diagnóstico automático: orienta la inspección y deja evidencia de qué se comprobó.

La alarma termina en un procedimiento

Rule Engine, colas, estados, asignación, historial y notificaciones cubren el recorrido dentro de ThingsBoard. Nodira diseña la lógica, separa condiciones industriales de fallas técnicas y prueba las rutas de error. Responsables, tiempos y procedimientos pertenecen a la organización que operará el sistema; ninguna regla puede sustituirlos.