UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Mic]

@arteck sagte in Frage zu subscribeForeignStates() -> ack:

if (state && !state.ack) {

Danke für deine Antwort

Aber lt. deinem Code-Beispiel

if (state && !state.ack) {

ist ack ausgeschlossen (durch && !...im Ausdruck).
In meinen bisherigen Adaptern mache ich das auch so, aber nur bei den Adapter-eigenen States.

Was aber, wenn sich ein fremder State ändert, lieber auf ack=false, oder ack=true reagieren, oder in meinem zukünftigen Adapter sogar als Option für jeden Datenpunkt anbieten?
Evtl. wäre tatsächlich als Option nicht schlecht, da nicht alle JS-Scripts "true" zurückgeben, etc.

[arteck]

@Mic es ist nicht ausgeschlossen sonder als eine verneinte "und Anweisung"

also wenn (state && state.ack == false)

[Mic]

Hey @arteck
Jetzt verwirrst du mich noch mehr mit deinem

ich frag beides ab

Also das hier:

if (state && !state.ack) {

if (state) prüft ja das State-Objekt auf truthly: All values are truthy unless they are defined as falsy (i.e., except for false, 0, -0, 0n, "", null, undefined, and NaN).

Dann wird geprüft (durch &&) :
if (!state.ack). Wenn kein acknowledge, dann geht es ins else bzw. in die leere...

[arteck]

@Mic

jo genau so... wie du es beschreibst...

aber das sind eigene States.. bei fremden .. hmm gute frage..

[AlCalzone]

@Mic sagte in Frage zu subscribeForeignStates() -> ack:

Sobald Bewegungsmelder ausschlägt, ein Wandschalter gedrückt wird, oder ein User in javascript.0.machWas den Datenpunkt-Wert ändert, soll was ausgelöst werden in onStateChange().
Reicht da ack=false, oder muss ich auch ack=true abfangen, bzw. beides?

Bei anderen Adaptern solltest du davon ausgehen, dass die States erst "gültig" bzw. bestätigt sind, wenn ack: true.

States mit ack: false zu setzen, ist eine Aufforderung an den dazugehörigen Adapter (oder Skript), diese Änderung zu verarbeiten.

[Mic]

Danke @AlCalzone

Evtl. wäre es sinnvoll, im Adapter eine Option anbieten, bei User-Datenpunkten unterhalb javascript.x und 0_userdata.0 auch auf ack:false zu reagieren... Also grad wenn user-eigene Scripts das nicht so sauber machen... Mal sehen

[SKB]

Der Beitrag ist zwar schon alt, aber vielleicht kommt ja nochmal jemand her und fragt sich zu dem Thema.

Ich frage alle states auf ACK true ab, außer die eigenen und die von Javascript und Userdata - also startsWith.

[mcm1957]

@skb said in Frage zu subscribeForeignStates() -> ack:

Der Beitrag ist zwar schon alt, aber vielleicht kommt ja nochmal jemand her und fragt sich zu dem Thema.

Ich frage alle states auf ACK true ab, außer die von Javascript und Userdata - also startsWith.

Das wäre aber fehlerhaft wenn es sich um Adaptercode handelt.

Adaptercode sollte / darf bei eigenen States NUR auf externe Writes ('state writeable') mit ACK=FALSE reagieren. Alles andere kann man zwar programmieren ist aber einer Verletzung der ioBroker Philosophie.

Oder zusammengefasst:

• eigene States des Adapters

  • die von externen Quellen beschrieben werden (= Input):
    nur state changes mit ack=false sind zu beachten
  • die selbst vom Adaptercode beschrieben werden (= eher seltener Sonderfall dass der Code diese Änderungen per subscribe überwacht):
    ack je nach dahinetrstehender Logik beliebig zu beachten

• States eines anderen Adapters
  normalerweise sind hier nur state changes mit ack=true zu beachten, d.h. der fremde Adapter hat einen bestätigten Wert geschrieben. Alternativen sind je nach Logik denkbar

• States im 0_user_0 Bereich
  wären prinzipiell analog zu fremden States zu betrachten. Die meisten Adapter ignorieren hier allerdings das ack Flag aus Komfortgründen für die User.

Siehe auch: https://forum.iobroker.net/topic/61876/bestätigt-acknowledged-flag-bedeutung-ein-mysterium

Zitat aus obigem Beitrag:

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 Adapter

[SKB]

@mcm1957 wieso fehlerhaft?

Viele User schreiben ihre Skripts oder Blockly nicht sauber und haben demnach kein ACK true mit dabei.

Daher reagiere ich in den Fällen nicht drauf, was so absolut ok ist!

Eigene states des Adapters bearbeite ich auch mit ACK false, da der Adapter ja damit etwas tun soll und diesen dann bestätigt.

[mcm1957]

@skb

Wenn der User mit ACK=TRUE in einen State deines Adapters schreibt um zB. eine Einstellung zu ändern, dann ist dieser Schreibvorgang zu ignorieren. Siehe auch Apollon77s Beitrag. Alles andere ist (von etwaigen Sonderfällen mal abgesehen) schlicht und einfach falsch.

Wenn die States eines fremden Adapters überwachst um z.B. Werte die ein anderer Adapter schreibt zu verarbeiten, dann solltest du nur Werte mit ack = true beachten.

Viele User schreiben ihre Skripts oder Blockly nicht sauber und haben demnach kein ACK true mit dabei.

Daher reagiere ich in den Fällen nicht drauf, was so absolut ok ist!

Wenn es sich um eigene States deines Adapter handelt dann ist das ja OK. Du darfst ja eben NUR mit ack=false regieren! Wenn es sich um fremde States handelt, solltes du ack=false eher ignorieren.

Nur weil User das das ack Flag falsch verwenden und zB. Einstellungen mit ack=true schrieben ist das noch kein Grund dass sich ein Adapter falsch verhält.

In jedem fall fehlt in obiger Aussage um welcghe States (die deines Adapters, welche in 0:userdate_0, etc.) es sich handelt.

[SKB]

@mcm1957 entspricht ja nicht meiner Aussage!

Eigene Adapter states werden nur mit ACK false beachtet, bei Javascript und userdatata beachte ich beides! Andere Adapter nur mit ACK true.

So, wie es richtig ist!

[mcm1957]

@skb said in Frage zu subscribeForeignStates() -> ack:

@mcm1957 entspricht ja nicht meiner Aussage!

Eigene Adapter states werden nur mit ACK false beachtet, bei Javascript und userdatata beachte ich beides! Andere Adapter nur mit ACK true.

So, wie es richtig ist!

Das ist vollkommen RICHTIG

In deinem ersten Beitrag fehlte nur ursprünglich das "eigenen" und damit entstand der Eindruck dass du Schreibvorgänge auf die eigenen States mit ack=true erwartest. Und das wäre falsch. Nach deiner obigen Korrektur ist es nun OK.

[SKB]

@mcm1957 mehr sagte ich ja oben auch nicht