Alertas por umbral en MQTT: recibe avisos cuando los valores salen de rango

Las alertas por umbral en MQTT te avisan en el momento en que una lectura de temperatura, presión o nivel sale de su rango seguro, sin que nadie tenga que estar mirando un panel. En este tutorial publicarás datos de sensores realistas, crearás reglas de alerta por umbral en el portal de ConnectMQ, construirás una alerta equivalente en Node-RED capaz de avisar a las personas y añadirás histéresis y debounce para que un valor que ronda el límite no te inunde de alertas.

Cómo funcionan las alertas por umbral en MQTT

MQTT en sí no tiene el concepto de alerta. Una alerta por umbral es un suscriptor que vigila uno o varios topics, extrae un valor numérico de cada payload y lo compara con un límite. Cuando la comparación pasa de normal a anómala, genera una alerta; cuando vuelve, la desactiva. Dónde se ejecuta ese suscriptor es la principal decisión de diseño:

Muchos equipos los combinan: reglas en el portal para tener visibilidad rápida, más un alertador en Node-RED o propio donde necesitan avisar a alguien. Los enclavamientos de seguridad críticos pertenecen siempre al sistema de control local, nunca a una alerta en la nube.

Paso 1: publica datos de sensores

Necesitas un flujo de números con desviaciones ocasionales. Este script publica la temperatura y la presión de un depósito cada dos segundos y se sale de rango de vez en cuando. Instala el cliente con pip install "paho-mqtt>=2.0".

import json
import math
import random
import time

import paho.mqtt.client as mqtt

# Producción: tu broker de ConnectMQ en el 8883 con TLS y las credenciales del portal.
# Prueba rápida: el broker público en el 1883 con un client ID único.
HOST, PORT = "broker.connectmq.com", 1883
ROOT = "connectmq/demo/a7f3q2/factory1/utilities/tank1"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="tank1-sim-a7f3q2")
# Para tu broker privado:
# client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID")
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
# client.tls_set()
# PORT = 8883
client.connect(HOST, PORT, keepalive=60)
client.loop_start()

t = 0
while True:
    temperature = 60 + 15 * math.sin(t / 30) + random.uniform(-1, 1)
    pressure = 4.0 + random.uniform(-0.2, 0.2) + (1.5 if random.random() < 0.03 else 0)
    payload = {"temperature": round(temperature, 2),
               "pressure": round(pressure, 2),
               "ts": int(time.time())}
    client.publish(f"{ROOT}/telemetry", json.dumps(payload), qos=1)
    t += 1
    time.sleep(2)

La temperatura oscila lentamente entre unos 45 y 75 grados y cruza con regularidad un límite de 70 grados, mientras que la presión supera de vez en cuando los 5 bar. Cambia la parte a7f3q2 del topic por tu propia cadena aleatoria, porque el área pública es visible para todo el mundo.

Paso 2: crea reglas de alerta por umbral en el portal de ConnectMQ

El portal de ConnectMQ incluye reglas de alerta por umbral y un registro de alertas, así que puedes vigilar valores sin desplegar nada más. Apunta el simulador a tu propio broker (las líneas comentadas de arriba) y después:

1. Inicia sesión en el portal y abre tu broker.
2. Confirma que llegan los datos buscando factory1/utilities/tank1/telemetry en el explorador de topics en vivo.
3. Crea una regla de alerta por umbral para ese topic sobre el campo temperature, con un límite superior de 70.
4. Crea una segunda regla sobre el campo pressure con un límite superior de 5.
5. Deja el simulador en marcha y abre el registro de alertas. En un minuto o dos aparecerán las desviaciones de temperatura cuando la onda sinusoidal alcance sus picos, y también los picos ocasionales de presión.

Mantén tus payloads como JSON plano con campos numéricos, como en el simulador. Los valores enterrados en cadenas anidadas o enviados como "70.4 C" son mucho más difíciles de evaluar para cualquier herramienta de alertas. El panel y la vista de dispositivos del portal muestran el mismo depósito junto a las alertas, lo que ayuda cuando necesitas contexto sobre qué más estaba pasando en la línea.

Paso 3: construye alertas con notificación en Node-RED

Cuando una alerta debe llegar a un teléfono, a un canal de chat o a un sistema de tickets, Node-RED es un complemento práctico del broker. Configura un nodo de configuración mqtt-broker con el host de tu broker, el puerto 8883 con TLS activado y las credenciales del portal. Después conecta este flujo:

1. mqtt in suscrito a factory1/utilities/+/telemetry, con salida "a parsed JSON object".
2. Nodo function con la lógica de umbral que aparece a continuación.
3. El nodo de notificación que prefieras: correo electrónico, una integración de chat o una petición HTTP a una herramienta de incidentes.

// Nodo function de Node-RED: alerta por umbral con histéresis por depósito
const HIGH = 70;      // activa cuando la temperatura supera este valor
const CLEAR = 67;     // desactiva solo cuando baja de este valor
const tank = msg.topic.split("/")[2];
const value = Number(msg.payload.temperature);
if (Number.isNaN(value)) return null;

const key = `alarm_${tank}`;
const active = context.get(key) || false;

if (!active && value > HIGH) {
    context.set(key, true);
    msg.payload = { tank, state: "ALARM", temperature: value, limit: HIGH };
    return msg;
}
if (active && value < CLEAR) {
    context.set(key, false);
    msg.payload = { tank, state: "CLEARED", temperature: value };
    return msg;
}
return null;

No hace falta un nodo de filtro después de la función, porque solo emite un mensaje cuando cambia el estado de la alarma. El índice de topic [2] supone topics como factory1/utilities/tank1/telemetry; ajústalo a tu jerarquía. Nuestro tutorial de Node-RED con MQTT explica en detalle cómo instalar Node-RED y configurar el nodo del broker.

Paso 4: evita las avalanchas de alertas con histéresis y debounce

Una comprobación ingenua de "valor mayor que 70" se dispara con cada mensaje mientras el valor está alto, y oscila entre activada y desactivada cuando el ruido empuja una lectura de un lado a otro del límite. Dos técnicas lo solucionan:

• La histéresis usa umbrales distintos para activar y desactivar (70 y 67 en el ejemplo anterior), de modo que el ruido en torno al límite no pueda alternar el estado.
• El debounce exige que la condición persista, por ejemplo durante tres lecturas consecutivas o 30 segundos, antes de activar la alerta. Filtra los picos de una sola muestra causados por ruido eléctrico.

El siguiente alertador en Python aplica ambas técnicas y publica el estado de la alerta en su propio topic retenido, para que los paneles, un gemelo digital 3D de la planta y otros sistemas puedan suscribirse a las alertas como a cualquier otro dato:

import json
import paho.mqtt.client as mqtt

HOST, PORT = "broker.connectmq.com", 1883
ROOT = "connectmq/demo/a7f3q2/factory1/utilities"
RULES = {"temperature": (70.0, 67.0), "pressure": (5.0, 4.6)}  # activar, desactivar
DEBOUNCE = 3

state = {}  # (tank, field) -> {"active": bool, "count": int}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(f"{ROOT}/+/telemetry", qos=1)


def on_message(client, userdata, msg):
    tank = msg.topic.split("/")[-2]
    try:
        data = json.loads(msg.payload)
    except ValueError:
        return
    for field, (raise_at, clear_at) in RULES.items():
        value = data.get(field)
        if not isinstance(value, (int, float)):
            continue
        s = state.setdefault((tank, field), {"active": False, "count": 0})
        if not s["active"]:
            s["count"] = s["count"] + 1 if value > raise_at else 0
            if s["count"] >= DEBOUNCE:
                s["active"] = True
                publish_alert(client, tank, field, "ALARM", value, raise_at)
        elif value < clear_at:
            s["active"], s["count"] = False, 0
            publish_alert(client, tank, field, "CLEARED", value, clear_at)


def publish_alert(client, tank, field, status, value, limit):
    alert = {"tank": tank, "field": field, "status": status,
             "value": value, "limit": limit}
    print(alert)
    client.publish(f"{ROOT}/{tank}/alerts/{field}", json.dumps(alert),
                   qos=1, retain=True)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="alerter-a7f3q2")
client.on_connect = on_connect
client.on_message = on_message
client.connect(HOST, PORT, keepalive=60)
client.loop_forever()

Ejecútalo junto al simulador. Verás un ALARM por cada desviación y un CLEARED cuando el valor se recupera, en lugar de decenas de mensajes.

Elegir buenos umbrales

Los umbrales son una decisión de proceso, no de TI. Un breve checklist ayuda:

1. Parte de los límites de los equipos y de las especificaciones del proceso, y fija la alerta por debajo del límite duro para dejar tiempo de reacción.
2. Usa dos niveles cuando sea útil: un aviso y una alerta crítica.
3. Fija el umbral de desactivación lo bastante lejos del de activación como para absorber el ruido normal.
4. Alerta también ante el silencio: un sensor que deja de publicar suele ser más peligroso que un valor alto. El topic $SYS/broker/connection/{clientId}/state de ConnectMQ, o un mensaje Last Will, te indica cuándo se cae un dispositivo.
5. Revisa el historial de alertas cada mes y retira las alertas sobre las que nadie actúa.

Los límites fijos no son la única opción. Una regla de tasa de cambio, como que la temperatura suba más de cinco grados en un minuto, suele avisar antes que un límite absoluto, porque detecta un fallo de refrigeración cuando el valor todavía está dentro de rango. Estas reglas necesitan estado entre mensajes, así que encajan de forma natural en la función de Node-RED o en el alertador de Python anteriores: guarda el valor y la marca de tiempo anteriores por dispositivo y compara la pendiente con tu límite. Empieza con umbrales sencillos y añade reglas basadas en la tasa de cambio allí donde el registro de alertas muestre que las desviaciones eran evidentes a posteriori.

Para señales más amplias de salud del broker, como el número de conexiones y las tasas de mensajes, consulta nuestra guía de monitorización de un broker MQTT, y usa el artículo sobre la consola de gestión de un broker MQTT para ver dónde encajan las alertas entre las demás funciones de la consola.

Configura alertas por umbral en ConnectMQ

Crea un broker gratuito en app.connectmq.com con el plan Serverless, sin tarjeta de crédito, y añade tu primera regla de alerta por umbral en minutos. ConnectMQ te ofrece un broker MQTT gestionado con el registro de alertas, el explorador de topics y el panel en un único portal. Para un experimento rápido, ejecuta primero el simulador contra el servidor MQTT público gratuito de broker.connectmq.com, pensado solo para pruebas y prototipos, y lee la guía de broker MQTT en la nube cuando planifiques la puesta en producción.

Preguntas frecuentes

¿Puede un broker MQTT enviar alertas por sí mismo?

El protocolo MQTT no incluye alertas, pero algunos brokers MQTT gestionados las añaden en su portal. ConnectMQ ofrece reglas de alerta por umbral y un registro de alertas; para notificaciones a teléfonos o chat, combínalo con Node-RED o con un pequeño servicio suscriptor.

¿Qué es la histéresis en las alertas por umbral?

Consiste en usar un umbral distinto para desactivar una alerta que para activarla, por ejemplo activar por encima de 70 y desactivar por debajo de 67. Así se evita que una alerta oscile cuando un valor con ruido ronda el límite.

¿Cómo genero una alerta cuando un sensor deja de enviar datos?

Usa un mensaje Last Will o el topic de estado de conexión del broker para detectar las desconexiones, y añade a tu alertador un tiempo de espera que se dispare si no llega ningún mensaje dentro del intervalo esperado.

¿Deben basarse las alarmas de seguridad en alertas por umbral MQTT?

No. Las funciones de seguridad pertenecen al sistema de control local. Las alertas por umbral MQTT sirven para dar visibilidad y para la respuesta operativa, no para enclavamientos de protección.