Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium ;-)

[Loredo]

Sehr gut, super!

Ich mache regen Gebrauch davon im neuen Residents Logik-Adapter, auch von den Quality Infos, wenn ich Kommandos (also Änderungen mit ack=false) ablehne und den ursprünglichen Wert (dann mit ack=true) wieder zurückschreibe (letzteres muss sich wohl jeder Adapter noch immer für sich selbst merken, weil es nicht im Event mitkommt? So macht es ja auch der JavaScript Adapter bisher, wäre aber auch was Feines das zu generalisieren </OffTopic>).

[Loredo]

@apollon77 sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium :

@klassisch Die Hsitory-Adapter schreiben alles weg was kommt - inklusiveden ack flag ...

Bedeutet aber, wenn ein Adapter eine Änderung ablehnt und den alten Wert wieder zurückschreibt, dann wird eigentlich auch etwas geloggt, was gar nicht geloggt hätte werden dürfen?

[OliverIO]

@loredo
gültige werte sollten dann eigentlich auch ack=true haben.
die ack=false werte sollten man nicht betrachten.
ich denke, das die diagram-adapter das auch so berücksichtigen

[paul53]

@loredo sagte: Bedeutet aber, wenn ein Adapter eine Änderung ablehnt und den alten Wert wieder zurückschreibt, dann wird eigentlich auch etwas geloggt, was gar nicht geloggt hätte werden dürfen?

Ja, wenn nicht nur Wertänderungen aufgezeichnet werden sollen.
Bei einer Ablehnung sollte nicht zurück geschrieben werden, sondern stattdessen eine Warnung erzeugt werden.

[Loredo]

@paul53 sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium :

@loredo sagte: Bedeutet aber, wenn ein Adapter eine Änderung ablehnt und den alten Wert wieder zurückschreibt, dann wird eigentlich auch etwas geloggt, was gar nicht geloggt hätte werden dürfen?

Ja, wenn nicht nur Wertänderungen aufgezeichnet werden sollen.
Bei einer Ablehnung sollte nicht zurück geschrieben werden, sondern stattdessen eine Warnung erzeugt werden.

Das geht bei einem Logik-Adapter nicht, der auf konsistente Werte angewiesen ist. Der korrekte Wert wäre aber nach einem Adapter Neustart dann weg und nur noch der nicht korrekte/zurückgewiesene Wert vorhanden.

[Homoran]

@loredo sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium :

was gar nicht geloggt hätte werden dürfen?

warum nicht?
wenn dann auch geloggt wird dass ack=true war, sieht man in der History warum der Adapter nicht reagiert hat.
Außerdem wird auch noch die Quelle der Werteänderung gespeichert sofern dies konfiguriert ist.

[paul53]

@loredo sagte: Das geht bei einem Logik-Adapter nicht

Welche Logik?

[Loredo]

@paul53 Ein Adapter, der kein physisches Gerät hinten rum abfragt, sondern allein für sich alleine werkelt. Der verliert den eigentlich korrekten Wert bei einem Neustart, denn er kann sich nur auf die aktuellen Werte in den States verlassen.

[paul53]

@loredo sagte: allein für sich alleine werkelt.

Weshalb muss er von sich aus das Ack-Flag beeinflussen?

[Loredo]

@paul53 das ist genauso wie bei einem physischen Gerät hinten dran: Ein Logik-Adapter bekommt eine Kommando-Anfrage mit ack=false und kann sich überlegen, ob er es verarbeitet oder nicht. Ein physisches, externes Gerät macht das genauso und je nachdem, wie "gut" die externe API implementiert ist, liefert das externe Gerät dann den neuen Wert als Bestätigung zurück oder eben den alten Wert wieder. In beiden Fällen wird der Adapter aber die Antwort dann mit ack=true schreiben. Ich mache in meinem Residents Adapter nichts anderes, nur dass ich auch so geschäftig bin zusätzlich noch das Quality Flag zu benutzen, so wie es gedacht ist

[paul53]

@loredo sagte: liefert das externe Gerät dann den neuen Wert als Bestätigung zurück oder eben den alten Wert wieder. In beiden Fällen wird der Adapter aber die Antwort dann mit ack=true schreiben.

Im dritten Fall, dass das Gerät sich nicht zurück meldet, schreibt ein Geräte-Adapter nichts zurück. Das würde wohl eher dem Fall "nicht annehmen" entsprechen.

[Loredo]

@paul53 sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium :

@loredo sagte: liefert das externe Gerät dann den neuen Wert als Bestätigung zurück oder eben den alten Wert wieder. In beiden Fällen wird der Adapter aber die Antwort dann mit ack=true schreiben.

Im dritten Fall, dass das Gerät sich nicht zurück meldet, schreibt ein Geräte-Adapter nichts zurück. Das würde wohl eher dem Fall "nicht annehmen" entsprechen.

Jaein, das kommt eben ganz drauf an. Einige Adapter reagieren leider so, selbst wenn sie eigentlich "verbunden" sind und werten die Rückmeldung (oder eben das Fehlen jener) nicht gut aus. Ist zumindest meine bescheidene Beobachtung und ist nicht der Anspruch, den ich an einen gut implementierten Adapter hätte.

[paul53]

@loredo
Es entspricht der Philosophie von ioBroker, dass der Datenpunkt ein Sollzustands-Datenpunkt (val = neuer Wert, ack = false) bleibt, solange die Rückmeldung ausbleibt.

[klassisch]

Ich hatte mir zum ack Thema mal den github-iobroker-wiki-Artikel notiert: https://github.com/ioBroker/ioBroker/wiki/Adapter-Development-Documentation#commands-and-statuses

Ist das noch aktuell?

[Loredo]

@paul53 Es ist halt ein Unterschied nicht zu reagieren oder etwas nicht anzunehmen und zurückzuweisen. Nicht zu reagieren, obwohl man das Kommando wahrgenommen hat, ist halt nicht zu unterscheiden davon, dass der Adapter einfach nicht läuft. Ich finde es aber wichtig das zu unterscheiden. IMHO sollte ein laufender Adapter immer etwas tun, aber mir persönlich reicht da ein einfacher Logeintrag nicht. Ich möchte das auch Event basiert verarbeiten können und auch direkt im Admin Adapter sehen können, ohne das Log zu durchforsten.

Die von dir besagte Philosophie stört mich nicht selten und hinterlässt bei mir oft den Eindruck eines nur halb fertigen Adapters.
Es ist aber erlaubt, dass du eine andere Meinung hast als ich

[paul53]

@klassisch sagte: Ist das noch aktuell?

Ja, und es beschreibt es so, wie ich geschrieben habe.
Beispiel: HomeMatic, Datenpunkt MANUAL_MODE: Darüber schaltet man den Thermostaten in den manuellen Modus und man übergibt den manuellen Sollwert. Dieser Datenpunkt wird nie bestätigt.

Anmerkung: ioBroker ist ursprünglich aus einer Erweiterung für HomeMatic hervorgegangen. Das ist für Dich sicher nicht neu, aber wahrscheinlich für @Loredo.

[Loredo]

@paul53 Korrekt. Nein das ist nicht neu für mich, sondern an vielen Stellen sehr offensichtlich (was nicht schlimm ist). Ich kenne ioBroker auch schon seit etlichen Jahren, auch wenn ich ihn noch nicht so lange aktiv nutze.
Das ist für mich aber deshalb nicht dauerhaft in Stein gemeißelt, sondern kann sich weiterentwickeln
Ich habe für meinen Adapter entschieden, dass ich das Verhalten so sinnvoller finde. Vor allem auch deshalb, weil eine Darstellung der tatsächlich korrekten Werte über eine externe GUI möglich sein soll. Da stört es, wenn in der GUI dann plötzlich aber Werte angezeigt werden, die gar nicht dem Ist-Zustand entsprechen. Meine oberste Priorität ist immer, den Ist-Zustand zu jeder möglichen Zeit richtig anzuzeigen, nicht den Soll-Zustand.

[paul53]

@loredo sagte: Ist-Zustand zu jeder möglichen Zeit richtig anzuzeigen, nicht den Soll-Zustand.

Dann muss aber auch der Wert mit dem Ist-Wert überschrieben werden - nicht nur das Ack-Flag. Der Fehlversuch wird dann natürlich in der History mit aufgezeichnet.

[Loredo]

@paul53 sagte in Bestätigt/Acknowledged-Flag Bedeutung - ein Mysterium :

@loredo sagte: Ist-Zustand zu jeder möglichen Zeit richtig anzuzeigen, nicht den Soll-Zustand.

Dann muss aber auch der Wert mit dem Ist-Wert überschrieben werden - nicht nur das Ack-Flag.

Hatte ich ja oben auch so geschrieben, dass ich oldState mit ack=true ergänzt von z.B. q=0x40 zurückschreibe
oldState muss sich halt der laufende Adapter selbst organisieren, weshalb es auch unschön ist, wenn Änderungen an Objekten passieren, während der Adapter nicht läuft. der JS-Controller wäre besser dafür geeignet, oldState (also nur die States mit ack=true) für alle Adapter bereitzuhalten, aber sowas gibts wohl bisher nicht.

By the way, da fällt mir gerade wieder der Bug ein, der mir bei der Entwicklung begegnet ist:
getForeignStateAsync() liefert nur ack: false

Dadurch muss man beim zurückschreiben (je nachdem, wie lange der Adapter schon läuft) trotzdem nochmal explizit ack=true setzen. Das aber nur am Rande erwähnt, weil es auch was mit der Nutzung der ack Werte zu tun hat. Das macht es leider derzeit auch schwierig den ack-Wert außerhalb von Events abzuprüfen, weil der Wert eben immer false ist und nie true </OffTopic>

[Marty56]

@wildbill
das stimmt und ich finde es bedauerlich!
Ich hätte gerne, dass ich mit setState() steuern könnte, ob ein Wert im History Adapter an die jeweilige DB übertragen wird.