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. 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.
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.
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ätszu 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
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 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.
Zuletzt aktualisiert