NEWS
Deconz-Adapter Neustart
-
Hallo,
habe die aktuellen Versionen von ioBroker-Adapter, Deconz und Firmware installiert, und es ist immer noch so.Hier: Xiaomi Smart Switch WXKG11LM
Der ist quasi unbrauchbar, wenn ein Tastencode ein "Umschalten" eines Zustandes bewirkt...
Prinzipiell hat der ZigBee-Adapter das Problem nicht, weil er keine ButtonEvents ausgibt, sondern Press- und Release für jede Kombination erzeugt...
Aber, er läuft! -
Hallo,
habe die aktuellen Versionen von ioBroker-Adapter, Deconz und Firmware installiert, und es ist immer noch so.Hier: Xiaomi Smart Switch WXKG11LM
Der ist quasi unbrauchbar, wenn ein Tastencode ein "Umschalten" eines Zustandes bewirkt...
Prinzipiell hat der ZigBee-Adapter das Problem nicht, weil er keine ButtonEvents ausgibt, sondern Press- und Release für jede Kombination erzeugt...
Aber, er läuft! -
So hab mich damit nochmal befasst. Für euer Problem gibt es doch das Objekt lastupdated.
Berücksichtigt ihr den?
Genau so könnt ihr Letzte Änderung des states abfragen und prüfen ob das jetzt war oder schon länger her.Ich sehe hier nämlich ein Interessenkonflikt: Der Adapter ruft die Werte von deConz ab und setzt den Zeitstempel womit klar ist das der Wert noch Aktuell ist, er könnte sich in deConz ja geändert haben. Der Wert wird aber nicht neu gesetzt, das sieht man an Letzte Änderung.
Ich kann das setzen des Zeitstempels nur verhindern wenn ich den State gar nicht schreibe, damit fehlt aber auch die Kontrolle ob beim Adapter start auch wirklich der neue Wert gelesen wurde. -
-
Also,
der Datenpunkt "...29.buttonevent" wird gesetzt, wenn ich eine Taste drücke oder den Deconz-Adapter neu starte.
Dessen Eigenschaft "Zeitstempel" ist darum immer NEU.
Dessen Eigenschaft "Letzte Änderung" ist der letzte andere Tastendruck - also auch nicht auswertbar.
Der Datenpunkt "...29.lastupdated" wird ca. 4ms später gesetzt, und enthält als Eigenschaft "LetzteÄnderung" den gewünschten Wert des letzten Tastendrucks, nicht des letzten Adapter-Neustarts.Also,
in dem Trigger-Event alles in einen Timeout von ... 10ms packen und die vergangene Zeit testen.

-
Also,
der Datenpunkt "...29.buttonevent" wird gesetzt, wenn ich eine Taste drücke oder den Deconz-Adapter neu starte.
Dessen Eigenschaft "Zeitstempel" ist darum immer NEU.
Dessen Eigenschaft "Letzte Änderung" ist der letzte andere Tastendruck - also auch nicht auswertbar.
Der Datenpunkt "...29.lastupdated" wird ca. 4ms später gesetzt, und enthält als Eigenschaft "LetzteÄnderung" den gewünschten Wert des letzten Tastendrucks, nicht des letzten Adapter-Neustarts.Also,
in dem Trigger-Event alles in einen Timeout von ... 10ms packen und die vergangene Zeit testen.

@BigWumpus sagte in Deconz-Adapter Neustart:
Also,
der Datenpunkt "...29.buttonevent" wird gesetzt, wenn ich eine Taste drücke oder den Deconz-Adapter neu starte.
Dessen Eigenschaft "Zeitstempel" ist darum immer NEU.
Dessen Eigenschaft "Letzte Änderung" ist der letzte andere Tastendruck - also auch nicht auswertbar.
Der Datenpunkt "...29.lastupdated" wird ca. 4ms später gesetzt, und enthält als Eigenschaft "LetzteÄnderung" den gewünschten Wert des letzten Tastendrucks, nicht des letzten Adapter-Neustarts.Also,
in dem Trigger-Event alles in einen Timeout von ... 10ms packen und die vergangene Zeit testen.

Das funktioniert. Danke dass du die Info mit uns geteilt hast!
Eine Option in der Instanz in der man das Updaten von Schaltern (ggf. auch jeweils für Lampen und Sensoren) verhindern kann würde ich weiterhin für eleganter halten, aber so funktioniert es zumindest. Hoffentlich weiß ich in einem Jahr noch wozu der Timeout da ist. (jaja ich weiß, Kommentar ran
) -
Unter https://forum.iobroker.net/topic/8930/aufruf-deconz-adapter-testen-1-0-2/354 wurde ein Fork erzeigt welcher das Problem zumindest für Buttons beheben soll. Kann leider erst nächste Woche testen, aber ggf. auch für dich interessant @BigWumpus

