> 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/devices/commands/verification.md).
# Befehle bestätigen
Wie Kilo IoT Server bestätigt, dass ein Befehl wirksam geworden ist — keine Verifizierung, Prüfung beim nächsten Uplink oder Abfrage nach dem Ack.
Das Senden eines Befehls und zu wissen, dass er funktioniert hat, sind zwei verschiedene Dinge. Ein Downlink kann zur Zustellung akzeptiert werden und dennoch das physische Gerät nie verändern — das Gerät könnte schlafen, außerhalb der Reichweite sein oder ihn einfach ignorieren. Der **Verifizierung** Der Abschnitt des Befehlseditors ermöglicht es Ihnen, der Plattform mitzuteilen, wie bestätigt werden soll, dass ein Befehl tatsächlich wirksam geworden ist, sodass eine Ausführung nur dann als erfolgreich markiert wird, wenn dahinter echte Belege stehen.
Die Verifikation wird pro Befehl konfiguriert, in **Abschnitt 4** des [Befehlseditors](/kilo-docs-de/kilo-iot-server/devices/commands/creating-commands.md). Wählen Sie eine von drei Strategien.
## Keine Verifizierung
Senden und vergessen. Der Befehl wird gesendet und die Plattform prüft das Ergebnis nicht.
Mit dieser Strategie wird eine Ausführung als **Zugestellt markiert, sobald der Downlink zur Zustellung akzeptiert wurde — nicht erst, wenn das Gerät darauf reagiert.** (Das grüne **Zugestellt** Status bedeutet genau das: gesendet, aber unverifiziert — anders als **Bestätigt**, was nur eine Verifikationsstrategie erzeugen kann.) Es gibt keine Garantie, dass die Aktion irgendeine Wirkung hatte. Das ist für nicht kritische, idempotente Aktionen geeignet, bei denen ein verpasster Befehl harmlos ist und ohnehin erneut gesendet wird, aber verlassen Sie sich niemals darauf als Beweis dafür, dass sich physisch etwas geändert hat.
## Auf das nächste Uplink warten
Nachdem der Befehl gesendet wurde, wartet die Plattform auf den nächsten regulären Uplink des Geräts und prüft ihn gegen die **erwarteten Sensorzustände** die Sie definieren. Wenn die gemeldeten Werte übereinstimmen, wird die Ausführung bestätigt.
Das eignet sich für Geräte, die nach Zeitplan melden und ihren Zustand in der normalen Telemetrie abbilden — zum Beispiel ein Controller, der seinen aktuellen Sollwert oder seine Relaisposition in jedem Uplink mitliefert.
## Abfrage nach Bestätigung
Die gründlichste Option. Nachdem das Gerät den Befehl bestätigt hat, sendet die Plattform einen **Abfragebefehl** — ein kleiner Lesezugriff, der das Gerät nach seinem aktuellen Zustand anstößt — und gleicht die Uplink-Antwort dieser Abfrage mit den erwarteten Zuständen ab.
Bei einem LoRaWAN-Gerät schalten Sie **Bestätigter Downlink** in Abschnitt 2 (Routing) ein, bevor Sie diese Strategie wählen. Die Abfrage wird gesendet, sobald das Gerät den Befehl bestätigt, also muss es überhaupt eine Bestätigung geben, auf die gewartet werden kann — andernfalls wird der Befehl nicht gespeichert. Wenn Sie lieber keinen bestätigten Downlink verwenden möchten, wählen Sie *Auf das nächste Uplink warten*.
* **Abfragebefehl** — Wählen Sie einen vorhandenen Abfragebefehl oder **erstellen Sie einen neuen** inline. Ein Abfragebefehl ist ein dedizierter, leichtgewichtiger Befehlstyp: ein **zustandsabfragender Lesezugriff ohne Operatorparameter**, also gibt es zur Ausführungszeit nichts auszufüllen. Er selbst ist immer auf **Keine Verifizierung** — die Abfrage *ist* die Verifikationsstufe, und sein Uplink ist das, was geprüft wird, daher enthält er keinen eigenen Verifikationsblock. Jeder Befehl, der keine Parameter annimmt und Keine Verifikation verwendet, kann als Abfragebefehl dienen und erscheint in dieser Liste. Nach dem Speichern erscheint er in der Befehlsliste, als für eine Abfrage geeignet gekennzeichnet, und kann von jedem anderen Befehl wiederverwendet werden *Abfrage nach Bestätigung*.
* Geben Sie im **Neuer Abfragebefehl** Dialog definieren Sie die Nutzlast, die das Gerät abfragt. Für MQTT-Geräte wählen Sie, ob Sie **Unverändert senden** (die Nutzlast genau so ausliefern, wie sie geschrieben wurde) oder **Mit Encoder verarbeiten** (sie zuerst durch den Encoder des Geräts laufen lassen).
* Die Abfrage wird ausgeführt, nachdem das Gerät bestätigt hat, und ihre Antwort wird anhand der erwarteten Zustände unten ausgewertet.
Verwenden Sie dies, wenn ein Gerät seinen Zustand nicht in regulären Uplinks von selbst mitteilt, aber auf einen direkten Lesezugriff antwortet.
## Erwartete Sensorzustände
Sowohl *Auf das nächste Uplink warten* und *Abfrage nach Bestätigung* prüfen die vom Gerät gemeldete Telemetrie mit den Zuständen ab, die Sie hier angeben. Klicken Sie **Zustand hinzufügen** um eine Zeile hinzuzufügen, und füllen Sie die beiden Felder unten aus. Fügen Sie mindestens eine Zeile hinzu — der Befehl wird sonst nicht gespeichert.
### Messwert
Wählen Sie den Sensor, den der Befehl verändert. Ein Befehl, der ein Relais schaltet, wird gegen den Sensor geprüft, der den Zustand des Relais meldet, nicht gegen Batteriestand oder Signalstärke.
Das Dropdown listet die Sensoren des Geräts unter den Namen auf, die Sie ihnen beim Mapping gegeben haben — dieselben Namen, die Sie auf Dashboards und in Regeln sehen. Diese Namen sind nicht die Feldnamen in Ihrem Decoder: Ein Decoder, der `socket_status` kann hier erscheinen als *Steckdosenstatus*. Um zu sehen, welcher Sensor welches dekodierte Feld enthält, öffnen Sie den Mapping-Abschnitt des Geräts — siehe [Payload-Dekodierung und Connector-Schlüssel](/kilo-docs-de/kilo-iot-server/devices/payload-decoding.md).
Wählen Sie einen Sensor, der bereits gemappt ist und Messwerte empfängt. Nicht gemappte Sensoren erscheinen ebenfalls in dieser Liste, und ein dagegen geprüfter Befehl erhält nie einen Wert zum Vergleichen, also endet er jedes Mal als *Leichte Warnung* immer. Wenn das Gerät noch keine Sensoren gemappt hat, führt der Editor Sie zum Mapping-Abschnitt, damit Sie sie zuerst einrichten.
### Erwarteter Wert
Geben Sie den Wert ein, den der Sensor melden soll, sobald der Befehl wirksam geworden ist. Schreiben Sie ihn genau so, wie das Gerät ihn meldet — öffnen Sie den Mapping-Abschnitt des Geräts und lesen Sie den aktuellen Wert des Sensors, um die zu kopierende Form zu sehen.
**Für einen Textzustand**, geben Sie ihn direkt ein. Groß- und Kleinschreibung spielt keine Rolle, also `ein` passt zu einem Gerät, das `EIN`.
**Für einen Zahlen- oder Wahr/Falsch-Zustand**, verweisen Sie stattdessen auf einen Befehlsparameter: geben Sie `{{ parameterName }}` ein und deklarieren Sie diesen Parameter im Nutzlast-Abschnitt als Ganzzahl, Float oder Boolean. Ein Wert, den Sie eingeben, wird immer als Text behandelt, also sucht ein eingegebenes `1` nach dem Text `1` und wird nicht mit einem Gerät übereinstimmen, das die Zahl 1 meldet.
**Um der Eingabe des Bedieners zu folgen**, verwenden Sie dieselbe `{{ parameterName }}` Referenz — ein "Helligkeit setzen"-Befehl kann prüfen, dass das Gerät nun genau die angeforderte Helligkeit meldet. Der Name muss mit einem im Nutzlast-Abschnitt definierten Parameter übereinstimmen; der Editor markiert ihn, wenn das nicht der Fall ist.
| Der Sensor meldet | Geben Sie |
| -------------------- | ------------------------------------------------------ |
| `ein` oder `EIN` | `ein` |
| `offen` | `offen` |
| `60` (eine Zahl) | `{{ level }}`, wobei **level** als Ganzzahl deklariert |
| `wahr` (wahr/falsch) | `{{ state }}`, wobei **state** als Boolean deklariert |
Wenn ein Befehl immer als *Leichte Warnung* endet, obwohl das Gerät eindeutig geantwortet hat, prüfen Sie zuerst dieses Feld: Vergleichen Sie, was Sie eingegeben haben, mit dem Wert, den der Sensor im Mapping-Abschnitt tatsächlich meldet.
## Konvergenz-Timeout
Die **Konvergenz-Timeout** ist die Zeit, die die Plattform wartet, bis der gemeldete Zustand übereinstimmt, bevor sie aufgibt.
* Leer lassen, um den Plattform-Standard von **1,5 × dem Daten-Sendeintervall des Geräts**zu verwenden. Stellen Sie dieses Intervall zuerst auf dem Gerät korrekt ein — wenn es fehlt, ergibt der Standard ein 90-Minuten-Fenster, das für die meisten Befehle viel länger ist als nötig.
* Oder geben Sie einen eigenen Wert ein, bis zu 24 Stunden.
* Wenn das Fenster verstreicht, ohne dass eine Übereinstimmung gefunden wird, wird die Ausführung als **Leichte Warnung** statt als Fehlgeschlagen markiert — der Befehl wurde zugestellt und bestätigt, aber die Plattform konnte die Wirkung innerhalb der erwarteten Zeit nicht bestätigen. Diese Unterscheidung ist operativ wichtig: Eine weiche Warnung bedeutet "wir konnten nicht bestätigen", nicht "es ist definitiv fehlgeschlagen".
* Ein Befehl, der innerhalb seines Fensters nicht bestätigt wird, wird nicht erneut gesendet. Führen Sie ihn selbst erneut aus oder lassen Sie dies von einer Regel erledigen.
## Eine Strategie wählen
| Strategie | Bestätigt | Am besten geeignet für |
| ----------------------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------- |
| Keine Verifizierung | Nur Zustellung | Aktionen mit geringem Risiko, die sich wiederholen lassen |
| Auf das nächste Uplink warten | Gemeldeter Zustand in der nächsten geplanten Nachricht | Geräte, die ihren Zustand regelmäßig melden |
| Abfrage nach Bestätigung | Gemeldeter Zustand aus einer direkten Abfrage | Geräte, die auf Lesezugriffe antworten, aber ihren Zustand nicht selbst mitteilen |
Sobald die Verifikation gesetzt ist, gehen Sie weiter zu [Befehle ausführen](/kilo-docs-de/kilo-iot-server/devices/commands/executing-commands.md) um den Befehl zu senden und das Ergebnis zu beobachten. Die gesamte Sequenz auf einem Gerät — Nutzlast, Verifikation und Ausführung — finden Sie unter [Beispiel: Smarte Steckdose](/kilo-docs-de/kilo-iot-server/devices/commands/smart-socket-example.md).
---
# 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/devices/commands/verification.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.
