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

[paul53]

@selector sagte: Hat jemand ne Idee wo mein Denkfehler ist?

Der Adapter bestätigt nach Ausführung das Kommando.
Wenn du im Trigger "ack: true" weg lässt, wirst du sehen, dass erst unbestätigt getriggert wird.

@selector sagte in setState()-Aufrufe haben immer ack == true:

Wenn der Schalter per Hardware geschaltet wird, muss der Modus in VIS aktualisiert werden, bei Aktualisierungen durch VIS bzw das Script soll der Modus nicht geändert werden.

Dann ändere den Trigger auf change: 'ne'.

[haus-automatisierung]

@selector sagte in setState()-Aufrufe haben immer ack == true:

Läuft da was falsch, oder habe ich da ein Verständnisproblem zu der Funktion? Die Doku finde ich da nicht sehr aufschlussreich.

Eventuell hilft Dir die Erklärung ja: https://www.youtube.com/watch?v=p5FyeifYUnw

[ticaki]

@paul53

müsste man da nicht noch zusätzlich auf from testen?

[paul53]

@ticaki sagte: müsste man da nicht noch zusätzlich auf from testen?

Kann man, aber

on({id: 'zigbee.0.dc8e95fffe15d81a.state', ack: true, change: 'ne'}

sollte ausreichen, da bei Bestätigung der Änderung aus Vis oder Javascript keine Wertänderung erfolgt, denn diese erfolgte vorher unbestätigt.

[haus-automatisierung]

@ticaki sagte in setState()-Aufrufe haben immer ack == true:

müsste man da nicht noch zusätzlich auf from testen?

from wird in diesem Fall immer zigbee.0 sein (für bestätigte Werte). Und javascript.0 für unbestätigte Werte. Es kommt also stark drauf an, was genau man eigentlich wissen möchte und wann man eine Aktion auslösen will.

In diesem Fall sollte man die Darstellung in VIS wohl nur dann "nachziehen", wenn die Aktion auch wirklich ausgeführt wurde (= bestätigt ist). Und nicht dann, wenn die Aktion angestoßen wurde.

PS: Eigene Datenpunkte sollte man bestätigt setzen. Also

setState('0_userdata.0.rooms.bathroom.mirrow_state', 'ON', true);

Den Vergleich mit true kann man sich schenken:

    if (obj.state.val) {
        setState('0_userdata.0.rooms.bathroom.mirrow_state', 'ON', true);
    } else {
        setState('0_userdata.0.rooms.bathroom.mirrow_state', 'OFF', true);
    }

Und dann könnte man das auch komplett kürzen:

setState('0_userdata.0.rooms.bathroom.mirrow_state', obj.state.val ? 'ON' : 'OFF', true);

[selector]

Erstmal danke für die Posts,

@paul53 said in setState()-Aufrufe haben immer ack == true:

sollte ausreichen, da bei Bestätigung der Änderung aus Vis oder Javascript keine Wertänderung erfolgt, denn diese erfolgte vorher unbestätigt.

das war auch meine Annahme.

@paul53

Auch das hatte ich schon ausprobiert. Es wird aber immer mit ack=true bestätigt, egal ob ich

setState([object-path], true) oder
setState([object-path], true, false) oder
setState([object-path], true, false, ()=>{})

aufrufe.

Den Trigger auf 'ne' Ändern hilft, nicht, das bestimmt ja nur ob der Event-Handler nur aufgerufen wird, wenn eine Änderung zum Vor-Zustand erfolgt. Das kann bei mir sowohl durch den Manuellen Taster, als auch durch VIS sein.

from ist, wie @haus-automatisierung schon gesagt hat, immer gleich.

PS: Eigene Datenpunkte sollte man bestätigt setzen. Also

Warum sollten die immer bestätigt gesetzt werden? Ich hätte jetzt gedacht, dass man über das ack-Flag nur steuert, ob der dahinterliegende Event-Mechanismus getriggert wird. Aber ich gucke mir jetzt erstmal das verlinkte Video an. Danke für den Link.

[ticaki]

@haus-automatisierung

Mein Gedanke dabei war das man von zigbee.0 nur change: 'ne' bekommt, wenn die Änderung von einem Zigbeegerät angestossen wurde. (z.B. Relais ähnlich shelly 1)

Edit: Beispiel geändert

[paul53]

@ticaki sagte: von zigbee.0 nur change: 'ne' bekommt, wenn die Änderung von einem Zigbeegerät angestossen wurde. (taster, schalter usw)

... zusammen mit Bestätigung. Wenn die Änderung per Javascript, Vis oder Admin erfolgt, bekommt man auch change: 'ne' von "zigbee.0", aber unbestätigt.

[selector]

ok, danke, ich weiß jetzt was mein Denkfehler war und warum eigene Datenpunkt im Gegensatz von Datenpunkten von Adaptern Bestätigt gesetzt werden sollten, das Video hat mir geholfen und. Problem war

1. Ich setze den Datenpunkt unbestätigt
2. Der Zigbee-Adapter nimmt das zum anlass den Schalter zu schalten
3. und sendet ein bestätigtes Event, welches ich dann abgefangen habe

[ticaki]

@paul53

change: 'ne' löst nur aus wenn sich der Wert ändert .

"ne" (not equal) New value must be not equal to the old one (state.val != oldState.val) If pattern is id-string this value is used by default

und nur durch das bestätigen ändert sich ja nicht der Wert... oder hat sich da was geändert?

[paul53]

@ticaki sagte: und nur durch das bestätigen ändert sich ja nicht der Wert...

Das war meine Aussage. Nur, wenn sich der Wert durch manuelle Betätigung vor Ort ändert, kommen change: 'ne', ack: true von "zigbee.0" gleichzeitig.

[paul53]

@ticaki sagte: müsste man da nicht noch zusätzlich auf from testen?

Will man nur eine Trigger-Schleife verhindern, sollte man from testen:

on({id: 'zigbee.0.dc8e95fffe15d81a.state', change: 'ne', fromNe: 'system.adapter.javascript.0'}, function (obj) {
    console.log('manual mirrow state change to: ' + obj.state.val)
    console.log(obj)
    setState('0_userdata.0.rooms.bathroom.mirrow_state', obj.state.val ? 'ON' : 'OFF', true);
});

EDIT: So kommt auch eine Änderung per Admin (Tab "Objekte") in der Visualisierung an.

[ticaki]

@paul53
Jetzt passt es, habs dann wohl falsch gelesen. Ich benutze from/fromNe im Kontext von Shellys um Automatismen zu deaktivieren.

[selector]

@paul53 said in setState()-Aufrufe haben immer ack == true:

@ticaki sagte: und nur durch das bestätigen ändert sich ja nicht der Wert...

Das war meine Aussage. Nur, wenn sich der Wert durch manuelle Betätigung vor Ort ändert, kommen change: 'ne', ack: true von "zigbee.0" gleichzeitig.

Ja, danke nochmal. Auch das ist korrekt, da hatte ich auch erst einen Denkfehler.