Triggerschemata

Triggerschemata bündeln Prüfzeitpunkt, Bedingungen und auszuführende Aktionen zu wiederverwendbaren Regeln.

Aufbau eines Schemas

Ein Schema kann mehrere Trigger enthalten. Jeder Trigger umfasst Bedingungen und Aktionen; Bedingungen lassen sich mit AND / OR verknüpfen. Das Schema kann aktiviert oder deaktiviert und mit einem Gesamtgültigkeitszeitraum versehen werden.

Bedingung	Zweck
CRON	Ausführung nach einem Kalenderzeitplan
TIME_POINT	Ausführung zu festgelegten täglichen Uhrzeiten, kombinierbar mit dem Gültigkeitszeitraum des Schemas
TIME_PERIOD	Prüfung innerhalb eines festgelegten Zeitfensters
INTERVAL	Prüfung in festen Zeitabständen
DATA_CHANGE	Bedingung bei einer Datenpunktänderung auswerten; unterstützt freigegebene Daten

Datenbedingungsskripte geben einen booleschen Wert zurück. Prüfen Sie fehlende Daten ausdrücklich oder konvertieren Sie zunächst mit tonumber, damit fehlende Werte nicht als gültige Beobachtung behandelt werden.

Aktionen und Rückgabewerte

Aktionen können beschreibbare Datenpunkte, Zeitpläne, Aggregationsvariablen oder entfernte Geräte beschreiben. Sie können außerdem Alarme protokollieren, Alarmbeobachtungen übermitteln und MQTT-Nachrichten veröffentlichen.

Schema oder Szenario	Skriptrückgabe
EXPRESSION-Schema	Aktionsarray mit Indexbeginn 1
MIXED-Einzelpunktschreiben	Einzelwert für den betreffenden Datenpunkt
Datenänderungsbedingung	true / false

Beispiel: Eine aggregierte Laufzeitvariable in einer EXPRESSION-Aktion aktualisieren:

return {buildGeneralWriteMap("Aggregation", "demo_state", "ready", false)}

Ersetzen Sie die Beispieldatenpunkte vor der Nutzung durch die tatsächliche Konfiguration. Die Funktion erstellt lediglich eine auszuführende Aktion und bestätigt keine erfolgreiche Geräteausführung.

Alarmregeln

Für einfache Benachrichtigungen können einzelne Alarmeinträge erzeugt werden. Wenn Wiederherstellung und Bearbeitungsablauf benötigt werden, verwenden Sie Alarmereignisse. Melden Sie fortlaufend ACTIVE-, NORMAL- oder UNKNOWN-Beobachtungen und lösen Sie nicht nur bei Störungen aus.

Nachverarbeitung und Ausführungsprotokolle

Aktionen unterstützen Nachverarbeitung über needPostProcess / postProcessContent. Die Skriptvalidierung kann die Rückgabestruktur prüfen, wertet den Ausdruck jedoch aus. Prüfen Sie bei Skripten mit direkten Aufrufen daher vorab deren Seiteneffekte.

In Triggerprotokollen lassen sich Bedingungen, Ausführungsergebnisse und Fehler prüfen. Bei der Gerätesteuerung sollten Sie zusätzlich Gerätesteuerungsprotokolle und zurückgelesene Datenpunktwerte kontrollieren, um gesendete Anfragen von tatsächlich ausgeführten Aktionen zu unterscheiden.

Dynamische Geräte und Aktivierung von Schemata

Abfragen nach Präfix, Suffix und anderen Kriterien ermöglichen die Verarbeitung wechselnder Gerätezahlen. Sammelabfragen liefern eine nach dataKey indizierte Tabelle; verwenden Sie dafür pairs(). Bei dynamisch zusammengesetzten Abfragemustern ist die Vollständigkeit der Abhängigkeiten zu prüfen. Betroffene Datenpunkte können im Schema hinterlegt werden. Ihre aktuellen Werte erscheinen in der Detailansicht und erleichtern das Verständnis der Strategie.

Bei deaktivierten, gelöschten oder ungültigen Schemata werden Laufzeitaufgaben entfernt. Vor der Ausführung wird zudem der Zustand des übergeordneten Schemas geprüft. Bereits an Geräte gesendete Befehle müssen dennoch auf ihr tatsächliches Ergebnis geprüft werden. Begrenzen Sie bei häufig ausgeführten Strategien nach Bedarf die Aufruffrequenz, um wiederholte Befehle zu reduzieren.

Ausführliche Skripte: Triggeraktionsreferenz und Lua-Referenz. Für die Konfiguration durch einen Agenten steht der Triggerschema-Skill bereit.