ZENNER Datahub Howto: Automatisierte Abläufe mit der RuleEngine

Titelbild Blogbeitrag ZENNER Datahub Howto: Mit der RuleEngine Regeln für automatisierte Aktionen erstellen
- 📖🕓 ≈  6 min -

Letzte Änderung am 15.04.2024

Ihr benötigt für euren IoT-Anwendungsfall automatisierte Abläufe beim Eintreten bestimmter Zustände? Mit der ZENNER Datahub RuleEngine könnt ihr dies schnell und einfach umsetzen.

Was ist die ZENNER Datahub RuleEngine?

Die RuleEngine ist ein zentraler Bestandteil der ZENNER Datahubs und ermöglicht es euch, komplexe Regeln und Logiken zu definieren, die beim Eintreten bestimmter Ereignisse oder Bedingungen automatisch ausgeführt werden. Wie genau ihr solche Regeln einrichten könnt, zeigen wir euch im Folgenden Schritt für Schritt.

Wie können neue Regeln erstellt werden?

Schritt 1: Navigation zur RuleEngine

Nach Einloggen in eurem ZENNER Datahub Mandanten klickt ihr auf den Punkt „Regeln“ in der linken Seitenleiste.

B.One Middleware: Zur RuleEngine navigieren
ZENNER Datahub: Zur RuleEngine navigieren

Hier könnt ihr in der „Liste“ alle bereits angelegten Regeln einsehen und bearbeiten sowie neue Regeln erstellen.

Schritt 2: Anlegen und Einrichten der Regel

Wie ihr eine neue Regel erstellen und einrichten könnt, zeigen wir nun anhand eines konkreten Beispiels. In diesem Fall war das Ziel, eine an eine smarte Funksteckdose angeschlossene Signalleuchte über den Öffnungszustand einer überwachten Türe zu steuern. Sobald also der Türsensor signalisiert, dass die Türe geöffnet wurde, sollte über den ZENNER Datahub ein Downlink an die Funksteckdose gehen, um diese anzuschalten. Umgekehrt ein weiterer Downlink, wenn die Türe wieder geschlossen wird.

Um eine neue Regel zu erstellen, klickt ihr einfach links auf „Neue Regel“.

B.One Middleware: Neue Regel mit RuleEngine erstellen
ZENNER Datahub: Neue Regel mit RuleEngine erstellen

Im ersten Schritt vergebt ihr dann im Reiter „Allgemeine Informationen“ einen aussagekräftigen Namen. Dieser dient zur besseren Unterscheidung und eindeutigen Zuordnung. Sobald ihr auf „Speichern“ geht, generieren sich die ID und die Weiterleitungsregel automatisch, diese Felder müsst ihr also nicht manuell befüllen.

B.One Middleware: Beispielregel in der RuleEngine
ZENNER Datahub: Beispielregel in der RuleEngine

Nach erfolgreicher Erstellung der neuen Regel ist es nun Zeit, diese mit Leben zu füllen und entsprechend zu konfigurieren. Dies erfolgt über die weiteren Reiter „Match”, „Aktion bei Übereinstimmung”, „Aktion bei Nichtübereinstimmung” und „JSON”.

Schritt 2.1: Match festlegen

Als nächstes legt ihr den sogenannten „Match“ fest, also welche Bedingung überprüft beziehungsweise erfüllt werden soll.

In diesem Fall sollte festgelegt werden­, dass bei Öffnung der Türe ein Downlink an die Steckdose gesendet wird.

Operator:

Dazu wählt ihr zunächst den passenden Operator aus. Folgende stehen euch aktuell zur Auswahl:

  • UND
  • ODER
  • Weniger als
  • Mehr als
  • Gleich
  • Existiert

In diesem Fall wurde der Operator Gleich gewählt, also ein Abgleich, ob der Sensor einen bestimmten Wert hat (Ist gleich x).

Schablonen / Templates:

Hier wählt ihr aus, was beziehungsweise welches Feld der Operator überprüfen soll. Dafür stehen euch aktuell bereits ein paar vordefinierte Schablonen beziehungsweise Templates zur Verfügung. In diesem Fall konnte einfach auf das Template “Tür” zurückgegriffen werden.

B.One Middleware: Template für neue Regel auswählen
ZENNER Datahub: Template für neue Regel auswählen

Wenn es für euren eigenen Anwendungsfall noch kein passendes Template, könnt ihr hier auch “Benutzerdefiniert” verwenden. Ihr gebt dann manuell den Pfad an, auf welches Feld geprüft werden soll. Den richtigen Pfad findet ihr wiederum in der JSON-Datei eines übertragenen Datenpaketes.

B.One Middleware: Template "Benutzerdefiniert" für neue Regel
ZENNER Datahub: Template "Benutzerdefiniert" für neue Regel

Wert:

Hier stellt ihr ein, welcher Wert gegeben sein muss, damit die Regel ausgelöst wird. In diesem Fall wurde also der Wert Offen hinterlegt.

Das Ganze sieht dann in diesem Fall wie folgt aus:

B.One Middleware: Reiter "Match" nach Befüllen aller Felder
ZENNER Datahub: Reiter "Match" nach Befüllen aller Felder

Schritt 2.2: Aktion bei Übereinstimmung festlegen

Im Reiter „Aktion bei Übereinstimmung“ geht es nun darum zu bestimmen, welche Aktion bei erfolgreicher Abfrage, also einem Match, ausgeführt werden soll. In diesem Fall also, wenn die Tür offen ist bzw. geöffnet wird.

Um einen neuen Befehl zu erstellen müsst ihr zunächst auf das + Symbol rechts klicken, da theoretisch mehrere Aktionen/Befehle gleichzeitig möglich sind.

B.One Middleware: Aktion bei Übereinstimmung in RuleEngine anlegen
ZENNER Datahub: Aktion bei Übereinstimmung in RuleEngine anlegen

Anschließend wählt ihr den passenden Aktionstyp aus. In diesem Fall LoRaWAN Downlink, da ein solcher soll ja bei Türöffnung an die Funksteckdose (Smart Plug) versendet werden soll.

B.One Middleware: Downlink als Aktionstyp bei Übereinstimmung in RuleEngine
ZENNER Datahub: Downlink als Aktionstyp bei Übereinstimmung in RuleEngine

Nun öffnet sich eine neue Maske, in der folgende Felder zu befüllen sind:

B.One Middleware: Aktionstyp Downlink in RuleEngine konfigurieren
ZENNER Datahub: Aktionstyp Downlink in RuleEngine konfigurieren

Nutzlast / Payload:

Die Nutzlast beziehungsweise Payload ist der Code für die Aktion, die der Sensor ausführen soll.

Da die Payload je nach Gerät verschieden und in ihrer hexadezimalen Rohform für uns ohne weitere Informationen unlesbar ist, müsst ihr diese der Payload-Beschreibung entnehmen, die je nach Gerät online oder im Handbuch zu finden ist. Manche Hersteller vereinfachen dies auch und stellen dafür einen entsprechenden Payload-/Downlink-Generator zur Verfügung.

Die richtige Payload lautet in diesem Fall: 1150000601, siehe auch https://support.watteco.com/smartplug/ unter dem Punkt Frame Examples -> Standard Report -> Configuration -> „Power or cut power to the electric device plugged into the SmartPlug“.

Port:

Der Port ist je nach Gerät verschieden. Auch dieser muss im Vorfeld recherchiert werden. In diesem Fall hat der Port der Steckdose die Nummer 125.

DevEUI:

Die DevEUI ist die eindeutige Adresse des Gerätes, das angesteuert werden soll, vergleichbar mit der MAC-Adresse eines Computers oder Gateways. In diesem Fall also die Funksteckdose. Wo die DevEUI zu finden ist, hängt immer etwas vom Hersteller beziehungsweise Lieferanten ab. Bei diesem Gerät steht sie direkt auf dem Gehäuse.

Zusammenfassend:

Mit der Payload wurde angegeben, was der Sensor für eine Aktivität ausführen soll, mit dem Port und der DevEUI, an welches Gerät der Befehl gehen soll.

B.One Middleware: Aktionstyp Downlink in RuleEngine fertig konfiguriert
ZENNER Datahub: Aktionstyp Downlink in RuleEngine fertig konfiguriert

Schritt 2.3: Aktion bei Nichtübereinstimmung festlegen

Hierbei geht es um die Aktion, die ausgeführt werden soll, wenn die Abfrage nicht erfolgreich ist.

Der Aufbau dieses Reiters ist identisch zum vorherigen. Zuerst wieder das + Symbol rechts anklicken und dann den gewünschten Aktionstyp auswählen. Hier ist es ebenfalls möglich, mehrere Aktionen für eine Regel anzulegen. In diesem Fall ist es wieder ein LoRaWAN Downlink.

B.One Middleware: Aktion bei Nichtübereinstimmung in RuleEngine anlegen
ZENNER Datahub: Aktion bei Nichtübereinstimmung in RuleEngine anlegen
B.One Middleware: Downlink als Aktionstyp bei Nichtübereinstimmung in RuleEngine
ZENNER Datahub: Downlink als Aktionstyp bei Nichtübereinstimmung in RuleEngine

Die DevEUI bleibt gleich, es soll ja immer noch die Steckdose angesteuert werden.

Die für diesen Befehl benötigte Payload ist jedoch eine andere und lautet: 1150000600 (vorher …601)

Der Port ist wiederum derselbe wie zuvor: 125

Die Payload endet diesmal auf …600, da ein anderer Befehl an die Steckdose gesendet werden soll. Die Nutzlast …600 sagt aus, dass der Strom der Steckdose ausgeschaltet bleiben bzw. werden soll, somit löst auch die Signalleuchte nicht aus.

Schritt 2.4: JSON Code überprüfen

Der letzte Schritt zum Einrichten der neuen Regel erfolgt im Reiter „JSON“. Hier wird angezeigt, wie die Daten im JSON Format an die Geräte weitergeleitet werden. Somit könnt ihr hier eure Daten nochmals überprüfen und eventuelle manuelle Verbesserungen vornehmen.

In diesem Fall ist der JSON Code etwas komplexer und sieht wie folgt aus:

B.One Middleware: JSON Daten in RuleEngine überprüfen
ZENNER Datahub: JSON Daten in RuleEngine überprüfen

Schritt 2.5: Regel auslösendem Sensor zuweisen

Im letzten Schritt müsst ihr eure Regel noch dem auslösenden Sensor zuweisen, also dem Sensor, auf den der Match aus Schritt 2.1 zutreffen soll. Dazu ruft ihr das entsprechende Gerät über die „Geräteliste“ auf, wechselt auf den Reiter „Weiterleitung“ und fügt unten rechts über das Plus-Symbol die entsprechende Regel hinzu. Sie erscheint dann oben in der Liste der bereits zu diesem Gerät hinzugefügten Weiterleitungsregeln.

B.One Middleware RuleEngine: Regel auslösendem Sensor zuweisen
ZENNER Datahub RuleEngine: Regel auslösendem Sensor zuweisen
B.One Middleware RuleEngine: Liste einem Gerät zugewiesener Regeln
ZENNER Datahub RuleEngine: Liste einem Gerät zugewiesener Regeln

Damit wisst ihr nun, wie ihr mit der ZENNER Datahub Rule Engine Regeln für automatisierte Abläufe/Aktionen erstellen könnt. Ihr habt Fragen dazu oder Verbesserungsideen/-wünsche? Dann hinterlasst unten einfach einen Kommentar oder schickt uns eine Direktnachricht. Dasselbe gilt, wenn ihr wissen wollt, wie das Ganze auch via API über den Endpunkt inventory/rule funktioniert.

Empfohlen2 EmpfehlungenVeröffentlicht in Bedienungshilfen, ZENNER Datahub

Zum Thema passende Artikel

Kommentare