Beispiel Temperatur-Alarm

Beispiel Temperatur-Alarm

Dieses Beispiel zeigt eine einfache Rulechain, die einen Alarm erzeugt, sobald ein Temperaturwert einen Grenzwert von 5 °C überschreitet. Fällt der Wert wieder auf 5 °C oder darunter, wird der Alarm wieder gelöscht.

Damit eignet sich das Beispiel gut, um den grundsätzlichen Aufbau einer Rulechain zu verstehen:

• Nachrichten kommen in die Kette hinein
• mehrere Knoten prüfen schrittweise die Bedingungen
• je nach Ergebnis wird ein Alarm erzeugt oder gelöscht

Gesamtübersicht der Beispielregel

Die vollständige Rulechain besteht aus mehreren Knoten, die nacheinander verbunden sind.

Der Ablauf ist wie folgt:

1. Eine Nachricht gelangt über den Input in die Rulechain.
2. Der Knoten Filter Devices prüft, ob die Nachricht von einem der gewünschten Geräte stammt.
3. Der Knoten Filter Message prüft, ob der gewünschte Temperaturkanal in der Nachricht enthalten ist.
4. Der Knoten Temperature Threshold bewertet den Grenzwert.
5. Bei True wird ein Alarm erzeugt.
6. Bei False wird ein vorhandener Alarm wieder gelöscht.

Schritt 1: Geräte filtern

Der erste inhaltliche Knoten ist der Gerätefilter.

Dieser Knoten erhält:

• einen Namen
• die Auswahl der Geräte, für die die Regel gelten soll

In diesem Beispiel wurden zwei Demo-Geräte ausgewählt. Nur Nachrichten dieser Geräte dürfen die Rulechain weiter durchlaufen. Nachrichten anderer Geräte werden an dieser Stelle blockiert.

Damit wird die Regel gezielt auf einen definierten Gerätebereich beschränkt.

Schritt 2: Nachrichteninhalt prüfen

Im nächsten Schritt wird überprüft, ob die eingehende Nachricht den zu überprüfenden Temperaturkanal enthält.

Hier wird:

• ein Name für den Knoten vergeben
• unter Message Data der zu prüfende Kanal ausgewählt bzw. manuell eingegeben

info

Um den Kanal mauell einzugene, muss dieser einfach eingetippt und mit Eingabe bestätigt werden. Die manuelle Eingabe des zu prüfenden Kanals is case-sensitiv

Mit der Option Check that all selected keys are present wird sichergestellt, dass nur Nachrichten weitergegeben werden, die den gewählten Schlüssel tatsächlich enthalten.

Fehlt der Kanal in der Nachricht, wird die Verarbeitung an dieser Stelle beendet.

Schritt 3: Grenzwert mit Skript prüfen

Danach folgt ein Skriptknoten, der den eigentlichen Schwellwert überprüft.

In diesem Beispiel ist die Logik bewusst einfach:

return msg.temperature > 5;

Die Aussage des Skripts lautet:

• True, wenn der Temperaturwert größer als 5 ist
• False, wenn der Wert kleiner oder gleich 5 ist

Der Knoten besitzt entsprechend zwei Ausgänge:

• True
• False

So wird die Rulechain an genau dieser Stelle in zwei fachliche Pfade aufgeteilt.

hinweis

Der genaue Variablenname innerhalb eines Skriptknotens kann je nach Knotentyp oder Kontext variieren. Für die Fachlogik des Beispiels ist entscheidend, dass der Temperaturwert gelesen und gegen den Grenzwert verglichen wird.

Schritt 4: Alarm erzeugen

Wenn die Bedingung erfüllt ist, läuft die Nachricht über den True-Pfad in den Alarm-Knoten.

Hier wird festgelegt:

• welcher Alarmtyp erzeugt werden soll
• welchen Schweregrad der Alarm besitzt

Im Beispiel wird ein Alarm vom Typ Temperature Alarm mit dem Schweregrad Critical erzeugt.

Optional könnten an dieser Stelle zusätzliche Details ergänzt werden, zum Beispiel:

• der aktuelle Temperaturwert
• berechnete Zusatzinformationen
• aktualisierte Alarm-Metadaten

Für das Grundbeispiel bleibt der Knoten bewusst einfach.

Schritt 5: Alarm löschen

Wenn die Bedingung nicht mehr erfüllt ist, läuft die Nachricht über den False-Pfad in den Knoten zum Löschen des Alarms.

Hier wird angegeben, welcher Alarmtyp entfernt werden soll. In diesem Beispiel ist das derselbe Typ:

• Temperature Alarm

Dadurch wird ein aktiver Alarm wieder geschlossen, sobald die Temperatur den Grenzwert nicht mehr überschreitet.

Schritt 6: In die Root Rule Chain einbinden

Damit die neue Regel tatsächlich ausgeführt wird, muss sie an eine aktive Verarbeitungskette, also die Root Regel angebunden werden.

Im gezeigten Beispiel wird die erstellte Rulechain hinter den Pfad Save Time Series in der Root Rule Chain eingebunden. Das ist in diesem fall notwendig, weil die Temperatur als Telemetriedatenkanal vom Gerät gesendett wird und damit über den Telemetry-Pfad in die Rule Engine gelangt. Sie wird hinter dem Save Timseries Knoten eingebunden, um die normale Basisverarbeitung nicht zu unterbrechen. Es gilt nun also:

Geräte sendet "Temperature" -> "Temperature" wird ganz normal verarbeitet und in der Datenbank gespeichert -> Nach dem speichern in der Datenbank wird "Temperature" and die AlarmEvaluierungRegel weitergeleitet.

Erst durch diese Einbindung wird die erstellte Logik im laufenden System wirksam.

Ergebnis

Nach dem Speichern und Aktivieren funktioniert die Regel wie vorgesehen:

• Temperatur über 5 °C führt zu einem Alarm
• Temperatur bei 5 °C oder darunter löscht den Alarm wieder

Einordnung

Dieses Beispiel zeigt eine bewusst einfache Rulechain, enthält aber bereits die wichtigsten Grundmuster:

• Eingangsfilter
• Datenprüfung
• Bedingungslogik
• unterschiedliche Pfade für True und False
• Aktion auf Basis des Ergebnisses

Auf dieser Grundlage lassen sich auch komplexere Rulechains aufbauen, etwa für:

• mehrstufige Alarmierung
• Benachrichtigungen per E-Mail oder andere Kanäle
• Anbindung externer APIs
• Kombination mehrerer Geräte- oder Datenbedingungen

Zurück zur allgemeinen Einführung:

• Rulechain Grundlagen