NEWS
Deconz-Adapter Neustart
-
Hallo,
ich habe das Gefühl, daß der Deconz-Adapter bei einem Neustart die aktuellen Zustände eines Switch als "neu" verkauft. Also der letzte Tastendruck (1x, 2x, 3x, 4x) wird wieder aktuell gemledet, was bei Ein/Aus echt Mist ist…
-
Ja der Adapter setzt die Zustände beim Neustart neu.
Mal sehen ob ich das ändern kann, aber ich hab definitiv erst ab Dezember wieder Zeit.
Gesendet von meinem m8 mit Tapatalk
-
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! -
@BigWumpus
Hab das auch letztens angemerkt. @Jey-Cee will sich das Mal anschauen wenn er Zeit hat. Dezember wurde ja anscheinend nichts. Aber ich bin optimistisch. -
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. -
Ein Möglichkeit wäre das Prüfen, ob der alte Wert != neuer Wert ist und nur dann den neuen Wert zu schreiben.
Man könnte stattdessen/auch das Schreiben von Werten zumindest für Schalter unterbinden.Wären das mögliche Lösungsansätze?
-
Bei meinem gestrige Versuch wurde LastUpdated immer auf die aktuelle Zeit gesetzt...
-
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