Alertes de seuil MQTT : soyez prévenu quand les valeurs sortent de leur plage

Les alertes de seuil MQTT vous signalent l'instant où une mesure de température, de pression ou de niveau sort de sa plage sûre, sans que personne n'ait à fixer un tableau de bord. Dans ce tutoriel, vous allez publier des données de capteurs réalistes, créer des règles d'alerte de seuil dans le portail ConnectMQ, construire une alerte équivalente dans Node-RED capable de prévenir des personnes, et ajouter de l'hystérésis et un anti-rebond pour qu'une valeur qui oscille autour de la limite ne vous submerge pas d'alertes.

Comment fonctionnent les alertes de seuil MQTT

MQTT n'a en soi aucune notion d'alerte. Une alerte de seuil est un abonné qui surveille un ou plusieurs topics, extrait une valeur numérique de chaque payload et la compare à une limite. Lorsque la comparaison passe de normal à anormal, il déclenche une alerte ; lorsqu'elle revient à la normale, il la lève. L'endroit où tourne cet abonné est le principal choix de conception :

Beaucoup d'équipes les combinent : des règles dans le portail pour une visibilité rapide, plus un alerteur Node-RED ou sur mesure lorsqu'il faut prévenir quelqu'un. Les verrouillages de sécurité relèvent toujours du système de contrôle local, jamais d'une alerte cloud.

Étape 1 : publier des données de capteurs

Il vous faut un flux de valeurs avec des dépassements occasionnels. Ce script publie la température et la pression d'une cuve toutes les deux secondes, en sortant de temps à autre de la plage. Installez le client avec pip install "paho-mqtt>=2.0".

import json
import math
import random
import time

import paho.mqtt.client as mqtt

# Production : votre broker ConnectMQ sur 8883 avec TLS et les identifiants du portail.
# Test rapide : le broker public sur 1883 avec un client ID unique.
HOST, PORT = "broker.connectmq.com", 1883
ROOT = "connectmq/demo/a7f3q2/factory1/utilities/tank1"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="tank1-sim-a7f3q2")
# Pour votre broker privé :
# 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 température oscille lentement entre environ 45 et 75 degrés, franchissant régulièrement une limite de 70 degrés, tandis que la pression dépasse parfois brièvement 5 bar. Remplacez la partie a7f3q2 du topic par votre propre chaîne aléatoire, car l'espace public du serveur MQTT public gratuit est visible par tous : il sert aux tests, pas aux données de production.

Étape 2 : créer des règles d'alerte de seuil dans le portail ConnectMQ

Le portail ConnectMQ inclut des règles d'alerte de seuil et un journal des alertes : vous pouvez surveiller des valeurs sans rien déployer d'autre. Pointez le simulateur vers votre propre broker (les lignes commentées ci-dessus), puis :

1. Connectez-vous au portail et ouvrez votre broker.
2. Vérifiez que les données arrivent en trouvant factory1/utilities/tank1/telemetry dans l'explorateur de topics en direct.
3. Créez une règle d'alerte de seuil pour ce topic sur le champ temperature, avec une limite haute de 70.
4. Créez une seconde règle sur le champ pressure avec une limite haute de 5.
5. Laissez tourner le simulateur et ouvrez le journal des alertes. En une minute ou deux, les dépassements de température apparaissent aux pics de la sinusoïde, ainsi que les pics de pression occasionnels.

Gardez vos payloads en JSON plat avec des champs numériques, comme dans le simulateur. Des valeurs enfouies dans des chaînes imbriquées ou envoyées sous la forme "70.4 C" sont bien plus difficiles à évaluer pour n'importe quel outil d'alerting. Le tableau de bord et la vue des appareils du portail affichent la même cuve à côté des alertes, ce qui aide quand vous avez besoin de contexte sur ce qui se passait d'autre sur la ligne.

Étape 3 : construire des alertes avec notification dans Node-RED

Lorsqu'une alerte doit atteindre un téléphone, un canal de discussion ou un outil de ticketing, Node-RED est un compagnon pratique du broker. Configurez un nœud de configuration mqtt-broker avec l'hôte de votre broker, le port 8883 avec TLS activé et les identifiants du portail. Câblez ensuite ce flow :

1. mqtt in abonné à factory1/utilities/+/telemetry, sortie « a parsed JSON object ».
2. Un nœud function avec la logique de seuil ci-dessous.
3. Le nœud de notification de votre choix : e-mail, intégration de messagerie ou requête HTTP vers un outil de gestion d'incidents.

// Nœud function Node-RED : alerte de seuil avec hystérésis par cuve
const HIGH = 70;      // déclencher quand la température dépasse cette valeur
const CLEAR = 67;     // lever uniquement quand elle redescend sous cette valeur
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;

Aucun nœud de filtrage n'est nécessaire après la fonction, car elle n'émet un message que lorsque l'état de l'alarme change. L'index de topic [2] suppose des topics comme factory1/utilities/tank1/telemetry ; adaptez-le à votre hiérarchie. Notre tutoriel Node-RED MQTT détaille l'installation de Node-RED et la configuration du nœud broker.

Étape 4 : stopper les avalanches d'alertes avec hystérésis et anti-rebond

Une vérification naïve « valeur supérieure à 70 » se déclenche à chaque message tant que la valeur est haute, et oscille entre activée et désactivée lorsque le bruit fait passer une mesure de part et d'autre de la limite. Deux techniques règlent le problème :

• L'hystérésis utilise des seuils de déclenchement et de levée distincts (70 et 67 ci-dessus), pour que le bruit autour de la limite ne puisse pas basculer l'état.
• L'anti-rebond exige que la condition persiste, par exemple pendant trois mesures consécutives ou 30 secondes, avant de déclencher l'alerte. Il filtre les pics isolés dus au bruit électrique.

L'alerteur Python suivant applique les deux et publie l'état des alertes sur son propre topic retained, pour que tableaux de bord et autres systèmes puissent s'abonner aux alertes comme à n'importe quelle autre donnée :

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)}  # déclenchement, levée
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()

Lancez-le à côté du simulateur. Vous voyez un seul ALARM par dépassement et un seul CLEARED lorsque la valeur revient à la normale, au lieu de dizaines de messages.

Bien choisir ses seuils

Les seuils relèvent d'une décision de procédé, pas d'une décision informatique. Une courte checklist aide :

1. Partez des limites des équipements et des spécifications du procédé, puis placez l'alerte sous la limite absolue pour laisser le temps de réagir.
2. Utilisez deux niveaux lorsque c'est utile : un avertissement et une alerte critique.
3. Placez le seuil de levée suffisamment loin du seuil de déclenchement pour absorber le bruit normal.
4. Alertez aussi sur le silence : un capteur qui cesse de publier est souvent plus dangereux qu'une valeur élevée. Le topic $SYS/broker/connection/{clientId}/state sur ConnectMQ, ou un message Last Will, vous indique quand un appareil décroche.
5. Passez en revue l'historique des alertes chaque mois et supprimez celles sur lesquelles personne n'agit.

Les limites fixes ne sont pas la seule option. Une règle de taux de variation, comme une température qui monte de plus de cinq degrés en une minute, prévient souvent plus tôt qu'une limite absolue, car elle détecte une panne de refroidissement alors que la valeur est encore dans la plage. Ces règles nécessitent un état d'un message à l'autre : elles s'intègrent donc naturellement dans la fonction Node-RED ou l'alerteur Python ci-dessus. Conservez la valeur et l'horodatage précédents par appareil et comparez la pente à votre limite. Commencez par des seuils simples, puis ajoutez des règles de taux de variation là où le journal des alertes montre que les dépassements étaient prévisibles a posteriori.

Pour des signaux plus larges sur la santé du broker, comme le nombre de connexions et les débits de messages, consultez notre guide sur la supervision d'un broker MQTT, et lisez l'article sur la console de gestion d'un broker MQTT pour voir la place des alertes parmi les autres fonctionnalités de la console.

Configurer des alertes de seuil sur ConnectMQ

Créez un broker gratuit sur app.connectmq.com avec le plan Serverless, sans carte bancaire, et ajoutez votre première règle d'alerte de seuil en quelques minutes. ConnectMQ vous offre un broker MQTT managé avec le journal des alertes, l'explorateur de topics et le tableau de bord dans un seul portail. Pour une première expérience rapide, faites tourner le simulateur sur le serveur MQTT public gratuit, et lisez le guide du broker MQTT cloud lorsque vous préparez la production.

Questions fréquentes

Un broker MQTT peut-il envoyer des alertes par lui-même ?

Le protocole MQTT ne prévoit pas d'alerting, mais certains brokers MQTT managés l'ajoutent dans leur portail. ConnectMQ fournit des règles d'alerte de seuil et un journal des alertes ; pour des notifications vers des téléphones ou une messagerie, associez-le à Node-RED ou à un petit service abonné.

Qu'est-ce que l'hystérésis dans les alertes de seuil ?

Il s'agit d'utiliser un seuil différent pour lever une alerte et pour la déclencher, par exemple déclencher au-dessus de 70 et lever sous 67. Cela évite qu'une alerte oscille lorsqu'une valeur bruitée tourne autour de la limite.

Comment être alerté quand un capteur cesse d'envoyer des données ?

Utilisez un message Last Will ou le topic d'état de connexion du broker pour détecter les déconnexions, et ajoutez dans votre alerteur un délai d'attente qui se déclenche si aucun message n'arrive dans l'intervalle prévu.

Les alarmes de sécurité doivent-elles reposer sur des alertes de seuil MQTT ?

Non. Les fonctions de sécurité relèvent du système de contrôle local. Les alertes de seuil MQTT servent à la visibilité et à la réponse opérationnelle, pas aux verrouillages de protection.