Hallo Andre,
ich hatte nochmal den Fall, dass bei einem FHEM Neustart ein alter Tastendruck eines Zigbee Tasters als "neues Event" gewertet wurde und das SmartHome sich "verselbstständigt" hat.
Dürfte irgendwas mit der Zeitumstellung zu tun gehabt haben.
Ich hab wohl mittlerweile ein AT, welches das State-File zyklisch sichert, aber der Neustart den ich wöchentlich Nachts durchführen lasse war zufällig zu nah an der Zeitumstellung.
Dadurch scheint die Kombination Conbee2/Deconz und FHEM wohl der Meinung gewesen zu sein, dass das Event noch unbekannt war.
Da das Ganze immer noch seltene Randerscheinungen bleiben dürften, ein Wunsch / Vorschlag um das relativ unkompliziert zu umgehen (siehe dein Zitat unten):
Einfach ein Attribut, welches man den HUEDevices verpassen kann, mit dem man sagt "Du bist ein Device welches Events bekommt und somit nicht Pollen muss und im aktuellen Fall auch nicht Pollen soll".
Das könnte man dann z.B. Tastern zuweisen, Thermometern dafür nicht.
So kann der User das sauber bestimmen wenn er sich die Mühe machen will.
Das HUEBridge Modul muss es aber nicht selbstständig herausfinden (was wie von dir gut beschrieben ja nicht wirklich klappen kann).
Wenn man es noch feiner bestimmen will, könnte das Attribut auch eine Liste von Readings aufnehmen welche nicht gepollt werden sollen.
Dann könnte man battery etc. noch weiter zyklisch abholen lassen.
Aber darf auch gern die einfachere Version sein, wer weiß wer das außer mir jemals nutzen wird.
das ist im prinzip möglich. betrifft aber so auch alle anderen dinge die sich auf den vergleich mit einem vorherigen zustand (z.b. über OldReadingsVal) verlassen. wenn der alte zustand nicht zuverlässig ist gibt es ein problem.
dazu gibt es mehrere mögliche lösungen, die alle ebenfalls irgendwelche nachteile haben:
- nach einem neustart wird grundsätzlich die erste zustandsänderung ignoriert -> es gehen möglicherweise
zustände verloren
- nach einem neustart werden grundsätzlich die ersten daten die durch pollen rein kommen ignoriert
das geht nur auf systeme bei denen die bridge auch events sendet.
- für sensoren grundsätzlich nicht mehr pollen wenn es events gibt. geht nur wenn es (zuverlässige) events
gibt und das weiss ich eigentlich erst nach dem das erste event gekommen ist. wie merke ich mir das wenn
ich mich nicht darauf verlassen kann das die readings nach dem neustart stimmen?
- man baut irgendwelche höchstalter für die daten ein. problem: wie alt ist alt genug zum ignorieren?
die frage ist halt: was ist wichtiger, das der interne zustand nach einem neustart so schnell wie möglich stimmt und eventuell events doppelt kommen oder das niemals falsch ausgelöst wird und eventuell events verloren gehen. eventuell ist je nach sensor typ das eine oder das andere besser.
wie wäre ein attribut mit dem man 1., 2. oder 3. von oben und zusätzlich 4. konfigurieren kann?
ganz unabhängig davon eine geschichte: vor ein paar wochen hat der rollladen hier im schlafzimmer angefangen zu spinnen und ist mitten in der nacht mehrfach auf oder zu gefahren. nach langem suchen habe ich dann eine tablet ui installation an der wand als verantwortlichen gefunden. irgend ein netzwerk problem hat dazu geführt das das ding der meinung war jemand hat es von hand bedient.
