> 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/node-reference.md). # Knotenreferenz Knotenreferenz für die Rules Engine — Start, Ende, Skript, Gateway, Alarm setzen, Anreicherung, Grenze. Jede Automatisierungsregel besteht aus einer Reihe von Knotentypen, die Sie auf die Zeichenfläche des visuellen Editors ziehen, mit Flows verbinden und über ein Eigenschaftenfeld konfigurieren. Diese Seite dokumentiert jeden Knotentyp — was er tut, wann er verwendet wird, wie er auf der Zeichenfläche erscheint und jedes Feld in seinem Eigenschaftenfeld. Auf dieser Seite werden die Knoten dokumentiert, die derzeit in der Live-Palette verfügbar sind: **Start-Ereignis**, **Endereignis**, **Skriptaufgabe**, **Exklusives Gateway**, **Alarm setzen**, **Befehl ausführen**, **Anreicherung**, und **Grenzfehlerereignis**. Übergangs- oder geplante Knoten werden absichtlich ausgeschlossen, bis sie Teil der Live-Editor-Oberfläche sind. Für einen Überblick über die Zeichenfläche selbst — Palette, Symbolleiste und allgemeinen Bearbeitungsablauf — siehe [Visueller Editor](/kilo-docs-de/kilo-iot-server/rules-engine/visual-editor.md). *** ## Start-Ereignis Das Startereignis ist der Einstiegspunkt jeder Regel. Es entscheidet, was die Regel auslöst — entweder die Sensorwerte eines einzelnen Geräts oder ein gespeichertes [Trigger](/kilo-docs-de/kilo-iot-server/rules-engine/triggers.md) das eine Bedingung für ein oder mehrere Geräte auswertet. Jede Regel muss genau ein Startereignis haben. ### Visuelle Darstellung Ein Kreis mit einem Umschlag-Icon darin. ### Wann verwenden Jede Regel beginnt hier. Ohne Startereignis können Sie keine gültige Regel erstellen. ### Eigenschaftenfeld Wählen Sie das Startereignis auf der Zeichenfläche aus — darunter erscheinen ein Bleistift- und ein Papierkorb-Symbol. Klicken Sie auf den **Bleistift** um rechts sein Eigenschaftenfeld zu öffnen. **Name** — Ein Textfeld für die Knotenbeschriftung. Platzhalter: *z. B. Feueralarm*. **Startquelle** — Eine Auswahlliste mit zwei Optionen, die bestimmt, wonach das restliche Feld fragt. Ein Startereignis nennt die eine oder die andere Quelle; beide oder keine anzugeben wird abgelehnt. | Option | Womit die Regel startet | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sensorwert** | Messwerte eines einzelnen Geräts. Die Regel wird jedes Mal ausgelöst, wenn dieser Sensor meldet. | | **Auslösebedingung** | Ein gespeichertes [Trigger](/kilo-docs-de/kilo-iot-server/rules-engine/triggers.md). Seine Bedingung kann sofort oder nach einer Dauer wirken und kann ein oder mehrere Geräte unabhängig auswerten. Die Regel läuft, wenn der Auslöser sie signalisiert. | **Ereignisfilter** — Wird angezeigt, wenn **Startquelle** ist **Sensorwert**. Ein Abschnitt mit der Überschrift „Definieren Sie, welche Geräte diese Regel auslösen können.“ mit zwei Feldern: | Feld | Beschreibung | | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Gerät** | Durchsuchbares Autovervollständigungs-Dropdown. Platzhalter: *Gerät auswählen*. Listet alle Geräte in Ihrer Organisation auf. | | **Sensor** | Autovervollständigungs-Dropdown. Platzhalter: *Sensor auswählen*. Deaktiviert, bis ein Gerät ausgewählt wurde. Zeigt nur Sensoren an, die zum ausgewählten Gerät gehören. | **Auslösebedingung** — Wird anstelle des Ereignisfilters angezeigt, wenn **Startquelle** ist **Auslösebedingung**. Ein einzelnes Autocomplete, Platzhalter *Auslöser auswählen*, das die auf der **Auslöser** Registerkarte definierten Auslöser auflistet. > Es wird nur die erste Seite der Auslöser geladen, und das Feld weist darauf hin, wenn es mehr gibt. Wenn der benötigte Auslöser nicht in der Liste ist, liegt das daran — siehe [Auslöser](/kilo-docs-de/kilo-iot-server/rules-engine/triggers.md). **Zeitplan aktivieren** — Ein Schalter (standardmäßig Aus). Wenn er auf Ein gestellt wird, erscheinen die folgenden Felder: | Feld | Beschreibung | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Zeitbereich** | Erscheint, wenn Zeitplan auf Ein steht, mit der Überschrift *„Zeitbereich. Die Regel ist nur während dieses Zeitraums aktiv:“*. Ein **Zeitplan ändern** Button öffnet den Editor, in dem Sie die Wochentage auswählen, an denen die Regel ausgeführt werden darf, sowie die **Von** und **Bis** Uhrzeiten. Außerhalb dieses Zeitfensters wird die Regel nicht ausgeführt. Bei einer Triggerquelle laufen Überwachung und Countdowns weiter; nur der versuchte Regellauf wird übersprungen. | | **Zeitzone** | Ein Dropdown mit standardmäßigen Zeitzonen, damit dasselbe Zeitfenster überall gleich verstanden wird. | **Eingaben** — Optional. Eine Liste erweiterter CEL-Ausdrücke zur Datenaufbereitung. Die meisten Regeln lassen dies leer und lesen den eingehenden Messwert direkt. Jede Eingabe hat: * Einen Eingabenamen (Textfeld) * Eine Typkennzeichnung (gesperrt auf „Ausdruck“) * Ein CEL-Ausdrucksfeld * Neue Eingaben mit dem **+ Eingabe hinzufügen** Button hinzufügen. Eine Eingabe mit ihrem Löschen-Button entfernen. **Ausgaben** — Optional. Gleiche Struktur wie Eingaben, mit einem eigenen **+ Ausgabe hinzufügen** Button. Verwenden Sie Ausgaben, um benannte Werte in `vars` für nachgelagerte Knoten zu veröffentlichen. **Speichern / Abbrechen** — Am unteren Rand des Feldes. Klicken Sie auf **Speichern** um die Änderungen zu übernehmen, oder auf **Abbrechen** um sie zu verwerfen. ### Wie Daten vom Startereignis fließen Die Prozessvariablen hängen davon ab, **Startquelle**. **Sensorwert** liefert: | Variable | Inhalt | | ---------------- | ---------------------------------- | | `vars.value` | Der gemeldete Wert des Sensors | | `vars.sensor_id` | Die eindeutige Kennung des Sensors | | `vars.timestamp` | Der Zeitstempel des Messwerts | **Auslösebedingung** liefert: | Variable | Inhalt | | ------------------- | --------------------------------------------------------------------------------------------------------- | | `vars.device_name` | Der Name des überwachten Geräts, das den Auslöser erfüllt hat | | `vars.subject_kind` | Der Typ der überwachten Ressource; derzeit `Gerät` | | `vars.subject_id` | Die eindeutige Kennung des überwachten Geräts | | `vars.sensor_id` | Die Sensor-ID, die verwendet wird, um den Lauf und einen möglichen Alarm dem überwachten Gerät zuzuordnen | | `vars.detector_id` | Die eindeutige Kennung des Auslösers | | `vars.timestamp` | Die Zeit des Auslösesignals als Unix-Sekunden | Eine durch einen Auslöser gestartete Regel erhält kein `vars.value`. Siehe [Daten, die der Regel zur Verfügung stehen](/kilo-docs-de/kilo-iot-server/rules-engine/triggers.md#data-available-to-the-rule) bevor eine durch einen Sensor gestartete Regel umgewandelt wird. Das Startereignis kann eingehende Daten auch umstrukturieren, bevor der Rest der Regel ausgeführt wird: * **Eingaben** knotenspezifische Hilfsvariablen für diesen Schritt erstellen * **Ausgaben** benannte Werte in die Prozessvariablen schreiben, auf die nachgelagerte Knoten zugreifen können ### Beispiel Eine Compliance-Regel für Kühlraumlagerung in einem Pharma-Lager bindet das Startereignis an eine Temperatursonde innerhalb der Lagereinheit. Zeitplan bleibt ausgeschaltet, da die Sonde rund um die Uhr überwacht werden sollte; wäre es eine Regel, die nur außerhalb der Geschäftszeiten ausgeführt werden soll, **Zeitplan ändern** würde dies diese Tage und Zeiten an die lokale Zeitzone der Einrichtung binden. Es werden keine Eingaben benötigt — der rohe Temperaturwert reicht aus, damit das nachgelagerte Gateway auswerten kann. *** ## Endereignis Das Endereignis beendet einen Flussweg. Wenn die Ausführung ein Endereignis erreicht, ist dieser Zweig der Regel abgeschlossen. ### Visuelle Darstellung Ein Kreis mit einem dicken (starken) Rand. ### Wann verwenden Jeder Zweig Ihrer Regel muss mit einem Endereignis enden. Eine Regel mit mehreren Zweigen (z. B. nach einem Exklusiven Gateway) benötigt mehrere Endereignisse — eines pro Zweig. ### Eigenschaftenfeld | Feld | Beschreibung | | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Ein Textfeld für die Knotenbeschriftung. Bleibt normalerweise bei „Ende“ oder wird so benannt, dass das Ergebnis dieses Zweigs beschrieben wird (z. B. „Normal — keine Aktion“, „Alarm ausgelöst“). | Es ist keine weitere Konfiguration erforderlich. ### Beispiel Eine Regel, die prüft, ob ein Temperaturmesswert über oder unter einem Grenzwert liegt, hat zwei Zweige, die aus einem Exklusiven Gateway herausführen. Jeder Zweig endet mit seinem eigenen Endereignis — eines mit der Beschriftung „Im Bereich“, das andere folgt einem Knoten „Alarm setzen“. *** ## Skriptaufgabe Die Skriptaufgabe wertet einen [CEL](https://cel.dev) Ausdruck aus. Verwenden Sie sie, um eingehende Daten umzuwandeln, abgeleitete Werte zu berechnen, Messwerte zu klassifizieren oder Variablen für Entscheidungen weiter unten vorzubereiten. ### Visuelle Darstellung Ein abgerundetes Rechteck mit einem Skript-Icon (Dokument mit Linien) in der oberen linken Ecke. ### Wann verwenden * Einen rohen Sensorwert in eine Schweregradklassifizierung umwandeln * Eine Differenz zwischen zwei Werten berechnen (nach der Anreicherung) * Eine formatierte Zeichenkette für eine Alarmnachricht vorbereiten * Ein Flag setzen, das nachgelagerte Gateways auswerten ### Eigenschaftenfeld | Feld | Beschreibung | | ---------- | ---------------------------------------------------------------------------------------------------- | | **Name** | Ein Textfeld für die Knotenbeschriftung. Standard: „Skript“. Beispiel: „Schweregrad klassifizieren“. | | **Skript** | Ein mehrzeiliges CEL-Ausdrucksfeld (6 Zeilen). Hier schreiben Sie den auszuwertenden Ausdruck. | **Eingaben** — Eine Liste von Eingabeparametern, die vor dem Ausführen des Skripts ausgewertet werden. Jeder Eintrag hat einen Namen, eine Typkennzeichnung (gesperrt auf „Ausdruck“) und ein CEL-Ausdrucksfeld. Verwenden Sie diese, um lokale Hilfsvariablen für die Aufgabe zu erstellen. Fügen Sie Einträge mit **+ Eingabe hinzufügen**. Entfernen Sie sie mit der Löschen-Schaltfläche. **Ausgaben** — Gleiche Struktur wie Eingaben, mit einem eigenen **+ Ausgabe hinzufügen** Button. Verwenden Sie diese, um benannte Werte für nachgelagerte Knoten zu veröffentlichen. **Speichern / Abbrechen** — Am unteren Rand des Feldes. ### Wie Ergebnisse gespeichert werden Das klarste Muster ist, die Skriptaufgabe einen **Map** (eine Schlüssel-Wert-Struktur) zurückgeben zu lassen. Jeder Schlüssel wird einzeln in die Prozessvariablen übernommen. Wenn der Ausdruck der Skriptaufgabe beispielsweise lautet: ```cel {"level": vars.value > 80 ? "critical" : "normal", "needs_action": vars.value > 80} ``` Dann können nachgelagerte Knoten `vars.level` (eine Zeichenkette) und `vars.needs_action` (ein Boolescher Wert) unabhängig voneinander referenzieren. Sie können außerdem den **Ausgaben** Abschnitt der Aufgabe verwenden, um nach dem Ausführen des Skripts zusätzliche benannte Werte zu veröffentlichen. In der Praxis sind Maps und explizite Ausgaben das einfachste Muster zum Prüfen, Wiederherstellen und späteren Beheben von Problemen. ### Beispiel Ein Betriebsteam, das Vibrationssensoren überwacht, klassifiziert Messwerte, bevor es sie durch ein Gateway leitet: ```cel {"severity": vars.value > 90 ? "critical" : vars.value > 70 ? "warning" : "normal"} ``` Das nachgelagerte Exklusive Gateway prüft dann `vars.severity == "critical"` auf einem Zweig und `vars.severity == "warning"` auf einem anderen, mit einem Standardzweig für „normale“ Messwerte, der zu einem Endereignis führt. *** ## Exklusives Gateway Das Exklusive Gateway ist ein Entscheidungspunkt. Es wertet Bedingungen auf seinen ausgehenden Flows aus und leitet die Ausführung zu genau **einem** Zweig — dem ersten, dessen Bedingung wahr ist. Das ist XOR-Routing: Es wird genau ein Pfad genommen. ### Visuelle Darstellung Eine rautenförmige Gestalt. ### Wann verwenden * Zu unterschiedlichen Aktionen je nach Grenzwert routen (oberhalb vs. unterhalb) * Nach einer Schweregradklassifizierung verzweigen (kritisch, Warnung, normal) * Prüfen, ob angereicherte Daten die Entscheidung ändern * Einen Standard-Fallback-Pfad bereitstellen, wenn keine spezifische Bedingung zutrifft ### Eigenschaftenfeld Klicken Sie auf das Exklusive Gateway auf der Zeichenfläche, um sein Eigenschaftenfeld zu öffnen. Oben steht ein Hinweis: *„Bedingungen werden sequentiell ausgewertet (von oben nach unten). Die zuerst erfüllte Bedingung führt ihren Flow aus, und alle verbleibenden Bedingungen werden übersprungen.“* **Name** — Ein Textfeld für die Knotenbeschriftung. Platzhalter: *z. B. MSG Smoke*. **Flows** — Eine Liste aller ausgehenden Verbindungen von diesem Gateway. Jedes Flow-Element zeigt: | Element | Beschreibung | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Ziehgriff** | Flows durch Ziehen neu anordnen. Die Reihenfolge bestimmt die Auswertungspriorität — die zuerst passende Bedingung gewinnt. | | **Flow-Nummer** | „Flow 1“, „Flow 2“ usw. Wenn dieser Flow der Standard ist, erscheint die Kennzeichnung „Standard-Flow“. | | **Systemname** | Ein Textfeld für die interne Flow-Kennung. | | **Beschriftung** | Ein Textfeld für die Beschriftung des Pfeils auf der Zeichenfläche. Beim Standard-Flow ausgeblendet. | | **Farbe** | Ein Farbwähler, um Zweige auf der Zeichenfläche visuell zu unterscheiden. Beim Standard-Flow ausgeblendet. | | **Bedingung (Ausdruck)** | Ein CEL-Ausdruck, der zu `wahr` ausgewertet werden muss, damit dieser Pfad ausgeführt wird. Platzhalter: *z. B. vars.value > 10*. Beim Standard-Flow ausgeblendet. | | **Als Standard festlegen** | Ein Button, der diesen Flow als Fallback-Pfad festlegt. Tooltip: *„Wählen Sie eine der Bedingungen aus, die als Fallback-Pfad dienen soll, wenn alle anderen Bedingungen False sind.“* | | **Löschen** | Entfernt den Flow. Ein Bestätigungsdialog warnt: *„Dadurch wird auch die entsprechende Verbindung auf der Zeichenfläche entfernt.“* | Wenn Sie ändern, welcher Flow der Standard ist, erscheint eine Warnung: *„Wenn der Standard-Flow geändert wird, wird das Feld „Bedingung“ dauerhaft aus dem als Standard festgelegten Flow gelöscht.“* Der zuvor standardmäßige Flow erhält sein Feld „Bedingung“ zurück. Wenn das Gateway noch keine ausgehenden Verbindungen hat, zeigt der Abschnitt Flows einen Leerzustand: *Zeichnen Sie Verbindungen von diesem Gateway auf der Zeichenfläche, um Flows hinzuzufügen.* Sie müssen zuerst Verbindungen auf der Zeichenfläche zeichnen — Flows können nicht allein über das Eigenschaftenfeld hinzugefügt werden. **Eingaben** — Optional. Gleiche Struktur wie der Abschnitt Eingaben des Startereignisses (Name, Typ, CEL-Ausdruck, + Eingabe hinzufügen). **Ausgaben** — Optional. Gleiche Struktur wie der Abschnitt Ausgaben des Startereignisses (Name, Typ, CEL-Ausdruck, + Ausgabe hinzufügen). **Speichern / Abbrechen** — Am unteren Rand des Feldes. ### Brauche ich die Eingabe- und Ausgabeparameter? Nein. Beide sind optional, und ein Gateway, das lediglich prüft, ob ein Wert über einem Grenzwert liegt, benötigt keines von beiden — lassen Sie sie leer und schreiben Sie `vars.value > 70` direkt in die Flow-Bedingung. Verwenden Sie sie, wenn eine Bedingung sonst lang wäre oder wenn Sie dieselbe Berechnung über mehrere Flows hinweg wiederholen. **Eine Eingabe** berechnet einen Wert, bevor das Gateway entscheidet, und gibt ihm einen kurzen Namen, den die eigenen Flow-Bedingungen des Gateways verwenden können. Um einen Celsius-Wert einmal in Fahrenheit umzuwandeln und zweimal zu vergleichen, fügen Sie eine Eingabe hinzu: | Feld | Wert | | ----------- | ----------------------------- | | Eingabename | `tempF` | | Ausdruck | `vars.temperature * 1.8 + 32` | Dann schreiben Sie die Flow-Bedingungen als `vars.tempF > 158` und `vars.tempF > 104` anstatt die Umrechnung in jeder zu wiederholen. Eine Eingabe gehört zu dem Gateway, auf dem Sie sie definiert haben. Spätere Knoten können sie nicht lesen. **Eine Ausgabe** funktioniert umgekehrt. Sie wird ausgewertet, nachdem der Zweig ausgewählt wurde, und schreibt ihr Ergebnis in die Variablen der Regel, sodass spätere Knoten sie verwenden können — eine Alarmnachricht kann sich auf `vars.tempF` beziehen, obwohl die Umrechnung am Gateway erfolgt ist. Dasselbe gilt überall dort, wo Eingaben und Ausgaben vorkommen: Eine Eingabe ist ein Hilfsmittel für den Knoten, den Sie konfigurieren, eine Ausgabe ist die Art und Weise, wie dieser Knoten etwas weitergibt. ### Wie die Auswertung von Bedingungen funktioniert Bedingungen werden **von oben nach unten** in der Reihenfolge der Flows-Liste ausgewertet. Die erste Bedingung, die `wahr` zurückgibt, ist der gewählte Pfad. Alle verbleibenden Bedingungen werden übersprungen, unabhängig davon, ob sie ebenfalls wahr wären. Der Standard-Flow hat keinen Bedingungsausdruck. Er wird nur ausgeführt, wenn **jede andere Bedingung false ergibt**. Jedes Exklusive Gateway sollte einen Standard-Flow haben — ohne einen solchen bleibt die Regelausführung auf diesem Zweig stehen, wenn keine Bedingung zutrifft. Der Standard-Flow deckt den Fall ab, dass nichts zutraf. Er deckt nicht eine Bedingung ab, die nicht ausgewertet werden kann: Wenn ein Ausdruck nicht ausgewertet werden kann — meist, weil er auf eine Variable verweist, die die Regel nicht hat, oder etwas anderes als `wahr`/`false` zurückgibt — stoppt das Gateway dort und die Regel läuft auf diesem Pfad nicht weiter. In einer Debug-Sitzung wird das Gateway rot umrandet; siehe [Regeln debuggen](/kilo-docs-de/kilo-iot-server/rules-engine/debugging-rules.md#what-the-markers-on-the-canvas-mean). Ein Gateway muss außerdem verzweigen oder zusammenführen: Geben Sie ihm zwei oder mehr ausgehende Flows, um eine Entscheidung zu treffen, oder zwei oder mehr eingehende Flows, um Pfade wieder zusammenzuführen. Ein Gateway mit einem eingehenden und einem ausgehenden Flow wird beim Erstellen der Regel abgelehnt — verbinden Sie stattdessen diese beiden Knoten direkt. ### Beispiel Eine Regel zur Luftfeuchtigkeit im Lager verwendet ein Exklusives Gateway mit drei Flows: | Flow | Bedingung | Führt zu | | ----------------- | ----------------- | -------------------------------------------------- | | Flow 1 — Kritisch | `vars.value > 85` | Alarm setzen (kritischer Luftfeuchtigkeitsverstoß) | | Flow 2 — Warnung | `vars.value > 70` | Alarm setzen (Luftfeuchtigkeitswarnung) | | Flow 3 — Standard | *(keine)* | Endereignis (keine Aktion) | Da Bedingungen von oben nach unten ausgewertet werden, trifft ein Messwert von 90 % auf Flow 1 zu und überspringt Flow 2. Ein Messwert von 75 % verfehlt Flow 1 und trifft Flow 2. Ein Messwert von 60 % verfehlt beide und fällt auf den Standard durch. *** ## Alarm setzen Der Knoten „Alarm setzen“ löst einen Alarm basierend auf einer vorkonfigurierten Alarmdefinition aus. Wenn die Ausführung diesen Knoten erreicht, erstellt er ein Alarmereignis, das die Eskalationsrichtlinie startet, Benachrichtigungen über konfigurierte Kanäle sendet und im Alarm-Posteingang erscheint.
The Set Alarm properties panel with the alarm selector, the CEL motivation message, and the Inputs and Outputs sections
### Visuelle Darstellung Ein abgerundetes Rechteck mit einem Glocken-Icon in der oberen linken Ecke. ### Wann verwenden * Einen kritischen Alarm auslösen, wenn ein Sensorwert einen gefährlichen Grenzwert überschreitet * Einen Warnalarm auslösen, der das Betriebsteam per E-Mail und SMS benachrichtigt * Alarme mit dynamischen Nachrichten erzeugen, die die tatsächlichen Sensorwerte enthalten ### Voraussetzungen Bevor Sie einen Knoten „Alarm setzen“ verwenden können, benötigen Sie mindestens eine **Alarmdefinition** im Abschnitt „Alerts“ konfiguriert. Alarmdefinitionen legen den Schweregrad, Eskalationsschritte, Benachrichtigungskanäle und Empfängerregeln fest. Der Knoten „Alarm setzen“ verweist auf eine vorhandene Definition — er erstellt keine. Siehe [Operatives Alarmieren](/kilo-docs-de/kilo-iot-server/alarm.md) zum Erstellen und Verwalten von Alarmdefinitionen. ### Eigenschaftenfeld Die Kopfzeile des Feldes lautet **„Alarm setzen“** mit dem Untertext: *„Wählen Sie einen Alarm aus. Ein neuer Alarm kann auf der Alarme-Seite erstellt werden.“* Das Wort „Alarme-Seite“ verlinkt zum [Abschnitt „Alerts und Benachrichtigungen“](/kilo-docs-de/kilo-iot-server/alarm.md) . | Feld | Beschreibung | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | Ein Textfeld für die Knotenbeschriftung. Beispiel: „Kritischen Alarm auslösen“. | | **Alarm auswählen** | Ein durchsuchbares Autovervollständigungs-Dropdown. Listet vorhandene Alarmdefinitionen in Ihrer Organisation auf. Suchen Sie nach Alarmnamen, um die benötigte Definition zu finden. | | **Motivationsnachricht** | Ein mehrzeiliges CEL-Ausdrucksfeld (3 Zeilen). Platzhalter: `„Temperatur ist " + string(vars.temp) + " Grad"`. Der Ausdruck muss zu einer Zeichenkette ausgewertet werden — dieser Text wird dem Alarmereignis angehängt und gibt den Bearbeitern Kontext dazu, was den Alarm ausgelöst hat und warum. | **Eingaben** — Eine Liste von Eingabeparametern. Jeder Eintrag hat einen Namen, eine Typkennzeichnung (gesperrt auf „Ausdruck“) und ein CEL-Ausdrucksfeld. Fügen Sie Einträge mit **+ Eingabe hinzufügen**. Entfernen Sie sie mit der Löschen-Schaltfläche. **Ausgaben** — Gleiche Struktur wie Eingaben, mit einem eigenen **+ Ausgabe hinzufügen** Button hinzu. **Speichern / Abbrechen** — Am unteren Rand des Feldes. ### Beispiele für Motivationsnachrichten Die Motivationsnachricht ist ein CEL-Ausdruck, sodass Sie Live-Sensorwerte und berechnete Variablen einbetten können: ```cel "Temperatur " + string(vars.value) + " Grad überschreitet den Sicherheitsgrenzwert" ``` ```cel "Feuchtigkeitsmesswert von " + string(vars.value) + "% in Zone A — über " + string(vars.severity) + " Stufe" ``` ```cel "CO2-Konzentration bei " + string(vars.value) + " ppm, und damit um " + string(vars.value - 800) + " ppm über dem Grenzwert" ``` ### Was passiert, wenn der Knoten ausgeführt wird 1. Es wird ein Alarmereignis mit dem Schweregrad und der Konfiguration der ausgewählten Alarmdefinition erstellt 2. Der Ausdruck der Motivationsnachricht wird ausgewertet und dem Ereignis angehängt 3. Die Eskalationsrichtlinie des Alarms beginnt — Benachrichtigungen werden über die in der Alarmdefinition definierten Kanäle und an die dort festgelegten Empfänger gesendet 4. Das Alarmereignis erscheint im Alarm-Posteingang zur Nachverfolgung und Behebung Der Knoten „Alarm setzen“ **nicht** legt Schweregrad, Kanäle, Zeitpläne oder Eskalation selbst fest. Diese stammen aus der ausgewählten Alarmdefinition. Die Regel entscheidet **wann** auszulösen ist; die Alarmdefinition entscheidet **wie** dieser Alarm behandelt wird. ### Beispiel Eine Umgebungsüberwachungsregel für den Serverraum erreicht den Knoten „Alarm setzen“, wenn die Temperatur 35 Grad Celsius überschreitet. Der Knoten ist mit einer Alarmdefinition namens „Überhitzung Serverraum“ konfiguriert (Schweregrad: Kritisch, Eskalation: sofortige SMS an den Bereitschaftsingenieur, E-Mail an den Facility Manager nach 5 Minuten). Die Motivationsnachricht lautet: ```cel "Serverraumtemperatur ist " + string(vars.value) + " Grad — sofortige Aufmerksamkeit erforderlich" ``` *** ## Befehl ausführen Der Knoten „Befehl ausführen“ sendet einen Befehl an ein Gerät, wenn die Regel ihn erreicht — die Aktion, mit der eine Regel Hardware steuern kann, nicht nur darüber benachrichtigen. Er sendet einen der vordefinierten Befehle eines Geräts [Gerätebefehle](/kilo-docs-de/kilo-iot-server/devices/commands.md) als Downlink, sodass eine Regel ein Ventil schließen, einen Sollwert vorgeben oder ein Relais automatisch in dem Moment schalten kann, in dem ihre Bedingungen erfüllt sind. Den vollständigen Ablauf, Beispiele und das Muster „handeln und alarmieren“ finden Sie unter [Ausführen von Gerätebefehlen](/kilo-docs-de/kilo-iot-server/rules-engine/running-device-commands.md). Dieser Eintrag beschreibt die Felder des Knotens. ### Visuelle Darstellung Ein abgerundetes Rechteck mit einem Befehls-Icon in der oberen linken Ecke. Es befindet sich in derselben Aktivitätsgruppe wie Alarm setzen und Anreicherung. ### Wann verwenden * Ein Ventil schließen, ein Relais schalten oder eine Pumpe stoppen, sobald ein Grenzwert überschritten wird * Einen neuen Sollwert als Reaktion auf einen Messwert an einen Regler senden * Einen Wert proportional einstellen — z. B. Lüfterdrehzahl, abgeleitet aus der gemessenen Temperatur ### Voraussetzungen Das Zielgerät muss **steuerbar** (MQTT oder ein LoRaWAN-Gerät der Klasse C) sein und bereits **mindestens einen definierten Befehl** in seiner **Befehle & Zustände** Registerkarte haben. Der Knoten führt vorhandene Befehle aus; er erstellt keine. Siehe [Befehle erstellen](/kilo-docs-de/kilo-iot-server/devices/commands/creating-commands.md). ### Eigenschaftenfeld | Feld | Beschreibung | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Ein Textfeld für die Knotenbeschriftung. Wenn es leer gelassen wird, füllt es sich mit dem Namen des ausgewählten Befehls. Beispiel: „Einlassventil schließen“. | | **Gerät** | Eine durchsuchbare Autovervollständigungs-Dropdown-Liste, die die Geräte in Ihrer Organisation auflistet. Wählt das Gerät aus, an das der Befehl gesendet wird. | | **Befehl** | Eine Autovervollständigungs-Dropdown-Liste mit den definierten Befehlen des ausgewählten Geräts. Deaktiviert, bis ein Gerät ausgewählt ist. | | **Parameter** | Eine Zeile pro Parameter, den der ausgewählte Befehl erwartet. Jeder Parameter wird als Literal angegeben **Wert** (wird gegen Typ und Bereich des Parameters validiert) oder als **CEL-Ausdruck** (zur Laufzeit ausgewertet, wobei `vars` verfügbar ist). | | **Eingaben / Ausgaben** | Optionale benannte CEL-Ausdrücke für fortgeschrittene Datenaufbereitung, nach demselben Muster wie bei anderen Knoten. | **Speichern / Abbrechen** — Unten im Bedienfeld. Speichern ist deaktiviert, bis sowohl ein Gerät als auch ein Befehl ausgewählt sind und jeder Parameter gültig ist. ### Was passiert, wenn der Knoten ausgeführt wird 1. Jeder Parameter wird aufgelöst — Literale unverändert, Ausdrücke werden gegen das aktuelle `vars`. 2. Der Befehl wird als Downlink (MQTT oder LoRaWAN) an das Gerät gesendet, genau wie bei einer manuellen Ausführung. 3. Das Senden wird in der Ausführungs-Historie des Geräts mit seinem Ergebnis aufgezeichnet (Ausstehend, Bestätigt, Zugestellt, Soft-Warnung oder Fehlgeschlagen). Jede für den Befehl konfigurierte Verifizierung gilt hier ebenfalls. Koppeln Sie einen Execute-Command-Knoten mit einem [Grenzfehlerereignis](#boundary-error-event) wenn ein fehlgeschlagenes Senden dennoch einen Menschen über einen Fallback-Pfad erreichen soll. ### Beispiel Eine Regel zur Leckerkennung bindet ihr Start-Ereignis an einen Lecksensor. Ein Exklusives Gateway leitet einen "Leck erkannt"-Messwert zu einem Execute-Command-Knoten, der einen `schließen` Befehl an das Wasserabsperrventil sendet, gefolgt von einem Alarm festlegen-Knoten, der einen Kritischen Alarm auslöst. Das Wasser wird automatisch gestoppt, und das Team wird darüber benachrichtigt. *** ## Anreicherung Der Anreicherungs-Knoten ruft den neuesten Messwert von einem anderen Sensor ab. Dadurch können Sie Entscheidungen auf Basis von Daten aus mehreren Sensoren innerhalb einer einzigen Regel treffen, ohne für jeden einzelnen separate Regeln erstellen zu müssen. ### Visuelle Darstellung Ein abgerundetes Rechteck mit einem Download-Symbol in der oberen linken Ecke. ### Wann verwenden * Eine Innenraum-Temperaturmessung mit der aktuellen Außentemperatur vergleichen * Einen Feuchtigkeitssensor prüfen, bevor entschieden wird, ob ein Temperatursprung besorgniserregend ist * Eine CO2-Messung mit einem Belegungssensor korrelieren, um festzustellen, ob erhöhte Werte zu erwarten sind * Einen Referenzsensor verifizieren, bevor ein Alarm ausgelöst wird ### Eigenschaftenfeld Die Kopfzeile des Feldes lautet **"Datenanreicherung"** mit dem Untertext: *"Relevante Metadaten an die eingehenden Gerätedaten anhängen, bevor sie verarbeitet werden."* | Feld | Beschreibung | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Ein Textfeld für die Knotenbeschriftung. Platzhalter: *z. B. Raumtemperatur zu Sensordaten hinzufügen*. | | **Gerät** | Durchsuchbare Autovervollständigungs-Dropdown-Liste. Listet alle Geräte in Ihrer Organisation auf — dasselbe Auswahlmuster wie beim Start-Ereignis. | | **Sensor** | Gefilterte Dropdown-Liste. Deaktiviert, bis ein Gerät ausgewählt ist. Zeigt nur Sensoren an, die zum gewählten Gerät gehören. | | **Ausgabevariable** | Ein Textfeld für den Variablennamen, unter dem die abgerufenen Daten gespeichert werden. Platzhalter: *Benutzermetadaten*. Nach der Ausführung des Knotens ist das Ergebnis verfügbar als `vars.`. | **Eingaben** — Eine Liste von Eingabeparametern. Jeder Eintrag hat einen Namen, eine Typkennzeichnung (gesperrt auf „Ausdruck“) und ein CEL-Ausdrucksfeld. Fügen Sie Einträge mit **+ Eingabe hinzufügen**. Entfernen Sie sie mit der Löschen-Schaltfläche. **Ausgaben** — Gleiche Struktur wie Eingaben, mit einem eigenen **+ Ausgabe hinzufügen** Button hinzu. **Speichern / Abbrechen** — Am unteren Rand des Feldes. ### Wie angereicherte Daten strukturiert sind Nachdem der Anreicherungs-Knoten ausgeführt wurde, ist der abgerufene Messwert verfügbar als `vars.` mit der folgenden Struktur: | Eigenschaft | Inhalt | | ----------------------------------- | ------------------------------------------ | | `vars..sensor_id` | Die Kennung des Sensors | | `vars..value` | Der aktuellste Messwert | | `vars..type` | Der Datentyp des Sensors | | `vars..timestamp_ms` | Zeitstempel des Messwerts in Millisekunden | Wenn der Variablenname zum Beispiel `outdoor_temp` lautet, können nachgelagerte Knoten auf `vars.outdoor_temp.value` verweisen, um den neuesten Außentemperatur-Messwert zu erhalten. ### Fehlerbehandlung Der Anreicherungs-Knoten kann fehlschlagen, wenn der Zielsensor offline ist, nie Daten gesendet hat oder nicht zugänglich ist. Koppeln Sie einen Anreicherungs-Knoten immer mit einem **Grenzfehlerereignis** (siehe unten), um diese Fehler elegant zu behandeln. Ohne Fehlerbehandlung stoppt eine fehlgeschlagene Anreicherung diesen Ausführungspfad. ### Beispiel Eine Regel zur Rechenzentrumsüberwachung vergleicht die Umgebungstemperatur im Inneren eines Serverraums mit dem externen Temperatursensor des Gebäudes. Der Anreicherungs-Knoten ruft vom externen Sensor in eine Variable namens `external_temp`. Ein nachgelagerter Script-Task berechnet die Differenz: ```cel {"temp_delta": vars.value - vars.external_temp.value} ``` Ein Exklusives Gateway prüft dann, ob `vars.temp_delta > 15` — ein großer Unterschied könnte auf einen Ausfall der HVAC-Anlage hinweisen, da die Innentemperatur unabhängig von den Außenbedingungen steigt. *** ## Grenzfehlerereignis Das Boundary-Error-Event ist ein Fehlerbehandler, der an einen Task-Knoten angehängt wird. Wenn der Task, an den es angehängt ist, während der Ausführung fehlschlägt, fängt das Boundary-Error-Event den Fehler ab und leitet die Ausführung an einen Fallback-Pfad weiter, anstatt die Regel zu beenden. ### Visuelle Darstellung Ein kleiner Kreis mit einem Blitzsymbol, der am Rand des Task-Knotens positioniert ist, an den er angehängt ist. Er sitzt am Rand des Elternknotens und nicht als eigenständiges Element auf der Arbeitsfläche. ### Wann verwenden * Ein Anreicherungs-Knoten ruft von einem Sensor ab, der offline sein könnte * Ein Script-Task wertet einen Ausdruck aus, der von optionalen Daten abhängt * Ein Alarm-festlegen-Knoten verweist auf eine Alarmdefinition, die möglicherweise deaktiviert wurde * Jeder beliebige Task, bei dem ein Fehler eine bestimmte Reaktion statt Schweigen auslösen soll ### So hängen Sie ihn an Ziehen Sie ein Boundary-Error-Event aus der Palette und legen Sie es auf einen vorhandenen Task-Knoten (Script-Task, Alarm festlegen oder Anreicherung). Es schnappt an den Rand dieses Knotens. Zeichnen Sie dann genau eine ausgehende Verbindung vom Boundary-Error-Event zum Fallback-Pfad — typischerweise ein weiterer Alarm-festlegen-Knoten, ein Script-Task, der den Fehlerkontext protokolliert, oder ein End-Ereignis. ### Regeln * Ein Boundary-Error-Event muss an einen Task-Knoten angehängt sein. Es kann nicht als eigenständiger Knoten auf der Arbeitsfläche existieren. * Es muss genau **einem** ausgehenden Fluss haben. * Es darf keine eingehenden Flüsse haben (außer seiner impliziten Anheftung an den Eltern-Task). ### Eigenschaftenfeld | Feld | Beschreibung | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | Ein Textfeld für die Knotenbeschriftung. Standard: "Fehler". Beispiel: "Fallback bei Sensor offline". | | **Fehlercode** | Ein Textfeld. Platzhalter: *Fehlercode hier angeben*. Dient im Editor zur Beschriftung und Annotation — siehe den Hinweis unten. | | **Nachricht** | Ein mehrzeiliges Textfeld (3 Zeilen). Platzhalter: *Fehlermeldung hier eingeben*. Dient im Editor zur Beschriftung und Annotation — siehe den Hinweis unten. | **Eingaben / Ausgaben** — Das Eigenschaftenfeld kann bei dem Boundary-Error-Event die Felder Eingabe und Ausgabe anzeigen. Die Automatisierungs-Engine verarbeitet jedoch auf diesem Knotentyp keine Eingaben oder Ausgaben. Wenn Sie Daten transformieren oder Werte auf dem Fehlerpfad veröffentlichen müssen, fügen Sie Eingaben und Ausgaben zum **nachgelagerten Knoten** hinzu, mit dem der ausgehende Fluss des Boundary-Events verbunden ist — zum Beispiel dem Fallback-Script-Task, dem Alarm festlegen-Knoten oder dem End-Ereignis. **Speichern / Abbrechen** — Am unteren Rand des Feldes. **Wichtiger Hinweis:** Die Felder Fehlercode und Nachricht dienen im Editor der Beschriftung und Annotation. Sie ermöglichen kein selektives Laufzeit-Matching nach Fehlercode. Die Engine leitet **alle** Fehler des angehängten Tasks unabhängig vom eingegebenen Code über das Boundary-Event weiter. Das zentral unterstützte Verhalten ist der Fallback-Pfad selbst: Wenn der angehängte Task aus irgendeinem Grund fehlschlägt, läuft der Fehlerpfad anstatt dieser Zweig still zu enden. ### Beispiel Eine Regel zur Multi-Sensor-Konformität reichert Innenraum-Messwerte mit einem externen Referenzsensor an. Der Anreicherungs-Knoten für den externen Sensor hat ein Boundary-Error-Event angehängt. Wenn der externe Sensor nicht erreichbar ist: 1. Das Boundary-Error-Event fängt den Fehler ab 2. Sein ausgehender Fluss führt zu einem Alarm-festlegen-Knoten, der mit einer Alarmdefinition „Sensor offline“ konfiguriert ist 3. Das Betriebsteam erhält eine Benachrichtigung, dass der externe Referenzsensor keine Daten liefert, sodass es weiß, dass der Konformitätsvergleich nicht durchgeführt werden konnte Ohne das Boundary-Error-Event würde der Fehler bei der Anreicherung diesen Ausführungspfad stillschweigend stoppen — und das Team würde nicht wissen, dass der Sensor offline war. *** ## Verbindungen (Sequenzflüsse) Verbindungen sind die Pfeile zwischen Knoten auf der Arbeitsfläche. Sie definieren die Ausführungsreihenfolge — Daten fließen entlang dieser Pfeile von einem Knoten zum nächsten. ### Verbindungen zeichnen Verwenden Sie das **Globale Verbindungswerkzeug** aus der Palette oder fahren Sie mit der Maus über einen Quellknoten, bis Verbindungsgriffe erscheinen, und ziehen Sie dann vom Quell- zum Zielknoten. ### Verbindungsregeln | Regel | Details | | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- | | **Start-Ereignisse** | Ein ausgehender Fluss. Keine eingehenden Flüsse. | | **End-Ereignisse** | Keine ausgehenden Flüsse. Ein oder mehrere eingehende Flüsse. | | **Task-Knoten** (Script-Task, Alarm festlegen, Befehl ausführen, Anreicherung) | Ein ausgehender Fluss. Ein eingehender Fluss (oder Anhang eines Boundary-Error-Events). | | **Exklusive Gateways** | Ein eingehender Fluss. Mehrere ausgehende Flüsse (einer pro Zweig). | | **Boundary-Error-Events** | Genau ein ausgehender Fluss. Keine eingehenden Flüsse (implizit an den Elternknoten angehängt). | ### Bedingungen für Gateway-Flüsse Jeder ausgehende Fluss eines Exklusiven Gateways — außer dem als Standard definierten Fluss — muss einen CEL-Bedingungsausdruck haben. Diese Bedingungen müssen zu einem booleschen Wert auswerten (`wahr` oder `false`). Der Standardfluss muss **nicht** eine Bedingung haben. Er wird nur ausgeführt, wenn alle anderen Bedingungen zu falsch auswerten. Wenn Sie einen Fluss von einem Gateway erstellen, ohne eine Bedingung festzulegen, wird der Build-Schritt dies als Fehler markieren und die Regel wird nicht erfolgreich erstellt. ### Flussbeschriftungen und -farben Flüsse von Exklusiven Gateways können Beschriftungen und Farben haben (konfiguriert im Eigenschaftenfeld des Gateways). Verwenden Sie diese, um komplexe Diagramme auf einen Blick lesbar zu machen — zum Beispiel einen Zweig mit „Kritisch“ in Rot und einen anderen mit „Warnung“ in Bernstein, wobei der Standardzweig „Normal“ in Grün dargestellt wird. --- # 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/node-reference.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.