[Bug]: setStateChanged funktioniert nicht wie erwartet

[paul53]

I'm sure that

• This issue is still present in the current beta version of this adapter
• There is no other (open) issue with the same topic (use the search!)
• This issue is not described in the adapter documentation / FAQ (read the docs!)

Script type

Javascript

The problem

Es wird nur dann nicht aktualisiert, wenn sowohl der Wert als auch die Bestätigung übereinstimmen. Das macht bei Adapter-Datenpunkten keinen Sinn.

iobroker.current.log (in debug mode!)

No response

Version of nodejs

20.17.0

Version of ioBroker js-controller

6.0.11

Version of adapter

8.7.6

[mcm1957]

Die Funktion von setStateChanged prüft ALLE Attribute des States. Dies gilt sowohl für setStateChanged in javascript als auch im Adapter API). M.E. sollte hier nur die Dokumentation angepasst werden damit die Funktion zwischen Java-Script und Adapter API bei gleichem Namen nicht unterschiedlich ist. Bei Schreibzugriffen auf input Parameter von Adaptern würde ein ignorieren des ACK Flags ggF Sinn machen, bei Zugriffen auf eigene States schon wieder weniger.

[paul53]

Die Funktion ist für die meisten Anwender nur dann bequem, wenn das Ack Flag nicht berücksichtigt wird. Auf einen Adapter-Datenpunkt wird unbestätigt geschrieben und der Adapter bestätigt den Wert. Beim nächsten unbestätigten Schreiben mit dem gleichen Wert soll nicht nochmal gesendet werden.

[paul53]

Das ursprüngliche Issue bezieht sich auch auf Wertänderung.

[mcm1957]

Die Funktion ist für die meisten Anwender nur dann bequem, wenn das Ack Flag nicht berücksichtigt wird. Auf einen Adapter-Datenpunkt wird unbestätigt geschrieben und der Adapter bestätigt den Wert. Beim nächsten unbestätigten Schreiben mit dem gleichen Wert soll nicht nochmal gesendet werden.

Dann sollte die Funktion ggF setStateValueChanged heißen. Unterschiedliche Funktionalitäten der javascript Adapter under Api Funktionen mit identiuscher Bezeichnung sind m.E. mehr als suboptimal.

[paul53]

Ja, ein anderer Bezeichner für die Funktion wäre dann sinnvoll.

[Apollon77]

Naja wenn bräuchte man dioe folgende Logik

• Wenn wert passt und neuer ack===false -> dann nur wert prüfen
• Wenn Wert passt und neuer ack===true -> Dann prüfen ob wert und ack passen

So macht das fpr mich sinn und verhindert das ein kommando nochmal angestossen wird oder nochmal der gleiche wert "gesteuert" wird. Das wäre denke ich das sinnvolle verhalten, oder sieht jemand andere Fälle?

[paul53]

Ich würde weiter gehen und nur dann aktualisieren, wenn

• neuer Wert != alter Wert ODER alter ack == false

Dann wird wiederholt gesendet, wenn der Wert beim letzten Mal nicht bestätigt wurde.

[mcm1957]

Naja wenn bräuchte man dioe folgende Logik

• Wenn wert passt und neuer ack===false -> dann nur wert prüfen
• Wenn Wert passt und neuer ack===true -> Dann prüfen ob wert und ack passen

So macht das fpr mich sinn und verhindert das ein kommando nochmal angestossen wird oder nochmal der gleiche wert "gesteuert" wird. Das wäre denke ich das sinnvolle verhalten, oder sieht jemand andere Fälle?

Was GENAU macht die Adapter Api Funktion eigentlich. Auf was ich raus will ist defaultet die ADAPTER Funktion eventuell die nicht angegebenen Werte (z.B. ACK nicht angegeben) mit dem alten Wert (bzw. prüft sie die Änderung nur wenn ACK explizit auf true od. false gesetzt wird) ?

Wenn dies der Fall ist, dann liegt ev. der "Fehler" im JavaScript Adapetr darin dass unabhängog davon ob der ACK Paramater im Javascript Code gesetzt ist immer true oder false an die untenliegende Schicht (Adapter Api) weiterreicht statt zwischen explizit true / false und "nicht angegeben" zu unterscheiden.

Nur mal so ein Gedankengang zur Prüfung da das Problem ja im Adapterumfeld bisher nicht aufgetreten ist.

[Apollon77]

@paul53 aDas wäre aber mehr breaking als mein vorschlag :-) bedenke bitte das viele User das nutzen. Aber ja man kann auch die eine Methode deprecatenund eine neue mit besser definiertem Verhakten machen. Ich denke Anpassen der alten nach meinem Vorschlag könnte gehen

[mcm1957]

@Apollon77
Ich bin noch immer der Meinung dass eine Funktion die ident zu einer API Funktion heißt sich auch ident verhalten sollte.
Also wenn im JS Adapter eine andere Funktionalität als im API gegeben sein soll, dann sollte die Funktion einen neuen Namen erhalten.

[paul53]

@Apollon77
Ich bin auch der Meinung, dass die Funktion einen neuen Bezeichner erhalten sollte.
Ziel der neuen Funktion sollte sein, dass ein neuer Wert an ein Gerät gesendet wird und dann, wenn das Senden erfolgreich war (Bestätigung), der gleiche Wert nicht wiederholt gesendet wird.

[Apollon77]

@mcm1957 Diesen Namenszusammenhang "interne API" und "JavaScript Adapter API" ist nirgendsfestgeschrieben und wäre auch bei vielem anderen nicht gegeben. Von daher: Trenne das bitte in Deinem Kopf. Den Anspruch gibts nicht. JavaScript Adapter ist "End user convenient API"

[mcm1957]

@Apollon77
Ich habe mir jetzt mal den API Code angesehen. Dieser prüft nur jene Paramater die EXPLIZIT angegeben werden, also

setStateChanged ( id, value) prüft nur das Value
setStateChanged ( id, value, false) prüft Value und Ack

https://github.com/ioBroker/ioBroker.js-controller/blob/d8db1108c68ebb24923ed095d272881bbccb3d4c/packages/adapter/src/lib/adapter/adapter.ts#L8259

Insofern sollte der JAVA Script Adapter bei der Function keinsfalls selbst was defaulten sondenr die Paramater 1:1 durchreichen.

ABER
Für den Einsatzzweck wie oben wäre eine anders benannte Funktion sinnvoll da dort gewunschen ist das ACK Flag zu clearen nur wenn sich Value geändert hat. Das ist also eine andere Funtkion als die setStateChange API Funktion anbietet. Ergo neuer Name für neue unterschiedliche Funktion,