> 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/running-device-commands.md). # Ausführen von Gerätebefehlen Lassen Sie eine Kilo-Regel eigenständig handeln — der Knoten „Befehl ausführen“ sendet einen Gerätebefehl, wenn die Bedingungen erfüllt sind. Dies ist die Änderung, die die Rules Engine von einem System, das *beobachtet* zu einem System macht, das *handelt*. Bis jetzt war das Maximum, das es tun konnte, wenn eine Regel ein Problem erkannte, Alarm zu schlagen und einen Menschen in die Schleife zu holen — jemand musste die Warnung lesen und den Schalter umlegen. Der **Befehl ausführen** -Knoten schließt diese Lücke. Eine Regel kann nun einen Befehl direkt an ein Gerät senden, sobald seine Bedingungen erfüllt sind, ohne dass eine Person dazwischensteht. Stellen Sie sich vor, was das in der Praxis bedeutet. Ein Lecksensor löst in einem Technikraum aus. Früher löste die Regel einen Alarm aus und ein Bediener eilte herbei, um das Hauptventil zu schließen — so oder so Minuten von Wasserschäden. Jetzt schließt dieselbe Regel das Ventil selbst in derselben Auswertung, die das Leck erkannt hat, und *dann* löst den Alarm aus, damit das Team weiß, dass es passiert ist. Die Kaltlagerung gerät aus dem Bereich, und die Regel setzt einen niedrigeren Sollwert an den Regler, bevor das Produkt gefährdet ist. Ein Tank erreicht die Hochfüllmarke, und die Regel schließt den Zulauf. Das ist Closed-Loop-Automatisierung: erfassen, entscheiden und handeln, durchgängig, in einer einzigen Regel. Die Aktion läuft auf derselben [Gerätebefehls-Engine](/kilo-docs-de/kilo-iot-server/devices/commands.md) wie Sie sie manuell verwenden — die Regel sendet einfach einen Befehl, den Sie bereits auf dem Gerät definiert haben. Daher gilt alles, was manuelle Befehle sicher macht (typisierte Parameter, optionale Verifizierung, ein vollständiger Ausführungsnachweis), automatisch auch, wenn eine Regel einen auslöst. ## Bevor Sie beginnen Der „Befehl ausführen“-Knoten sendet einen der **vorhandenen** Befehle. Er definiert keine neuen. Bevor eine Regel also auf ein Gerät reagieren kann: 1. **Das Gerät muss steuerbar sein** — per MQTT verbunden oder ein LoRaWAN-Gerät der Klasse C (Geräte der Klasse C lauschen kontinuierlich und können daher jederzeit einen Downlink empfangen). 2. **Das Gerät muss mindestens einen definierten Befehl haben** — richten Sie das zuerst auf der **Registerkarte „Befehle & Zustände“** des Geräts ein. Siehe [Befehle erstellen](/kilo-docs-de/kilo-iot-server/devices/commands/creating-commands.md). 3. **Sie haben die Berechtigung, die Regel und die Befehle des Geräts zu verwalten** — beides wird durch die Zugriffsrichtlinie Ihrer Organisation geregelt. Wenn ein Gerät noch keine Befehle hat, bietet es nichts an, das ausgeführt werden kann — definieren Sie zuerst den Befehl und kehren Sie dann zur Regel zurück. ## Hinzufügen eines „Befehl ausführen“-Knotens 1. Öffnen Sie die Regel im [Visuellen Editor](/kilo-docs-de/kilo-iot-server/rules-engine/visual-editor.md) und wechseln Sie in den **Bearbeitungs** modus. 2. Ziehen Sie **Befehl ausführen** aus der Palette auf die Leinwand. Er befindet sich in derselben Gruppe wie Alarm setzen und Anreicherung — es ist eine Aktion, die die Regel ausführt, wenn die Ausführung ihn erreicht. 3. Verbinden Sie ihn mit Ihrem Ablauf. Typischerweise folgt er einem Zweig eines Exklusiven Gateways — die Regel wertet eine Bedingung aus, und der Zweig, der „jetzt handeln“ bedeutet, führt in den „Befehl ausführen“-Knoten. 4. Klicken Sie auf den Knoten, um sein Eigenschaftenfenster zu öffnen, und füllen Sie die folgenden Felder aus. 5. Klicken Sie auf **Speichern**, dann **Erstellen** und stellen Sie die Regel wie gewohnt bereit. Der Befehl wird erst ausgelöst, sobald die Regel erstellt und ausgeführt wird. ## Eigenschaftenfenster | Feld | Beschreibung | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** | Eine Beschriftung für den Knoten auf der Leinwand. Wenn Sie sie leer lassen und einen Befehl auswählen, wird automatisch der Name des Befehls eingefügt. Beispiel: „Zulaufventil schließen“. | | **Gerät** | Ein durchsuchbares Dropdown mit den Geräten in Ihrer Organisation. Wählen Sie das Gerät aus, an das der Befehl gesendet werden soll. | | **Befehl** | Ein Dropdown mit den definierten Befehlen dieses Geräts. Deaktiviert, bis ein Gerät ausgewählt ist, danach werden alle auf dem ausgewählten Gerät verfügbaren Befehle aufgelistet. | | **Parameter** | Erscheint, sobald ein Befehl ausgewählt ist, mit einer Zeile pro Parameter, den der Befehl erwartet (ein Helligkeitswert, ein Sollwert, ein Öffnen-/Schließen-Schalter). Jeder Parameter wird entweder als ein literaler **Wert** oder als ein **CEL-Ausdruck** — siehe unten. | | **Eingaben / Ausgaben** | Optional. Benannte CEL-Ausdrücke für fortgeschrittene Datenformung, das gleiche Muster wie bei anderen Knoten. Verwenden Sie Eingaben, um Hilfswerte vorzubereiten, und Ausgaben, um Ergebnisse für nachgelagerte Knoten bereitzustellen. | **Speichern / Abbrechen** befinden sich unten im Fenster. ### Befehlparameter festlegen: Wert oder Ausdruck Jeder vom Befehl definierte Parameter erhält eine eigene Zeile, und für jeden wählen Sie aus, wie der Wert bereitgestellt wird: * **Wert** — ein fester Literalwert, den Sie eingeben. Verwenden Sie dies, wenn die Regel immer denselben Wert senden soll: einen Sollwert von `4`, einen Zustand von `aus`, einen Tastgrad von `100`. Das Feld wird gegen die Parameterdefinition des Befehls validiert, sodass ein Wert außerhalb des Bereichs oder vom falschen Typ gemeldet wird, bevor Sie speichern können. * **Ausdruck** — ein [CEL](/kilo-docs-de/kilo-iot-server/rules-engine/cel-reference.md) Ausdruck, der beim Ausführen der Regel ausgewertet wird. Das macht die Aktion *dynamisch*: Der Live-Kontext der Regel ist über `vars`verfügbar, sodass ein Befehlsparameter aus genau der Messung berechnet werden kann, die die Regel ausgelöst hat. Setzen Sie zum Beispiel eine Lüftergeschwindigkeit anhand der gemessenen Temperatur, oder reichen Sie den Wert des Sensors direkt weiter mit `vars.value`. Die Kombination ist leistungsstark: Ein Exklusives Gateway entscheidet *ob* gehandelt werden soll, und ein CEL-Ausdruck auf dem „Befehl ausführen“-Knoten entscheidet *welcher Wert gesendet werden soll* — so kann eine Regel sowohl auf einen Grenzwert reagieren als auch proportional dazu antworten, wie weit der Messwert darüber liegt. ## Was passiert, wenn der Knoten ausgeführt wird 1. Die Regel erreicht den „Befehl ausführen“-Knoten entlang ihres Ablaufs. 2. Jeder Parameter wird aufgelöst — Literale unverändert, Ausdrücke werden gegen den aktuellen `vars`. 3. Der Befehl wird als Downlink über MQTT oder LoRaWAN an das Gerät gesendet, genau so, als wäre er von Hand über die **Registerkarte „Zustände“** des Geräts ausgeführt worden. 4. Die Übermittlung wird mit ihrem Ergebnis (Ausstehend, Bestätigt, Zugestellt, Weiche Warnung oder Fehlgeschlagen) in der Ausführungshistorie des Geräts aufgezeichnet, sodass es eine vollständige Prüfung aller Aktionen gibt, die eine Regel vorgenommen hat. Da der Befehl über den standardmäßigen Pfad der Gerätebefehle läuft, gilt jede für diesen Befehl konfigurierte Verifizierung auch hier — die Regel kann bestätigen, dass das Gerät tatsächlich gehandelt hat, nicht nur, dass der Downlink gesendet wurde. Siehe [Befehle bestätigen](/kilo-docs-de/kilo-iot-server/devices/commands/verification.md). ## Handeln *und* und Alarmieren in einer Regel Das Handeln an einem Gerät ersetzt das Alarmieren nicht — beides funktioniert zusammen am besten. Eine einzige Regel kann das Ventil schließen **und** und einen Alarm auslösen, sodass die Situation automatisch eingedämmt wird *und* und die richtigen Personen informiert werden. Ein typisches Muster: | Schritt | Knoten | Was er tut | | --------------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------- | | Erkennen | Start Event → Exklusives Gateway | An den Lecksensor binden; bei erkannter Leckage verzweigen | | Handeln | Befehl ausführen | „Ventil schließen“ an das Absperrventil senden | | Benachrichtigen | Alarm setzen | Einen Alarm der Kritikalitätsstufe auslösen, damit das Team weiß, dass das Ventil geschlossen wurde und warum | Wenn die Aktion selbst fehlschlagen könnte — etwa wenn das Gerät kurzzeitig offline ist — hängen Sie ein [Grenzfehler-Ereignis](/kilo-docs-de/kilo-iot-server/rules-engine/node-reference.md#boundary-error-event) an den „Befehl ausführen“-Knoten und leiten Sie den Fehlerpfad zu einem Alarm setzen-Knoten, damit ein Befehl, der nicht durchgeht, dennoch einen Menschen erreicht. ## Ein durchgerechnetes Beispiel Eine Regel für die Kühlkette schützt einen pharmazeutischen Gefrierschrank. Das Start-Ereignis bindet an die Temperatursonde des Gefrierschranks. Ein Exklusives Gateway leitet jeden Messwert über −15 °C in einen „driftet warm“-Zweig. In diesem Zweig: 1. Ein **Befehl ausführen** Knoten sendet einen `set_setpoint` Befehl an den Regler des Gefrierschranks, wobei der Sollwertparameter als ein **Ausdruck** Ausdruck, der den Zielwert abhängig davon absenkt, wie weit der Messwert abgedriftet ist — je größer die Abweichung, desto kältere Korrektur. 2. Ein **Alarm setzen** Knoten löst einen Alarm mit hoher Kritikalität und einer Begründungsnachricht aus, die die aktuelle Temperatur enthält, sodass der zuständige Ingenieur informiert wird, obwohl die Regel bereits damit begonnen hat, das Problem zu korrigieren. Das Produkt ist im Moment der erkannten Abweichung geschützt, und das Team erhält dennoch das vollständige Bild. Das ist der Unterschied zwischen einer Plattform, die Ihnen sagt, dass etwas schiefgelaufen ist, und einer, die etwas dagegen unternimmt. ## Verwandte Seiten * [Gerätebefehls-Engine](/kilo-docs-de/kilo-iot-server/devices/commands.md) — definieren Sie die Befehle, die eine Regel ausführen kann, und führen Sie sie von Hand aus * [Knotenreferenz](/kilo-docs-de/kilo-iot-server/rules-engine/node-reference.md) — jeder Knotentyp, einschließlich Execute Command, im Detail * [CEL-Referenz](/kilo-docs-de/kilo-iot-server/rules-engine/cel-reference.md) — die Ausdruckssprache für dynamische Parameterwerte * [Steuerelement](/kilo-docs-de/kilo-iot-server/dashboards/adding-widgets/control-widget.md) — dieselben Befehle von einem Dashboard aus bedienen --- # 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/running-device-commands.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.