Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Codierknecht]

@hrobnik sagte in Gerät per Rest-Call steuern:

Wie kann ich (im Skript?) dem State mitteilen, daß die Zustandsänderung korrekt verarbeitet wurde? (Oder mache ich grundlegend etwas falsch?)

Zeig doch mal Dein Script.
Um einen State mit ACK-Flag zu setzen, muss der dritte (optionale) Parameter auf true gesetzt sein.

setState(id, value, true);

[hrobnik]

@Codierknecht sagte in Gerät per Rest-Call steuern:

Zeig doch mal Dein Script.
Um einen State mit ACK-Flag zu setzen, muss der dritte (optionale) Parameter auf true gesetzt sein.

setState(id, value, true);

Danke für die schnelle Antwort! Den State setze ich per iQontrol, nicht per setState(). (Andere States von z. B. shelly, die ich per iQontrol setze, zeigen das Verhalten nicht.)

const ids = {
    id: [ prefix + 'x', prefix + 'y' ]
}

on(ids, (data) => {
    let id = data.id.split('.')
    let name = id[id.length - 1]
    console.log(name);
    console.log(data.state.val)
    switchState(name, data.state.val)
})

switchState() setzt den HTTP-Request per httpGet() ab.

[hrobnik]

Verstehe ich Dich dahingehend richtig, daß das Skript den Wert (redundant) mit setState(., ., true) setzen sollte, damit der Wert "confirmed" ist?

Edit: sollte es definitiv nicht, das führt zu eine Endlosschleife...

[Codierknecht]

@hrobnik sagte in Gerät per Rest-Call steuern:

Andere States von z. B. shelly, die ich per iQontrol setze, zeigen das Verhalten nicht.

Was sind das denn für "andere States"?
Welche von Adaptern? Bei denen wäre das das übliche Verhalten. States von Adaptern dürfen nicht mit ACK gesetzt werden, weil das für den Adapter der Anlass ist, überhaupt etwas zu tun. Hat er das erledigt, setzt der Adapter das ACK Flag.
Bei eigenen States ist das aber auch völlig normal. Eine Vis (wie z.B. iQontrol) weiß ja nicht, ob es ein selbst definierter State ist, bei dem sie das ACK Flag gleich setzen könnte.

Verstehe ich Dich dahingehend richtig, daß das Skript den Wert (redundant) mit setState(., ., true) setzen sollte, damit der Wert "confirmed" ist?

Das könntest Du machen. Nachdem Du mit switchState() den Request verarbeitet hast, könntest Du den gleichen Wert manuell erneut setzen.

Edit: sollte es definitiv nicht, das führt zu eine Endlosschleife...

Das kommt dadurch, dass Du auf jede Aktualisierung triggerst.
Wenn Du das änderst und nur auf Änderungen triggerst, sollte das funktionieren.

on({ id: ids, change: 'ne' }, function() {
});

[paul53]

@hrobnik sagte: switchState() setzt den HTTP-Request per httpGet() ab.

Funktion zeigen! Ist sie Teil des Skripts?

[hrobnik]

Kaum macht man es richtig, schon geht es.

@codierknecht Nach Deinen Erläuterungen habe ich mich für den Filter ack: false entschieden (analog zu den Adaptern) und setze das im Skript mit true. Jetzt verhält sich auch iQontrol wie erwartet.

Vielen Dank für Deine schnelle Unterstützung.

[hrobnik]

@paul53 Ja, sie ist Teil des Skripts, aber nicht Teil des Problems.

[Codierknecht]

@paul53
Das Verhalten in iQontrol lässt sich auch ohne jegliches Script leicht nachstellen.
Jeder User-State verhält sich wie oben beschrieben. States der Adapter zeigen das Verhalten nicht. Da setzt der Adapter ja nach erfolgter Änderung das ACK Flag.

@hrobnik
Vielleicht kann man das in iQontrol auch so einstellen, dass iQontrol das ACK Flag setzt. Aber im Detail habe ich mich mit iQontrol nicht beschäftigt.

[paul53]

@Codierknecht sagte: Da setzt der Adapter ja nach erfolgter Änderung das ACK Flag.

Ich würde Ack aus der Callback-Funktion von httpGet() setzen, wenn kein Fehler zurück gemeldet wird.

        if (!err) setState(dp.id, dp.state.val, true); // Bestätigung

[hrobnik]

@Codierknecht sagte in Gelöst: Gerät per Rest-Call steuern:

Vielleicht kann man das in iQontrol auch so einstellen, dass iQontrol das ACK Flag setzt.

Dein ursprünglicher Vorschlag gefällt mir besser, insbesondere mit @paul53 s Vorschlag. Dann verhält sich das Skript wie ein "richtiger" Adapter.