> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/rules-engine/automation-patterns.md). # Automatisierungsmuster Automatisierungsmuster für Kilo IoT — Schwellenwertalarme, Anreicherung mit mehreren Sensoren, Eskalation, dynamisches CEL. Diese Seite präsentiert bewährte Automatisierungsmuster für Enterprise-IoT-Implementierungen. Jedes Muster beschreibt ein reales Betriebsszenario, die Struktur des BPMN-Diagramms, die beteiligten CEL-Ausdrücke und wann das Muster verwendet werden sollte. Die meisten dieser Muster werden visuell erstellt, indem Knoten auf der BPMN-Leinwand angeordnet werden. CEL erscheint an den Stellen, an denen die Regel exakte Logik, Klassifizierung oder dynamische Nachrichten benötigt. Da CEL verschachtelte Bedingungen, berechnete Werte, Vergleiche zwischen Sensoren und die dynamische Texterzeugung unterstützt, ist die Bandbreite der Modelliermöglichkeiten groß — von einer einzelnen Schwellwertprüfung bis hin zu mehrstufigen Workflows mit mehreren Sensoren, mit Fallback-Pfaden und abgestufter Eskalation. Diese Muster bauen auf den Knotentypen und Leinwand-Tools auf, die in [Knotenreferenz](/kilo-docs-de/kilo-iot-server/rules-engine/node-reference.md) und [Visuellen Editor](/kilo-docs-de/kilo-iot-server/rules-engine/visual-editor.md). Wenn Sie neu in der Rules Engine sind, beginnen Sie mit [Regeln erstellen](/kilo-docs-de/kilo-iot-server/rules-engine/creating-rules.md) um die Grundlagen zu verstehen. *** ## Muster 1: Einfacher Schwellwertalarm Das häufigste Automatisierungsmuster. Ein Sensor meldet einen Wert, die Regel prüft, ob er einen Grenzwert überschreitet, und löst bei Bedarf einen Alarm aus. ### Diagrammstruktur ``` Start-Ereignis → Skript-Task → Exklusives Gateway → Alarm setzen → End-Ereignis ↓ (Standard) End-Ereignis ``` ### Konfiguration **Start-Ereignis:** An das Zielgerät und den Sensor gebunden — zum Beispiel eine Temperatursonde in einem Kühlraum, die in Grad Celsius meldet. **Skript-Task** — „Schwellwert prüfen“: ``` {"above_threshold": vars.value > 30.0} ``` Dieser Ausdruck erzeugt ein boolesches Flag. Das Gateway verwendet dieses Flag, um zu entscheiden, ob ein Alarm ausgelöst werden soll. **Exklusives Gateway** — Zwei Zweige: * **Alarmzweig:** Bedingung `vars.above_threshold == true` — führt zum Knoten „Alarm setzen“ * **Standardzweig:** Leitet zu einem End-Ereignis weiter (keine Aktion erforderlich, wenn der Messwert im Bereich liegt) **Alarm setzen:** Konfiguriert mit einer vorhandenen [Alarmdefinition](/kilo-docs-de/kilo-iot-server/alarm.md) und einer Begründungsnachricht wie `„Temperaturmesswert hat 30 °C überschritten“`. Der Knoten „Alarm setzen“ löst die Definition aus — Schweregrad, Kanäle und Eskalation werden auf der Seite „Alarme“ konfiguriert, nicht in der Regel selbst. ### Wann dieses Muster verwendet werden sollte * Temperaturüberwachung im Kühlraum — Alarm, wenn die Temperatur über den sicheren Grenzwert steigt * Umgebungsüberwachung im Serverraum — Alarm, wenn Temperatur oder Luftfeuchtigkeit die Betriebsgrenzen überschreiten * Überwachung von Gerätevibrationen — Alarm, wenn die Vibrationsstärke den Basiswert überschreitet * Jedes Ein-Sensor-, Ein-Schwellwert-Szenario, bei dem ein Messwert außerhalb des Bereichs sofortige Aufmerksamkeit erfordert *** ## Muster 2: Mehrstufige Eskalation Wenn ein einzelner Grenzwert nicht ausreicht, klassifiziert dieses Muster den Messwert in Schweregrade und leitet jede Stufe an eine andere Alarmdefinition weiter — so werden für jeden Schweregrad unterschiedliche Benachrichtigungskanäle, Eskalationsketten und Reaktionsverfahren ermöglicht. ### Diagrammstruktur ``` Start-Ereignis → Skript-Task → Exklusives Gateway → Alarm setzen (Kritisch) → End-Ereignis ↓ (Warnung) Alarm setzen (Warnung) → End-Ereignis ↓ (Standard) End-Ereignis ``` ### Konfiguration **Skript-Task** — „Schweregrad klassifizieren“: ``` {"level": vars.value > 80 ? "critical" : vars.value > 50 ? "warning" : "normal"} ``` Dieser Ausdruck bewertet den Messwert und weist einen Schweregrad als Zeichenkette zu. **Exklusives Gateway** — Drei Zweige: * **Kritischer Zweig:** Bedingung `vars.level == "critical"` — führt zur kritischen Alarmdefinition (SMS an den Bereitschaftsingenieur, E-Mail an den Facility Manager) * **Warnzweig:** Bedingung `vars.level == "warning"` — führt zur Warnalarmdefinition (E-Mail an das Betriebsteam) * **Standardzweig:** Leitet zu einem End-Ereignis weiter (normale Messwerte erfordern keine Aktion) ### Wann dieses Muster verwendet werden sollte * HLK-Überwachung mit abgestufter Reaktion — Warnung, wenn eine Zone aus dem Komfortbereich driftet, kritisch, wenn unsichere Werte erreicht werden * Einhaltung von Umweltvorschriften — Warnung, wenn sich ein Messwert einem Grenzwert nähert, kritisch, wenn er ihn überschreitet * Batterieüberwachung — Warnung bei 20 %, kritisch bei 10 %, jeweils mit unterschiedlicher Dringlichkeit der Benachrichtigung * Jedes Szenario, in dem unterschiedliche Schweregrade unterschiedliche Reaktionsgeschwindigkeiten, Kanäle oder Teams erfordern *** ## Muster 3: Vergleich mehrerer Sensoren Manche Entscheidungen erfordern Daten von mehr als einem Sensor. Dieses Muster ruft mithilfe eines Anreicherungs-Knotens einen zweiten Messwert ab, berechnet die Beziehung zwischen den beiden Werten und entscheidet anhand des Ergebnisses. ### Diagrammstruktur ``` Start-Ereignis → Anreicherung → Skript-Task → Exklusives Gateway → Alarm setzen → End-Ereignis ↓ (Standard) End-Ereignis ``` ### Konfiguration **Start-Ereignis:** An einen Innentemperatursensor gebunden. **Anreicherung** — „Außentemperatur abrufen“: Konfiguriert, um den neuesten Messwert eines Außentemperatursensors am selben Standort abzurufen. Der angereicherte Wert wird in nachfolgenden Knoten als Variable verfügbar. **Skript-Task** — „Differenz berechnen“: ``` {"delta": vars.value - vars.outdoor_temp.value, "needs_alarm": vars.value - vars.outdoor_temp.value > 10} ``` Dieser Ausdruck berechnet die Temperaturdifferenz zwischen Innen- und Außensensor und markiert, ob der Abstand den Grenzwert überschreitet. **Exklusives Gateway** — Zwei Zweige: * **Alarmzweig:** Bedingung `vars.needs_alarm == true` — führt zu „Alarm setzen“ * **Standardzweig:** Leitet zu „End-Ereignis“ weiter **Alarm setzen:** Konfiguriert mit einer Begründungsnachricht wie `„Temperaturdifferenz zwischen Innen und Außen überschreitet 10 Grad“`. ### Wichtig: Fehlerbehandlung hinzufügen Anreicherungs-Knoten hängen von externen Daten ab — der Zielsensor kann offline, nicht erreichbar oder veraltete Daten liefern. Fügen Sie dem Anreicherungs-Knoten immer ein **Grenzfehler-Ereignis** hinzu. Siehe [Muster 4](#pattern-4-error-safe-enrichment) für den vollständigen Ansatz zur Fehlerbehandlung. ### Wann dieses Muster verwendet werden sollte * HLK-Effizienzüberwachung — Alarm, wenn der Temperaturunterschied zwischen Innen und Außen auf eine Isolationsstörung oder eine HLK-Fehlfunktion hinweist * Differenzdrucküberwachung — Drucksensoren zwischen Reinraumbereichen vergleichen * Validierung redundanter Sensoren — Messwerte zweier Sensoren vergleichen, die dieselbe Kennzahl erfassen, und alarmieren, wenn sie sich deutlich unterscheiden * Jedes Szenario, bei dem eine Entscheidung von der Beziehung zwischen zwei Datenpunkten statt von einem absoluten Grenzwert abhängt *** ## Muster 4: Fehlergeschützte Anreicherung Jede Regel, die einen Anreicherungs-Knoten verwendet, sollte die Möglichkeit eines fehlgeschlagenen Anreicherungsvorgangs berücksichtigen. Dieses Muster umgibt den Anreicherungs-Knoten mit einem Grenzfehler-Ereignis, das zu einem Fallback-Alarm weiterleitet, und stellt so sicher, dass die Regel niemals stillschweigend fehlschlägt, wenn ein Referenzsensor nicht verfügbar ist. ### Diagrammstruktur ``` Start-Ereignis → Anreicherung → Skript-Task → Exklusives Gateway → Alarm setzen → End-Ereignis | ↓ (Standard) [Grenzfehler] End-Ereignis ↓ Alarm setzen (Fallback) → End-Ereignis ``` ### Konfiguration **Anreicherung:** Gleiche Konfiguration wie in Muster 3 — ruft einen Messwert von einem sekundären Sensor ab. **Grenzfehler-Ereignis:** An den Anreicherungs-Knoten angehängt. Wenn die Anreicherung aus irgendeinem Grund fehlschlägt (Sensor offline, Zeitüberschreitung, fehlende Daten), fängt das Fehlerereignis den Fehler ab und leitet zum Fallback-Pfad weiter. **Alarm setzen (Fallback):** Konfiguriert mit einer anderen Alarmdefinition und einer Begründungsnachricht wie `„Referenzsensor offline — Differenz kann nicht berechnet werden. Manuelle Prüfung erforderlich.“` So wird sichergestellt, dass Ihr Betriebsteam weiß, dass die automatisierte Prüfung nicht abgeschlossen werden konnte. ### Wann dieses Muster verwendet werden sollte * Jede Regel, die Anreicherung verwendet und nicht stillschweigend ausfallen darf * Kritische Überwachungsszenarien, in denen ein fehlender Vergleichswert selbst ein alarmwürdiger Zustand ist * Compliance-Workflows, bei denen jede Überwachungslücke dokumentiert werden muss * Als Standard-Best-Practice: jedem Anreicherungs-Knoten in jeder Regel ein Grenzfehler-Ereignis hinzufügen *** ## Muster 5: Datenverarbeitungspipeline Einige Sensordaten müssen vor der sinnvollen Bewertung vorverarbeitet werden. Dieses Muster verkettet mehrere Skript-Tasks, um Rohmesswerte durch Schritte zur Umrechnung von Einheiten, Kalibrierung oder Normalisierung zu transformieren, bevor das Entscheidungsgateway erreicht wird. ### Diagrammstruktur ``` Start-Ereignis → Skript-Task (Konvertieren) → Skript-Task (Kalibrieren) → Exklusives Gateway → Alarm setzen → End-Ereignis ↓ (Standard) End-Ereignis ``` ### Konfiguration **Skript-Task** — „Einheiten umrechnen“: ``` {"celsius": (vars.value - 32) * 5.0 / 9.0} ``` Wandelt einen Fahrenheit-Wert in Celsius um. Passen Sie die Formel an Ihre spezifischen Umrechnungsanforderungen an. **Skript-Task** — „Kalibrierungs-Offset anwenden“: ``` {"calibrated": vars.celsius - 1.5, "above_threshold": vars.celsius - 1.5 > 25.0} ``` Wendet einen bekannten Kalibrierungs-Offset an (in diesem Beispiel misst der Sensor 1,5 Grad zu hoch) und prüft den korrigierten Wert gegen den Grenzwert. **Exklusives Gateway** — Zwei Zweige: * **Alarmzweig:** Bedingung `vars.above_threshold == true` * **Standardzweig:** Leitet zu „End-Ereignis“ weiter ### Wann dieses Muster verwendet werden sollte * Sensoren, die in Nicht-Standard-Einheiten melden und vor dem Schwellwertvergleich umgerechnet werden müssen * Sensoren mit bekannten Kalibrierungs-Offsets, die vor der Bewertung korrigiert werden müssen * Datennormalisierung für Sensoren verschiedener Hersteller, die dieselbe Kennzahl in unterschiedlichen Skalen melden * Jedes Szenario, in dem rohe Sensordaten einen oder mehrere Transformationsschritte benötigen, bevor sie für Entscheidungen sinnvoll sind *** ## Muster 6: Bedingte Anreicherung mit Fallback-Logik Ein fortgeschritteneres Muster, das Anreicherung, Transformation, Fehlerbehandlung und Entscheidungen mit mehreren Zweigen zu einer einzigen robusten Regel kombiniert. Dieses Muster repräsentiert einen Automatisierungs-Workflow auf Produktionsniveau. ### Diagrammstruktur ``` Start-Ereignis → Anreicherung → Skript-Task (Analysieren) → Exklusives Gateway → Alarm setzen (Kritisch) → End-Ereignis | ↓ (Warnung) [Grenzfehler] Alarm setzen (Warnung) → End-Ereignis ↓ ↓ (Standard) Skript-Task (Fallback) → Alarm setzen (Offline) → End-Ereignis ``` ### Konfiguration **Anreicherung:** Ruft einen Referenzmesswert ab (zum Beispiel die Außenluftfeuchtigkeit für ein Lagerhaus). **Grenzfehler-Ereignis:** Fängt Fehler bei der Anreicherung ab und leitet zu einem dedizierten Fallback-Skript-Task weiter. **Skript-Task (Fallback):** ``` {"level": "offline"} ``` Setzt den Wert auf „offline“, damit der Fallback-Alarm ausgelöst wird. **Skript-Task (Analysieren):** ``` {"delta": vars.value - vars.reference.value, "level": vars.value - vars.reference.value > 20 ? "critical" : vars.value - vars.reference.value > 10 ? "warning" : "normal"} ``` **Exklusives Gateway** — Drei Zweige: * **Kritisch:** `vars.level == "critical"` * **Warnung:** `vars.level == "warning"` * **Standard:** End-Ereignis Dieses Muster behandelt den Happy Path (Anreicherung gelingt, Daten werden analysiert, der passende Alarm wird ausgelöst), den Warnpfad und den Fehlerpfad (Anreicherung schlägt fehl, das Betriebsteam wird über das Sensorproblem informiert) — alles in einer einzigen Regel. *** ## Best Practices für das Erstellen von Automatisierungsregeln ### Einfach anfangen, Komplexität nur bei Bedarf hinzufügen Beginnen Sie mit Muster 1 (einfacher Schwellwert) und fügen Sie Anreicherung, mehrstufige Klassifizierung oder Transformationsschritte nur hinzu, wenn das Betriebsszenario sie wirklich erfordert. Eine einfache Regel, die zuverlässig funktioniert, ist besser als eine komplexe, die schwer zu beheben ist. ### Benennen Sie Ihre Knoten aussagekräftig Standardknotennamen wie „Skript-Task 1“ sind bei der Fehlersuche bedeutungslos. Benennen Sie Knoten nach ihrer Funktion: „Temperaturschwellwert prüfen“, „Schweregrad klassifizieren“, „Außenmesswert abrufen“. Ihr zukünftiges Ich — und Ihre Kolleginnen und Kollegen — werden es zu schätzen wissen, wenn Sie die Regel um 3 Uhr morgens prüfen. ### Bei Gateways immer einen Standardzweig hinzufügen Jedes Exklusive Gateway sollte einen Standardzweig haben, der zu einem End-Ereignis führt. Dadurch wird sichergestellt, dass die Regel sauber abgeschlossen wird, selbst wenn keine der expliziten Bedingungen zutrifft. Ohne Standardzweig hat die Regel bei unerwarteten Werten keinen weiteren Pfad. ### Anreicherungs-Knoten immer mit Grenzfehler-Ereignissen versehen Anreicherung hängt von externen Daten ab. Wenn der Zielsensor offline, gelöscht oder vorübergehend nicht erreichbar ist, schlägt die Anreicherung fehl. Ein Grenzfehler-Ereignis bietet einen sauberen Fallback — entweder durch Weiterleitung zu einem „Sensor offline“-Alarm oder durch vollständiges Überspringen der anreicherungsabhängigen Logik. ### Alarmunterdrückungsfenster verwenden, um Benachrichtigungsfluten zu verhindern Wenn ein Grenzwert dauerhaft überschritten wird, verhindern die Unterdrückungs- und Wiederholungseinstellungen der Alarmdefinition, dass Betreibende mit doppelten Benachrichtigungen überflutet werden. Konfigurieren Sie diese Einstellungen in Ihrem [Alarmdefinitionen](/kilo-docs-de/kilo-iot-server/alarm.md) statt zu versuchen, die Unterdrückungslogik in die Regel selbst einzubauen. ### Ausdrücke einfach halten CEL-Ausdrücke sollten leicht lesbar und verständlich sein. Wenn ein Ausdruck länger als eine Zeile wird, teilen Sie die Logik in mehrere Skript-Tasks auf. Jede Aufgabe übernimmt eine Berechnung, und die Ergebnisse werden als Variablen an den nächsten Schritt weitergegeben. ### Eine Regel pro Thema Widerstehen Sie der Versuchung, eine einzige Regel zu bauen, die Temperatur, Luftfeuchtigkeit, CO2 und Vibration gleichzeitig überwacht. Getrennte Regeln lassen sich leichter versionieren, testen, bereitstellen und unabhängig debuggen. Wenn eine Regel aktualisiert oder zurückgerollt werden muss, laufen die anderen unbeeinflusst weiter. ### Bewusst erstellen und bereitstellen Nachdem Sie Änderungen vorgenommen haben, bauen Sie die Regel, um sie zu validieren. Prüfen Sie den Namen und den Kommentar des Build-Artefakts. Stellen Sie erst bereit, wenn Sie sicher sind, dass die Regel korrekt ist. Der explizite Ablauf „bauen, dann bereitstellen“ soll verhindern, dass ungetestete Änderungen in die Produktion gelangen. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kiloiot.io/kilo-docs-de/kilo-iot-server/rules-engine/automation-patterns.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.