MQTT-Schwellenwert-Alarme: benachrichtigt werden, wenn Werte den Bereich verlassen

MQTT-Schwellenwert-Alarme melden Ihnen in dem Moment, in dem ein Temperatur-, Druck- oder Füllstandswert seinen sicheren Bereich verlässt, ohne dass jemand auf ein Dashboard starren muss. In diesem Tutorial publizieren Sie realistische Sensordaten, legen Schwellenwert-Alarmregeln im ConnectMQ-Portal an, bauen einen gleichwertigen Alarm in Node-RED, der Personen benachrichtigen kann, und ergänzen Hysterese und Entprellung, damit ein Wert, der an der Grenze pendelt, Sie nicht mit Alarmen überflutet.

Wie MQTT-Schwellenwert-Alarme funktionieren

MQTT selbst kennt keine Alarme. Ein Schwellenwert-Alarm ist ein Subscriber, der ein oder mehrere Topics beobachtet, aus jedem Payload einen Zahlenwert extrahiert und ihn mit einem Grenzwert vergleicht. Kippt der Vergleich von normal auf abnormal, löst er einen Alarm aus; kippt er zurück, hebt er den Alarm auf. Wo dieser Subscriber läuft, ist die zentrale Designentscheidung:

Viele Teams kombinieren sie: Portalregeln für schnelle Sichtbarkeit und einen Node-RED- oder eigenen Alarmdienst dort, wo jemand alarmiert werden muss. Sicherheitskritische Verriegelungen gehören immer in das lokale Steuerungssystem, niemals in einen Cloud-Alarm.

Schritt 1: Sensordaten publizieren

Sie brauchen einen Zahlenstrom mit gelegentlichen Ausreißern. Dieses Skript publiziert alle zwei Sekunden Temperatur und Druck eines Tanks und driftet ab und zu aus dem Bereich. Installieren Sie den Client mit pip install "paho-mqtt>=2.0".

import json
import math
import random
import time

import paho.mqtt.client as mqtt

# Produktion: Ihr ConnectMQ-Broker auf 8883 mit TLS und Zugangsdaten aus dem Portal.
# Schnelltest: der öffentliche Broker auf 1883 mit eindeutiger Client ID.
HOST, PORT = "broker.connectmq.com", 1883
ROOT = "connectmq/demo/a7f3q2/factory1/utilities/tank1"

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="tank1-sim-a7f3q2")
# Für Ihren privaten Broker:
# 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)

Die Temperatur schwingt langsam zwischen etwa 45 und 75 Grad und überschreitet regelmäßig eine Grenze von 70 Grad, während der Druck gelegentlich über 5 bar springt. Ändern Sie den Teil a7f3q2 des Topics in eine eigene Zufallszeichenkette, denn der öffentliche MQTT-Broker ist für Tests gedacht und für alle sichtbar.

Schritt 2: Schwellenwert-Alarmregeln im ConnectMQ-Portal anlegen

Das ConnectMQ-Portal enthält Schwellenwert-Alarmregeln und ein Alarmprotokoll, sodass Sie Werte überwachen können, ohne etwas zusätzlich zu deployen. Richten Sie den Simulator auf Ihren eigenen Broker aus (die auskommentierten Zeilen oben) und gehen Sie dann so vor:

1. Melden Sie sich im Portal an und öffnen Sie Ihren Broker.
2. Prüfen Sie, ob die Daten ankommen, indem Sie factory1/utilities/tank1/telemetry im Live-Topic-Explorer suchen.
3. Legen Sie für dieses Topic eine Schwellenwert-Alarmregel auf dem Feld temperature mit einer Obergrenze von 70 an.
4. Legen Sie eine zweite Regel auf dem Feld pressure mit einer Obergrenze von 5 an.
5. Lassen Sie den Simulator laufen und öffnen Sie das Alarmprotokoll. Innerhalb von ein bis zwei Minuten erscheinen Temperaturüberschreitungen, wenn die Sinuskurve ihren Höchststand erreicht, und auch gelegentliche Druckspitzen tauchen auf.

Halten Sie Ihre Payloads wie im Simulator als flaches JSON mit numerischen Feldern. Werte, die in verschachtelten Strings stecken oder als "70.4 C" gesendet werden, kann jedes Alarm-Tool deutlich schwerer auswerten. Dashboard und Geräteansicht des Portals zeigen denselben Tank neben den Alarmen, was hilft, wenn Sie Kontext darüber brauchen, was sonst gerade auf der Linie passiert ist.

Schritt 3: benachrichtigende Alarme in Node-RED bauen

Wenn ein Alarm ein Telefon, einen Chat-Kanal oder ein Ticketsystem erreichen muss, ist Node-RED eine praktische Ergänzung zum Broker. Konfigurieren Sie einen mqtt-broker-Konfigurations-Node mit dem Host Ihres Brokers, Port 8883 mit aktiviertem TLS und den Zugangsdaten aus dem Portal. Verdrahten Sie dann diesen Flow:

1. mqtt in mit Subscription auf factory1/utilities/+/telemetry, Ausgabe „a parsed JSON object".
2. function-Node mit der unten stehenden Schwellenwert-Logik.
3. Ein Benachrichtigungs-Node Ihrer Wahl: E-Mail, eine Chat-Integration oder ein HTTP-Request an ein Incident-Tool.

// Node-RED-Function-Node: Schwellenwert-Alarm mit Hysterese pro Tank
const HIGH = 70;      // auslösen, wenn die Temperatur darüber steigt
const CLEAR = 67;     // erst aufheben, wenn sie darunter fällt
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;

Nach der Funktion ist kein Filter-Node nötig, weil sie nur dann eine Nachricht ausgibt, wenn sich der Alarmzustand ändert. Der Topic-Index [2] setzt Topics wie factory1/utilities/tank1/telemetry voraus; passen Sie ihn an Ihre Hierarchie an. Unser Node-RED-MQTT-Tutorial erklärt ausführlich, wie Sie Node-RED installieren und den Broker-Node konfigurieren.

Schritt 4: Alarmfluten mit Hysterese und Entprellung stoppen

Eine naive Prüfung „Wert größer als 70" schlägt bei jeder Nachricht an, solange der Wert hoch ist, und flattert an und aus, wenn Rauschen einen Messwert über die Grenze hin und her schiebt. Zwei Techniken beheben das:

• Hysterese nutzt getrennte Schwellen zum Auslösen und Aufheben (oben 70 und 67), sodass Rauschen um die Grenze herum den Zustand nicht umschalten kann.
• Entprellung verlangt, dass die Bedingung anhält, zum Beispiel für drei aufeinanderfolgende Messwerte oder 30 Sekunden, bevor der Alarm ausgelöst wird. Sie filtert einzelne Ausreißer durch elektrisches Rauschen heraus.

Der folgende Python-Alarmdienst wendet beides an und publiziert den Alarmzustand auf ein eigenes Retained-Topic, sodass Dashboards und andere Systeme Alarme wie alle anderen Daten abonnieren können. In einem Unified Namespace (UNS) nach ISA-95 liegt ein solches Alarm-Topic direkt neben den Messwerten der Anlage, etwa acme/werk-stuttgart/versorgung/tanklager/tank-1/alerts/temperature, sodass MES, Leitstand und Instandhaltung Alarme an derselben Stelle finden wie die Prozessdaten:

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)}  # auslösen, aufheben
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()

Führen Sie ihn neben dem Simulator aus. Sie sehen pro Überschreitung ein ALARM und ein CLEARED, sobald sich der Wert erholt, statt Dutzender Nachrichten.

Gute Schwellenwerte wählen

Schwellenwerte sind eine Prozessentscheidung, keine IT-Entscheidung. Eine kurze Checkliste hilft:

1. Gehen Sie von Anlagengrenzen und Prozessspezifikationen aus und setzen Sie den Alarm unterhalb der harten Grenze, damit Zeit zum Reagieren bleibt.
2. Nutzen Sie zwei Stufen, wo es hilft: eine Warnung und einen kritischen Alarm.
3. Legen Sie die Aufhebungsschwelle weit genug von der Auslöseschwelle entfernt, um normales Rauschen zu schlucken.
4. Alarmieren Sie auch bei Stille: Ein Sensor, der nicht mehr publiziert, ist oft gefährlicher als ein hoher Wert. Das Topic $SYS/broker/connection/{clientId}/state bei ConnectMQ oder eine Last-Will-Nachricht zeigt Ihnen, wenn ein Gerät wegfällt.
5. Überprüfen Sie die Alarmhistorie monatlich und schaffen Sie Alarme ab, auf die niemand reagiert. In der Prozessindustrie beschreibt IEC 62682 (entspricht ISA-18.2) diesen Lebenszyklus des Alarmmanagements; die Norm ist ein guter Rahmen, auch wenn Ihre MQTT-Alarme nur der Sichtbarkeit dienen.

Feste Grenzen sind nicht die einzige Option. Eine Regel zur Änderungsrate, etwa ein Temperaturanstieg um mehr als fünf Grad pro Minute, warnt oft früher als eine absolute Grenze, weil sie einen Kühlungsausfall erkennt, solange der Wert noch im Bereich liegt. Solche Regeln brauchen einen Zustand über mehrere Nachrichten hinweg und passen daher natürlich in die Node-RED-Funktion oder den Python-Alarmdienst oben: Speichern Sie den vorherigen Wert und Zeitstempel pro Gerät und vergleichen Sie die Steigung mit Ihrem Grenzwert. Beginnen Sie mit einfachen Schwellenwerten und ergänzen Sie ratenbasierte Regeln dort, wo das Alarmprotokoll zeigt, dass Überschreitungen im Nachhinein offensichtlich waren.

Für umfassendere Signale zum Broker-Zustand wie Verbindungszahlen und Nachrichtenraten lesen Sie unseren Leitfaden zum MQTT-Broker-Monitoring; im Artikel zur MQTT-Broker-Verwaltungskonsole sehen Sie, wo Alarme zwischen den anderen Konsolenfunktionen ihren Platz haben.

Schwellenwert-Alarme mit ConnectMQ einrichten

Legen Sie unter app.connectmq.com einen kostenlosen Broker im Serverless-Plan an, ganz ohne Kreditkarte, und fügen Sie in wenigen Minuten Ihre erste Schwellenwert-Alarmregel hinzu. ConnectMQ bietet Ihnen einen verwalteten MQTT-Broker mit Alarmprotokoll, Topic-Explorer und Dashboard in einem Portal. Für ein schnelles Experiment vorab führen Sie den Simulator gegen den kostenlosen öffentlichen MQTT-Broker aus, und wenn Sie die Produktion planen, lesen Sie den Leitfaden zum Cloud-MQTT-Broker.

Häufig gestellte Fragen

Kann ein MQTT-Broker selbst Alarme senden?

Das MQTT-Protokoll kennt keine Alarmierung, doch manche verwalteten MQTT-Broker ergänzen sie in ihrem Portal. ConnectMQ bietet Schwellenwert-Alarmregeln und ein Alarmprotokoll; für Benachrichtigungen an Telefone oder Chats kombinieren Sie es mit Node-RED oder einem kleinen Subscriber-Service.

Was ist Hysterese bei Schwellenwert-Alarmen?

Sie bedeutet, zum Aufheben eines Alarms eine andere Schwelle zu verwenden als zum Auslösen, zum Beispiel Auslösen über 70 und Aufheben unter 67. Das verhindert, dass ein Alarm flattert, wenn ein verrauschter Wert um die Grenze pendelt.

Wie alarmiere ich, wenn ein Sensor keine Daten mehr sendet?

Nutzen Sie eine Last-Will-Nachricht oder das Verbindungszustands-Topic des Brokers, um Trennungen zu erkennen, und ergänzen Sie in Ihrem Alarmdienst ein Timeout, das auslöst, wenn innerhalb eines erwarteten Intervalls keine Nachricht eintrifft.

Sollten sich Sicherheitsalarme auf MQTT-Schwellenwert-Alarme verlassen?

Nein. Sicherheitsfunktionen gehören in das lokale Steuerungssystem. MQTT-Schwellenwert-Alarme dienen der Sichtbarkeit und betrieblichen Reaktion, nicht als Schutzverriegelung.