> 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.md).
# Rules-Engine
Visuelle BPMN-Rule-Engine — verwandeln Sie Sensordaten mit sicherem Build und Rollback in Alarme, Aktionen und Anreicherung.
Die Rules Engine ist ein visuelles Automatisierungssystem auf Basis von BPMN (Business Process Model and Notation) zur Überwachung von IoT-Geräten in Echtzeit. Wenn Sensordaten die von Ihnen definierten Bedingungen erfüllen, handelt die Engine automatisch — sie löst Alarme aus, reichert Daten von anderen Sensoren an, bevor sie eine Entscheidung trifft, und **sendet Befehle direkt an Ihre Geräte zurück**.
Diese letzte Fähigkeit verändert, was Automatisierung hier bedeutet. Eine Regel benachrichtigt nicht mehr nur einen Menschen, damit dieser handelt — sie kann die Aktion selbst ausführen, sobald eine Bedingung erfüllt ist. Früher löste ein Lecksensor einen Alarm und einen Sprint zum Absperrventil aus; jetzt schließt dieselbe Regel das Ventil automatisch und löst in derselben Auswertung den Alarm aus. Wahrnehmen, entscheiden, handeln — durchgängig, ohne jemanden in der Schleife. Siehe [Ausführen von Gerätebefehlen](/kilo-docs-de/kilo-iot-server/rules-engine/running-device-commands.md).
## So funktioniert es
Regeln sind BPMN-2.0-Workflows: visuelle Flussdiagramme, in denen jeder Knoten eine bestimmte Aufgabe erfüllt. Sie verbinden Knoten mit Flows (Pfeilen), um die Logik aufzubauen. Die Engine führt eine bereitgestellte Regel aus, wenn ihr Start-Event die ausgewählte Quelle empfängt: entweder einen Messwert von einem Sensor oder eine Aktivierung durch eine gespeicherte Trigger-Bedingung.
Jede Regel folgt einem verwalteten Lebenszyklus:
```
Erstellen → Bearbeiten → Bauen → Bereitstellen → Läuft → Stoppen
```
Änderungen, die Sie im visuellen Editor vornehmen, bleiben als Entwurf erhalten, bis Sie sie explizit bauen und bereitstellen. Der Build-Schritt validiert Ihre Regel — er prüft die Diagrammstruktur, verifiziert alle Ausdrücke und bestätigt, dass jeder Pfad vollständig ist. Erst nach einem erfolgreichen Build können Sie die Regel bereitstellen, damit sie mit der Verarbeitung ihrer ausgewählten Sensor- oder Trigger-Quelle beginnt.
## Was Sie erstellen können
Eine Regel beginnt mit einem **Start-Event**. Wählen Sie **Sensorwert** um sie auszuführen, wenn ein ausgewählter Sensor meldet, oder **Trigger-Bedingung** um sie auszuführen, wenn eine gespeicherte Bedingung für ein oder mehrere Geräte aktiv wird. Ein Trigger kann sofort reagieren oder warten, bis die Bedingung weiterhin wahr bleibt. Jedes Mal, wenn die ausgewählte Quelle auslöst, wird die Regel ausgeführt. Innerhalb der Regel können Sie:
* **Bedingungen auswerten** mit Exklusiven Gateways — den Ablauf anhand von CEL-Ausdrücken auf verschiedene Zweige lenken
* **Daten transformieren** mit Script-Tasks — abgeleitete Werte berechnen, Messwerte klassifizieren oder Flags für nachgelagerte Entscheidungen vorbereiten
* **Daten von anderen Sensoren abrufen** mit Anreicherungs-Knoten — Innen- und Außentemperatur vergleichen, Luftfeuchtigkeit mit Belegung korrelieren oder vor einer Entscheidung einen Referenzwert prüfen
* **Alarme auslösen** mit Alarm setzen-Knoten — Alarmdefinitionen mit dynamischen Motivationsnachrichten auslösen und Eskalationsrichtlinien sowie Benachrichtigungen anstoßen
* **Auf Geräte einwirken** mit Befehl ausführen-Knoten — einen Befehl senden (ein Ventil schließen, einen Sollwert vorgeben, ein Relais schalten) direkt an ein Gerät, wenn Bedingungen erfüllt sind, sodass die Regel das Problem umfasst, anstatt es nur zu melden. Siehe [Ausführen von Gerätebefehlen](/kilo-docs-de/kilo-iot-server/rules-engine/running-device-commands.md)
* **Fehler elegant behandeln** mit Rand-Fehlerereignissen — wenn ein Schritt fehlschlägt (zum Beispiel ist ein Sensor während der Anreicherung offline), den Fehler abfangen und auf einen Fallback-Pfad leiten, anstatt die gesamte Regel zu stoppen
Alle Bedingungen und Berechnungen verwenden [CEL](https://cel.dev) (Common Expression Language) — eine sichere, sandboxierte Ausdruckssprache, die für die Auswertung von Bedingungen entwickelt wurde. CEL kann nicht auf Dateien zugreifen, keine Netzwerkaufrufe tätigen und keine Schleifen ausführen. Sie wertet Ausdrücke nur anhand der von Ihnen bereitgestellten Daten aus.
Dieses Gleichgewicht ist absichtlich gewählt. Die meisten alltäglichen Regeln werden erstellt, indem Knoten per Drag-and-drop auf die Arbeitsfläche gezogen und Formulare ausgefüllt werden. CEL erscheint an gezielten Stellen, an denen die Regel exakte Logik benötigt: Gateway-Bedingungen, Script-Tasks, dynamische Alarmmeldungen, Anreicherungs-Lookups und Ein-/Ausgabemappings. Durch CEL kann die Regellogik sehr ausgefeilt werden — verschachtelte Bedingungen, berechnete Schweregrade, Delta-Berechnungen über mehrere Sensoren und dynamische Entscheidungspfade, die weit über einfache Schwellenwertalarme hinausgehen. Sie sind nicht auf beliebige Skripte angewiesen, aber auch nicht auf einfache „wenn Wert > X“-Bedingungen beschränkt.
## Sicherheit und Kontrolle
Die Rules Engine ist für Umgebungen konzipiert, in denen nicht verwaltete Änderungen an der Automatisierung nicht akzeptabel sind:
* **Bearbeitungssperren** — Nur eine Person kann eine Regel gleichzeitig bearbeiten. Andere sehen, wer die Sperre hält und wann sie abläuft. Organisationsinhaber können bei Bedarf eine Sperre aufheben.
* **Automatisches Speichern** — Ihre Arbeit wird während der Bearbeitung automatisch gespeichert, mit sichtbarer Statusrückmeldung ("Speichert...", "Gespeichert", "Autospeichern fehlgeschlagen").
* **Versionsverlauf** — Jedes Speichern erstellt eine Version. Versionen können umbenannt, angezeigt und wiederhergestellt werden. Wenn eine Änderung unerwartetes Verhalten verursacht, können Sie zu jeder früheren Version zurückkehren.
* **Vor der Bereitstellung bauen** — Der Build-Schritt erkennt Strukturfehler, ungültige Ausdrücke und fehlende Verbindungen, bevor Ihre Regel in die Produktion gelangt.
* **Artefakte** — Jeder Build erzeugt ein benanntes Artefakt mit Zeitstempeln, Autor und optionalen Kommentaren. Die Registerkarte Artefakte zeigt genau, was in allen Ihren Regeln bereitgestellt ist.
* **Papierkorb und Wiederherstellung** — Das Löschen einer Regel verschiebt sie in den Papierkorb, nicht in die dauerhafte Löschung. Sie können Regeln aus dem Papierkorb wiederherstellen.
* **Notfallsicherheit** — Das System überwacht den Ausführungszustand der Regeln und stoppt automatisch Regeln, die anhaltende Fehler verursachen, um Kaskadenausfälle zu verhindern.
## Abschnittsinhalte
| Seite | Was es abdeckt |
| --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| [Regelliste und Navigation](/kilo-docs-de/kilo-iot-server/rules-engine/rules-list-and-navigation.md) | Die Hauptseite der Rules Engine — Registerkarten, Aktionen und Navigation |
| [Regeln erstellen](/kilo-docs-de/kilo-iot-server/rules-engine/creating-rules.md) | Wie man eine neue Regel von Grund auf erstellt |
| [Trigger](/kilo-docs-de/kilo-iot-server/rules-engine/triggers.md) | Gespeicherte Bedingungen, Zeitsteuerung, Geräteauswahl und wie ein Trigger mit einer Regel verbunden wird |
| [Visueller Editor](/kilo-docs-de/kilo-iot-server/rules-engine/visual-editor.md) | Die BPMN-Arbeitsfläche — Palette, Eigenschaftsbereich und Symbolleiste |
| [Regeln debuggen](/kilo-docs-de/kilo-iot-server/rules-engine/debugging-rules.md) | Eine Regel vor der Bereitstellung schrittweise durchlaufen — Haltepunkte, Variablen, Beobachtungen, Nebeneffekte |
| [Knotenreferenz](/kilo-docs-de/kilo-iot-server/rules-engine/node-reference.md) | Jeder Knotentyp mit Konfigurationsdetails und Beispielen |
| [Ausführen von Gerätebefehlen](/kilo-docs-de/kilo-iot-server/rules-engine/running-device-commands.md) | Der Knoten Befehl ausführen — eine Regel dazu bringen, auf ein Gerät einzuwirken, nicht nur zu alarmieren |
| [CEL-Referenz](/kilo-docs-de/kilo-iot-server/rules-engine/cel-reference.md) | Typen, Operatoren und Muster der Ausdruckssprache |
| [Bearbeitungssperren und Team-Übergaben](/kilo-docs-de/kilo-iot-server/rules-engine/edit-locks-and-team-handoffs.md) | Sperren, Sperre aufheben erzwingen, Inaktivität und automatisches Speichern |
| [Versionsverlauf und Wiederherstellung](/kilo-docs-de/kilo-iot-server/rules-engine/version-history-and-restore.md) | Versionsverfolgung, Benennung, Anzeige und Wiederherstellung |
| [Builds, Artefakte und Bereitstellung](/kilo-docs-de/kilo-iot-server/rules-engine/builds-artifacts-and-deployment.md) | Regeln bauen, die Registerkarte Artefakte, Bereitstellen und Stoppen |
| [Papierkorb und Wiederherstellung](/kilo-docs-de/kilo-iot-server/rules-engine/trash-and-recovery.md) | Soft Delete, die Papierkorb-Ansicht und das Wiederherstellen von Regeln |
| [Automatisierungsmuster](/kilo-docs-de/kilo-iot-server/rules-engine/automation-patterns.md) | Enterprise-Automatisierungsmuster mit CEL-Beispielen |
| [Fehlerbehebung](/kilo-docs-de/kilo-iot-server/rules-engine/troubleshooting.md) | Build-Fehler, häufige Probleme und Grenzen |
---
# 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.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.
