ThingsBoard Rule Engine: Alarme und Benachrichtigungen einrichten

IoT-Plattform souverän und self-hosted aufbauen? WZ-IT plant, installiert und betreibt ThingsBoard auf Ihrer Infrastruktur - in der EU, ohne Cloud-Lock-in. Zur ThingsBoard-Plattform

Alarme in ThingsBoard entstehen in der Rule Engine: Eingehende Telemetrie läuft durch eine Rule Chain, ein Filter- oder Script-Node prüft den Schwellwert, ein Create-Alarm-Node löst bei Überschreitung den Alarm aus, und ein Clear-Alarm-Node räumt ihn wieder ab, sobald der Wert zurückfällt. Die Benachrichtigung (E-Mail, SMS, Slack, Microsoft Teams oder Webhook) übernimmt am elegantesten das Notification Center über einen Alarm-Trigger; alternativ verschickt ein Send-Notification- oder REST-API-Call-Node direkt aus der Rule Chain. Diese Anleitung zeigt das Schritt für Schritt - mit konkreter Beispiel-Rule-Chain, Severity, Status und Test. Stand Juni 2026, ThingsBoard CE 4.3 (Tag 4.3.1.3, Active LTS).

Inhaltsverzeichnis

• Rule Chains und Nodes verstehen
• Die wichtigsten Alarm-Nodes
• Schwellwert-Alarm definieren: Beispiel-Rule-Chain
• Alarm-Severity und Status
• Benachrichtigungen: E-Mail, Slack und Webhook
• Notification Center vs. Send-Notification-Node
• Alarm-Regel testen
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

Rule Chains und Nodes verstehen

Jede Nachricht, die ein Gerät an ThingsBoard schickt, durchläuft die Rule Engine (thingsboard.io). Diese besteht aus Rule Chains - gerichteten Graphen aus Nodes, die über benannte Relations (z. B. True, False, Post telemetry, Created) verbunden sind. Jeder Tenant hat eine Root Rule Chain, in der jede Nachricht startet. Von dort lässt sich auf weitere, dedizierte Rule Chains verzweigen.

Die Root Rule Chain beginnt typischerweise mit einem Input-Node, gefolgt von einem Message Type Switch, der die Nachricht nach Typ aufteilt (Post telemetry, Post attributes, RPC Request und weitere). Telemetrie wird über einen Save Timeseries-Node gespeichert. Für Alarme hängen wir einen zusätzlichen Zweig an den Ausgang Post telemetry. Wenn Sie ThingsBoard noch nicht laufen haben, hilft die Anleitung ThingsBoard installieren; was die Plattform insgesamt leistet, erklärt Was ist ThingsBoard?.

Skripte in den Nodes schreiben Sie standardmäßig in TBEL (ThingsBoard Expression Language), einer schlanken, sandboxed Skriptsprache. JavaScript ist weiterhin wählbar, TBEL ist aber schneller und der empfohlene Default.

Die wichtigsten Alarm-Nodes

Für Alarme brauchen Sie eine Handvoll Nodes. Die folgende Übersicht zeigt ihre Rolle und die wichtigsten Ausgänge:

Der Create-Alarm-Node ist bewusst idempotent: Existiert bereits ein aktiver Alarm desselben Typs am Gerät, aktualisiert er nur dessen End-Zeitstempel und Details (Ausgang Updated), statt einen Duplikat-Alarm zu erzeugen (Ausgang Created). So entsteht aus einer dauerhaft überschrittenen Schwelle genau ein Alarm, nicht hunderte.

Schwellwert-Alarm definieren: Beispiel-Rule-Chain

Ziel: Übersteigt die Temperatur 30 Grad, soll ein Alarm High Temperature mit Severity MAJOR entstehen; fällt sie wieder darunter, wird er gecleart. Bauen Sie dazu in Rule chains eine neue Chain oder erweitern Sie die Root Rule Chain:

1. Message Type Switch - Ausgang Post telemetry weiterverbinden.
2. Filter-Node (Typ Script) mit Namen "Temp > 30?" und folgendem TBEL-Filter:

return msg.temperature > 30;

3. Verbinden Sie den Ausgang True des Filters mit einem Create-Alarm-Node:
   • Alarm type: High Temperature
   • Alarm severity: MAJOR
   • Alarm details function (TBEL), zählt die Auslösungen mit:

var details = {};
if (metadata.prevAlarmDetails != null) {
    var prev = JSON.parse(metadata.prevAlarmDetails);
    details.count = prev.count + 1;
} else {
    details.count = 1;
}
details.temperature = msg.temperature;
return details;

4. Verbinden Sie den Ausgang False des Filters mit einem Clear-Alarm-Node, ebenfalls Typ High Temperature. Damit verschwindet der Alarm automatisch, sobald die Temperatur wieder unter 30 Grad liegt.

Schematisch:

Input → Message Type Switch ──Post telemetry──► Filter "Temp > 30?"
                                                   │
                                          True ────► Create Alarm (MAJOR)
                                                   │
                                          False ───► Clear Alarm

Für reine Schwellwert-Logik ohne eigene Skripte gibt es eine noch einfachere Variante: Unter Alarms → Alarm rules definieren Sie Bedingung, Severity und Clear-Bedingung rein deklarativ über die Oberfläche, empfohlen auf Ebene des Device Profile oder Asset Profile statt am einzelnen Gerät (ThingsBoard, Alarm rules). Die Rule-Chain-Variante lohnt sich, sobald Logik dazukommt (mehrere Keys, Enrichment, Zeitfenster, externe API-Calls).

Alarm-Severity und Status

ThingsBoard kennt fünf feste Severities. Im Create-Alarm-Node wählen Sie einen festen Wert oder aktivieren ein Severity-Pattern, das den Grad dynamisch aus der Nachricht zieht (z. B. ${msg.severity}):

Der Status eines Alarms hat zwei Dimensionen - aktiv/cleared und bestätigt/unbestätigt - und damit vier Ausprägungen: ACTIVE_UNACK, ACTIVE_ACK, CLEARED_UNACK, CLEARED_ACK. Ein neuer Alarm startet als ACTIVE_UNACK. Bestätigt (acknowledge) ein Bediener ihn im Dashboard, wird er ACTIVE_ACK; der Clear-Alarm-Node setzt ihn auf CLEARED_*. Diese Status steuern später auch, welche Notification-Trigger feuern.

Benachrichtigungen: E-Mail, Slack und Webhook

Der moderne und empfohlene Weg in ThingsBoard 4.3 und 4.4 ist das Notification Center (Menüpunkt Notification center, thingsboard.io). Es trennt drei Bausteine sauber:

1. Delivery-Methode konfigurieren (Settings): SMTP-Server für E-Mail, einen SMS-Provider (Twilio, AWS SNS, SMPP), einen Slack-Bot-Token oder eine Microsoft-Teams-Anbindung.
2. Notification Template anlegen: Inhalt (mit Platzhaltern wie ${alarmType}, ${alarmSeverity}) und die Kanäle, über die es zugestellt wird.
3. Notification Rule mit Trigger Alarm anlegen und Template plus Empfängergruppe zuordnen.

Die verfügbaren Delivery-Methoden im Überblick:

Einen generischen Webhook (eigener Endpoint, n8n, Node-RED, Ticketsystem) bedienen Sie nicht über das Notification Center, sondern über den REST-API-Call-Node in der Rule Chain: Verbinden Sie den Ausgang Created Ihres Create-Alarm-Nodes mit einem REST-API-Call-Node, der per POST an Ihre Webhook-URL den Alarm als JSON sendet.

Notification Center vs. Send-Notification-Node

Beide Wege führen zur Benachrichtigung, mit unterschiedlichem Charakter:

• Notification Center (Alarm-Trigger): deklarativ, GUI-basiert, feuert automatisch beim Anlegen, Bestätigen, Clearen oder Severity-Wechsel eines Alarms. Besonders stark sind die Eskalationsketten: Mehrere Empfängerstufen werden mit Verzögerung nacheinander benachrichtigt; bestätigt jemand den Alarm vorher, entfallen die folgenden Stufen. Das ist für die meisten Alarm-Benachrichtigungen die richtige Wahl.
• Send-Notification-Node: sitzt direkt in der Rule Chain und braucht ein Notification Template vom Typ Rule node plus eine Empfängergruppe. Sinnvoll, wenn der genaue Auslösepunkt von Logik in der Chain abhängt (etwa nur bei count > 5 oder nach einem Enrichment-Schritt).

Faustregel: Standard-Alarmierung über das Notification Center, Sonderfälle über Nodes in der Chain.

Alarm-Regel testen

Aktivieren Sie an Filter-, Create-Alarm- und Clear-Alarm-Node den Debug-Modus (Node öffnen, Debug einschalten) - dann sehen Sie In- und Output jeder Nachricht inklusive der gewählten Relation. Anschließend schicken Sie Testwerte über MQTT:

# Wert über Schwellwert -> Alarm soll entstehen
mosquitto_pub -h localhost -p 1883 -u "ACCESS_TOKEN" \
  -t v1/devices/me/telemetry -m '{"temperature": 34}'

# Wert unter Schwellwert -> Alarm soll clearen
mosquitto_pub -h localhost -p 1883 -u "ACCESS_TOKEN" \
  -t v1/devices/me/telemetry -m '{"temperature": 22}'

Prüfen Sie unter Entities → Devices → (Gerät) → Alarms, ob der Alarm High Temperature mit Severity MAJOR und Status ACTIVE_UNACK erscheint und nach dem zweiten Wert auf CLEARED_UNACK wechselt. Den Verlauf der Messwerte und Alarme visualisieren Sie im Dashboard - oder kombiniert mit Grafana, siehe Grafana-IoT-Dashboard mit InfluxDB.

Unser Vorgehen bei WZ-IT

Wir modellieren Alarme entlang Ihrer realen Prozesse: Schwellwerte und Hysterese pro Device Profile, sinnvolle Severities, saubere Clear-Bedingungen und Eskalationsketten, die die richtigen Personen zur richtigen Zeit erreichen - ohne Alarm-Müdigkeit durch Fehlalarme. Dazu gehören getestete Rule Chains, Notification-Templates in DE/EN, die Anbindung Ihrer Kanäle (E-Mail, SMS, Slack, Teams, Webhook ins Ticketsystem) und ein Betrieb mit Monitoring. Alles self-hosted auf Ihrer Infrastruktur, im Rahmen unserer ThingsBoard-Expertise und IoT-Plattformentwicklung.

Weiterführende Guides

• ThingsBoard-Expertise - Beratung, Integration und Betrieb
• ThingsBoard installieren - CE mit Docker Schritt für Schritt
• Was ist ThingsBoard? - Editionen, Architektur und Protokolle
• Grafana-IoT-Dashboard mit InfluxDB - Messwerte und Alarme visualisieren
• ThingsBoard Preise - Editionen, Lizenzen und echte Kosten

Sollen Alarme und Benachrichtigungen in Ihrer IoT-Plattform zuverlässig laufen? Lernen Sie uns kennen oder sehen Sie sich unsere IoT-Plattformen an.