Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium ;-)
-
Hi All,
weil ich im Forum und in GitHub in letzter Zeit vermehrt darüber gestolpert bin, möchte ich heute mal ein paar Zeilen zum Thema Bestätigt/Acknowledged-Flag beim setzen von State-Werten schreiben.
Wer jetzt denkt, das weiß ich doch alles ... lest doch vllt. noch ein Stück weiter
Aber fangen wir doch mal an mit einer kleinen Preisfrage (und bevor jemand fragt: Die Belohnung ist Wissen
)Kleine Preisfrage ...
Was genau bedeutet es "bestätigt/acknowleged" beim Setzen von State Werten auf "true" zu setzen?
Antwort A: Ich als User (bzw mein Skript) setzt "bestätigt" auf "true" um zu sagen das ich bestätige das der Wert so sein soll. (Ich bestätige dem Gerät das der Wert mein Wunsch ist.)
Antwort B: Das Gerät (bzw. der Adapter der das Gerät anbindet) zeigt mit "bestätigt" auf "true", das dies der Wert ist der beim Gert gerade wirklich gesetzt ist (Das Gerät hat diesen Wert als "echt" bestätigt.)
Bevor Ihr weiterlest beantwortet die Frage mal für euch ... ... ...
....
....
....
Wer für sich bei Antwort A gelandet ist, der sollte in jedem Fall weiterlesen, weil für Ihn schreibe ich das ganze
Alle anderen dürfen zur Überprüfung Ihres Wissens natürlich auch gern weiterlesen.Ok, wie ist es denn nun mit ack=true?
Antwort B ist korrekt.
Der "acknowledged" Flag (Deutsch "Bestätigt") kennzeichnet einen Wert ,der vom Gerät (bzw. vom Adapter auf Basis von Rückmeldungen vom Gerät - oder "bester Annahme") bestätigt wurde, als der Wert der gerade gesetzt ist. Es ist also "die Realität".
Im Normalfall setzen ausschließlich Adapter (bzw. eigene Skripte die den Status eines States "kennen") Werte mit ack=true. Es gibt nur sehr wenige Anwendungsfälle wo es Sinn macht das ein User bzw. ein Skript einen Wert mit ack=true setzt!
Jeder Adapter sollte jegliche Wertänderungen mit ack=true einfach ignorieren und nichts tun! Falls er es doch tut ist es ein Sonderfall oder ein Bug im AdapterBestätigte Werte werden im Admin "grün" angezeigt um zu visualisieren das der Wert direkt vom Adapter kommt und es der Wert sein sollte der dort gerade real ist.
Und wozu nutze ich dann ack=false?
Mit "Acknowledged=false" (was auch überall die Standardeinstellung ist) steuert man ein Gerät. Darauf sollten Adapter (wenn States schreibbar sind) dann auch reagieren und eine Steueraktion auslösen und den Wert zum Gerät senden.
Admin Zeigt Werte mit "ack=false" in rot an, um zu zeigen das man diesem Wert im ersten Schritt nicht uneingeschränkt vertrauen darf, weil das Gerät noch nichts dazu gesagt hat.
Im Normalfall wird der Adapter direkt (oder über Updates dann vom Gerät) nach einer Steueraktion einen neuen bestätigten Wert nach der erfolgten Steuerung setzen - das kann der Wert sein den man gesendet hat oder ein anderer!
Im Admin sieht man das das der gesetzte Wert kurz rot ist und dann kurz darauf von einem "grünen" Wert überschrieben wird. Das ist der Idealfall.Was heisst es wenn ein Wert "rot" bleibt?
Am Ende kann es grob drei Fälle geben wenn ein Wert "rot" (also unbestätigt) bleibt:
- Der Adapter bzw. das Skript die diesen State normalerweise abarbeiten werden gerade nicht ausgeführt. Dann nimmt niemand die Steueraktion entgegen und es bleibt halt so.
- Aus irgendeinem Grund konnte der Adapter die Steueraktion nicht ausführen (zB. weil das Gerät gerade offline ist) und hat auch keinen anderen neuen Wert vom Gerät. Dann könnte es im Logfile was zu finden geben.
- Es ist ein "write only State". Ein Write Only State (zB oft bei "Buttons) triggern bei Betätigung mit dem Wert "true" etwas, aber ausser dem "Trigger" haben sie keinen Wert. Ob so ein State vom Adapter wieder zurückgesetzt wird auf zB False mit ack=true ist Adapterspezifisch und nicht ganz so einfach zu definieren. Das jetzt hier genauer auszuführen würde diesen Rahmen deutlich sprengen.
Gibts das auch nochmal ausführlicher?
Ja, @haus-automatisierung hat das Thema uch in einem Video verarbeitet: Wer also die Erklärung gerne noch einmal in bewegten Bildern (mit ein paar Beispielen) sehen möchte:
https://www.youtube.com/watch?v=p5FyeifYUnw
Und bei eigenen Skripten?
Wenn Ihr Adapter-States steuern wollt ist das oben genannte genau so wichtig. Die "setState"-Methode hat den "ack"-Flag als dritten Parameter. Wenn er weggelassen wird oder auf false steht ist es eine "Steuern" Aktion, sonst wird der Wert "Aktualisiert" (ohne Steuerung). In Blockly und Rulez ist die Terminologie die gleiche.
Für eigene States (in zB 0_userdata.0.* oder javascript.X.*) obliegt es formal Euch wie Ihr arbeiten wollt. Wer die Unterscheidung, ob ein Wert "erfolgreich verarbeitet und umgesetzt" ist vs. "das wollte ich steuern" nicht braucht, kann den ack-Flag ignorieren ... Eine normale subscription auf einen State Wert liefert beide Wert-Änderungen, kann aber über Zusatzparameter eingeschränkt werden auf nur "ack: false" als Beispiel.
Aus Erfahrung sorgt das dann aber dafür das man in dem Umfeld gern mit "ack=true" arbeitet damit es im Admin "nicht als rot dargestellt wird" ... das kann hat zu einer Falle führen weil man dann immer umdenken muss.Ich persönlich versuche auch in Skripten mit korrekten ack-Flags zu arbeiten, um zu sehen ob ein Wert eine Steuerung ist oder der bestätigte Wert. Muss aber jeder für Sich entscheiden.
Gibts im Admin noch andere Farben?
In seltenen Fällen (bzw aktuell bei eher ausgewählten Adaptern) kann man noch State Werte in gelb sehen. Diese weisen an sich darauf hin das der Wert in irgendeiner Hinsicht als "Stale" (denke am besten als "veraltet" übersetzt) anzusehen ist. Das wird über das sogenannte "q" (aka "quality") Flag am State Wert gesteuert mit dem ein Adapter mitgeben kann das/ob ein Wert nur eine Annahme ist oder das Gerät aktuell offline ist und daher der Wert der "zuletzt bekannte aber potentiell veraltete" ist.
Das nutzen momentan nicht so viele Adapter - kommt vllt mal wieder mehr in ModeIch hoffe der kleine Exkurs hat mehr Fragen beantwortet als neue aufgeworfen - falls doch bitte einfach Fragen!
Eine aktuelle Idee ist das auch in der Admin UI etwas besser darzustellen das dort klarer wird das "bestätigt" bedeutet.Ingo
-
@apollon77 Vielen Dank für die Info.
Frage: Wird sich daran etwas ändern? Ich nehme das mit den Farben seit Jahren so hin (wurde vor Jahren man in einem Thread erklärt), bediene nichts in Skripten und frage auch nichts ab in eigenen Skripten. Daran ist bisher noch nichts gescheitert. Und solange es läuft, läuft es. Ist geplant, an dem Verhalten etwas zu ändern, so daß man alle seine Skripte durchflöhen und umstellen müßte? -
Das Konzept ist so tief verankert und macht - aus Datensicht - in jedem Fall weiterhin sinn.
Die Frage ist für mich eher wie man es für die User verständlicher aufbereiten/darstellen kann das es weniger zu Issues führt wie aktuell öfters mal.
Es kann höchsten sein das der Quality Flag vllt mehr genutzt wird, aber das ist erstmal eine andere Baustelle.
-
Das sind wirklich wichtige Grundlagen, welche viele noch nicht verstanden habe. Wer die Erklärung gerne noch einmal in bewegten Bildern (mit ein paar Beispielen) sehen möchte:
-
@haus-automatisierung sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:Wer die Erklärung gerne noch einmal in bewegten Bildern (mit ein paar Beispielen) sehen möchte:
https://www.youtube.com/watch?v=p5FyeifYUnwCool ... kommt oben noch mit rein. Danke!!
-
Dazu muss ich mal eine Frage stellen: gibt es eine Möglichkeit auf unbestätigt zu prüfen? Ich lasse zb unsere Zirkulationspumpe laufen (über eine Tasmota Schaltsteck). Da wäre es wichtig mit zu bekommen, wenn der Sonoff Adapter die Schaltsteck nicht erreichen und zb nicht ausschalten kann.
-
@mading naja Du könntest ein Skript schreiben welches den relevanten State subscribed einmal mit "ack: true" und einmal mit "ack:false". Wenn ack:false dann startest Du einen Timer nach dessen Ablauf Du etwas tun willst, zB ne email senden oder sowas. Wenn ack: true kommt beendest du den Timer, sodas er nicht auslöst.
Voilaa
-
So meinst du, oder?
// edit vermutlivh macht es Sinn, nochmal den Status von Power nach 2s zu holen und dann aus zu schalten falls true
-
Ich benutze das regelmäßig, wenn ich Datenpunkte habe, die gleichzeitig einen Status anzeigen und aber nicht immer auslösen sollen.
z.B. bei dem HomeKit Garagenöffner gibt es den Target State für die Garage, der im Normalfall, wenn es nicht gleich dem Current State ist, die Garage bedienen soll. Wenn ich die Garage ausschließlich über HomeKit bediene, ist das kein Problem, ich will sie habe auch über die Homematic Fernbedienung bedienen und gleichzeitig soll der Status in der HomeKit App korrekt sein.
Für diesen Fall benutze ich ack == false und in dem entsprechenden Listner die Konstruktion also
on({ id: path_garage + 'Garage_TargetDoorState',change:"any",ack: false }, function (obj) { setState(path_alias + 'direct.AS_Garagenschalter',true) });Und wenn "Garage_TargetDoorState' nicht auslösen, aber für die Anzeige in HomeKit geändert werden soll, dann
setState(path_garage +'Garage_TargetDoorState',siri_closed,true) -
Eine Grafik hilft evtl auch?
-
@mading sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:So meinst du, oder?
// edit vermutlivh macht es Sinn, nochmal den Status von Power nach 2s zu holen und dann aus zu schalten falls true
So auf keinen Fall.
Bitte so:
-
Für die Blockly-User noch eine Eselsbrücke:
wenn ich mit dem Wert etwas über einen Adapter steuern will muss ich den Blocksteuere ID...nehmen. (dieser arbeitet mit Ack=false.In eigenen Datenpunkten will ich den Wert nur aktualisieren. Also mit dem Block
aktualisiere ID... -
@homoran sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:In eigenen Datenpunkten will ich den Wert nur aktualisieren. Also mit dem Block
aktualisiere ID...Auch wenn history dieses Datum wegschreiben soll?
-
@klassisch sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:@homoran sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:In eigenen Datenpunkten will ich den Wert nur aktualisieren. Also mit dem Block
aktualisiere ID...Auch wenn history dieses Datum wegschreiben soll?
ja!
jetzt wird es semantisch anspruchsvoll. Hoffentlich korrekt:
history verarbeitet nicht den Wert in dem Adapter wie z.B. die Zielhelligkeit im Dimmer , sondern loggt diesen nur. -
@klassisch History (oder influx oder sonstige) reagieren auf die Stgate-Änderung an sich, egal ob ack true oder nicht.
Sobald sich was ändert, wird geschrieben. Wenn Du jetzt einen Adapter-Datenpunkt mit 1 beschreibst und dieser dann vom Adapter auf 2 rückgemeldet wird (z.B. beim Harmony-Adapter zum Starten von Activities) so wird sowohl die 1, als auch die 2 weggespeichert.Gruss, Jürgen
-
@asgothian danke, d.h. mit dem deutschen UI so:
-
@wildbill sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:History (oder influx oder sonstige) reagieren auf die Stgate-Änderung an sich, egal ob ack true oder nicht.
diese Formulierung hatte ich verworfen
da auch bei Aktualisierung geloggt werden kann. -
@homoran Jedenfalls halten sich history, influx & Co nicht an die übliche Adapter-Verhaltensweise. Macht Sinn, ist aber eine erwähnenswerte Ausnahme. Gibt es noch mehr solcher Ausnahmen. Visualisierungsadapter?
-
@klassisch sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:Jedenfalls halten sich history, influx & Co nicht an die übliche Adapter-Verhaltensweise
Das sind zwei Paar Schuhe! Das wollte ich mit dem Satz: "History verarbeitet nicht den Wert" klar machen, was mir anscheinend nicht gelungen ist.
Dort wird -egal was da steht- nur geloggt.@klassisch sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:ist aber eine erwähnenswerte Ausnahme.
richtig! Das sollte erwähnt werden.
@klassisch sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:Gibt es noch mehr solcher Ausnahmen. Visualisierungsadapter?
ich weiss jetzt nicht genau, was du damit meinst. Aber analog zu den Historisierungen, werden nur die Werte in den Widgets übernommen.
-
@mading sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium
:@asgothian danke, d.h. mit dem deutschen UI so:
Warum der zweite Trigger? Geht auch in einem:
(hatte ich damals mal im Community-Tab auf YouTube als Quiz gepostet - daher auch noch die alten Bezeichner "anerkannt" statt "bestätigt")
