Seit der Nutzung von piVCCU in Verbindung mit HMCCU habe ich ein Problem welches mit CUL_HM so nicht bestand:
Nach einem Neustart der CCU wird bei batteriebetriebenen Homematic & HomaticIP-Geräten nicht der bisherige Gerätestatus (vor dem Reboot) angezeigt, sondern der in der CCU hinterlegte Defaultwert. Dies ist bei den von mir getesteten Geräten (HM-Sec-SC, HM-Sec-SCo, HM-SCI-3-FM) stets "closed". Bis zum nächsten zyklischen Senden des Geräts (welches bis zu 24h dauert), habe ich somit u.U. einen fehlerhaften Wert in der CCU als auch in den per HMCCU angebunden Geräten innerhalb von FHEM. Auch die Aggregation von Gerätezuständen mit HMCCU ist somit, angesichts unklarer Zustände, nicht nutzbar.
Bei per CUL_HM angebundenen Homematic-Geräten tritt dieses Verhalten nicht auf. Hier wird bei einem Reboot stets der im save-file hinterlegte Wert angezeigt.
Mir ist bekannt, dass ich im HMCCU-Device mit dem Attribut "ccuflags" und der Einstellung "noInitialUpdate" ein automatisches Updaten der Readings beim FHEM-Start verhindern kann. Dies hilft aber nur, wenn sowohl der FHEM als auch die CCU gleichzeitig neu starten. Weiterhin werden hierbei sämtliche Devices (batterie & netzbetriebene) nicht aktualisiert.
Das Problem ist im Homematic-Forum bereits mehrfach erwähnt: https://homematic-forum.de/forum/viewtopic.php?f=65&t=34753, https://homematic-forum.de/forum/viewtopic.php?f=19&t=52107, https://homematic-forum.de/forum/viewtopic.php?f=30&t=10513
Hat jemand einen Workaround für dieses Problem? Ich würde hier gerne das selbe Verhalten wie in CUL_HM vorfinden...
Bei batteriebetriebenen Geräten, genauer gesagt bei all den Sensoren und Aktoren, die nicht aktiv durch eine Zentralinstanz angesprochen und somit deren Zustände abgefragt werden können, wird es nie so sein, dass du dich mit Sicherheit darauf verlassen kannst, dass der in einer Zentraleinheit noch gespeicherter Zustand dem tatsächlichen Zustand des Sensors oder Aktors entspricht. Da helfen auch keine Workarounds.
Und ich bin der Meinung, dass bei Einsatz einer CCU und deren Einbindung in fhem die Zustände dieser beiden Instanzen gleich sein sollten. Da die CCU hier ggü. den Devices das IO mit eigener Zustandsspeicherung ist, sollte fhem auch deren Zustände übernehmen.
Das sich der Devicezustand während eines Reboots ändern kann, ist mir natürlich klar. Was mir etwas widersinnig erscheint ist, dass die CCU anstatt des gespeicherten Zustands einfach einen Defaultwert für das Device annimmt.
Aus einem vor/während/nach dem Reboot offenen Fenster wird also kurzerhand ein geschlossenes. Wenn der Status nach einem Reboot egal sein sollte, könnte man sich ja gleich auch das save-file in FHEM sparen...
Zitat von: rrr am 05 Januar 2020, 17:23:45
Das sich der Devicezustand während eines Reboots ändern kann, ist mir natürlich klar. Was mir etwas widersinnig erscheint ist, dass die CCU anstatt des gespeicherten Zustands einfach einen Defaultwert für das Device annimmt.
So ist es aber nun einmal. Und das Verhalten der CCU können nur die Entwickler der CCU-Software verändern.
Zitat
Wenn der Status nach einem Reboot egal sein sollte, könnte man sich ja gleich auch das save-file in FHEM sparen...
Nö, der Unterschied liegt ja darin, dass fhem mit bspw. CUL_HM als einzige Zentralinstanz mit Zustandsspeicherung fungiert und fhem halt so programmiert ist, dass die letzten Zustände gespeichert werden. Aber auch hier gilt, dass fhem mit CUL_HM ebenfalls nicht die meisten batteriebetriebenen Sensoren aktiv abfragen kann, weil es diese Sensoren eben nicht hergeben.
Verwendet man mehrere Instanzen mit Zustandsspeicherung, gilt es immer, die Entscheidung zu treffen, ob man die Synchronität der beiden Instanzen favorisiert und damit die Zustandsspeicherung einer CCU, der man die Kommunikation mit den eigentlichen Devices überlässt, oder die Zustandsspeicherung in fhem selbst. So oder so hat man Inkonsistenzen.
Zitat von: Ralli am 05 Januar 2020, 17:46:51
So ist es aber nun einmal. Und das Verhalten der CCU können nur die Entwickler der CCU-Software verändern.
Darum auch meine Frage nach einem Workaround.
Die meisten User werden wohl noch CUL_HM nutzen und erst, wie mir passiert, bei der Migration auf HMCCU bemerken, dass batteriebetriebene Sensoren sich anders verhalten als gewohnt.
Ich werde daher wohl notgedrungen wieder CUL_HM nutzen...
ZitatIch werde daher wohl notgedrungen wieder CUL_HM nutzen...
aus welchem grund hast du auf hmccu gewechselt?
Zitat von: rrr am 05 Januar 2020, 17:23:45
Was mir etwas widersinnig erscheint ist, dass die CCU anstatt des gespeicherten Zustands einfach einen Defaultwert für das Device annimmt.
Ein weit verbreiteter Irrglaube.
Der Zustandswert ist kein Defaultwert wie true oder false, sondern "undefiniert", also ein Leerwert (null).
.
Wenn die CCU nach einem Neustart alle Werte aktualisieren würde, müsste sie sozusagen ein Feuerwerk an Anfragen an alle Geräte auslösen (Stichwort Duty Cycle).
Die Speicherung der Werte vor dem Reboot hilft nicht, denn während dem Neustart können sich die Zustände ja ändern (jemand öffnet ein Fenster, oder ...)
Zitat von: zap am 07 Januar 2020, 08:03:21
Wenn die CCU nach einem Neustart alle Werte aktualisieren würde, müsste sie sozusagen ein Feuerwerk an Anfragen an alle Geräte auslösen (Stichwort Duty Cycle).
In FHEM geht dies mit CUL_HM aber doch auch, dass nach einem Neustart sukzessive alle netzbetriebenen HomeMatic-Geräte nach ihrem Status befragt werden.
Nichts anderes macht ja wahrscheinlich auch die CCU nach einem Neustart. Nur dass sie dies, wie auch CUL_HM, eben bei batteriebetriebenen Geräten nicht kann.
Der Unterschied liegt nur darin, dass ich bei FHEM das save-file in sehr kurzen Abständen speichern kann und somit nach einem Neustart nicht wieder mit Default (oder undefinierten) Werten arbeiten muss.
Mein Vorschlag wäre, das Attribut "noInitialUpdate" zusätzlich auf HMCCUDEV/HMCCUCHN-Devices zu übertragen. Somit kann jeder Benutzer selbst entscheiden, ob er die Werte des FHEM-Savefiles bevorzugt oder ob ihm "aktuelle" Werte der CCU lieber sind.
Zitat von: zap am 07 Januar 2020, 08:03:21
Die Speicherung der Werte vor dem Reboot hilft nicht, denn während dem Neustart können sich die Zustände ja ändern (jemand öffnet ein Fenster, oder ...)
Natürlich wäre es in vielen Fällen hilfreich, da man dann Reboots planen kann. Falls die CCU die Zustände nicht speichert, ist von einem Designfehler zu sprechen.
Zitat von: marvin78 am 20 Januar 2020, 06:42:54
Natürlich wäre es in vielen Fällen hilfreich, da man dann Reboots planen kann. Falls die CCU die Zustände nicht speichert, ist von einem Designfehler zu sprechen.
Sehe ich auch so. Und selbst wenn es kein geplanter Reboot ist, habe ich zumindest lieber den letzten Stand, als einen mit Standardwerten welche auf keinen Fall der Realität entsprechen.
wenn z.B. während des reboots ein Fenster geöffnet wird aber die CCU den letzten gespeicherten Zustand vor dem reboot "geschlossen" anzeigen würde - das wäre ein Designfehler.
Dann lieber ein undefinierter Zustand wie jetzt - bessere funktionale Sicherheit - imho.
Zitat von: Tom Major am 20 Januar 2020, 20:37:25
wenn z.B. während des reboots ein Fenster geöffnet wird aber die CCU den letzten gespeicherten Zustand vor dem reboot "geschlossen" anzeigen würde - das wäre ein Designfehler.
Dann lieber ein undefinierter Zustand wie jetzt - bessere funktionale Sicherheit - imho.
Genau so ist es aber, wenn Du CUL_HM verwendest. Es wird einfach der Stand aus dem save-file genommen, bis ein batteriebetriebener Sender etwas neues meldet.
Daher ja mein Vorschlag das "noInitialUpdate"-Attribut auf Geräte/Kanal-Ebene auszuweiten. So kann jeder entscheiden was er lieber möchte...
Zitat von: Tom Major am 20 Januar 2020, 20:37:25
wenn z.B. während des reboots ein Fenster geöffnet wird aber die CCU den letzten gespeicherten Zustand vor dem reboot "geschlossen" anzeigen würde - das wäre ein Designfehler.
Dann lieber ein undefinierter Zustand wie jetzt - bessere funktionale Sicherheit - imho.
Mit "Sicherheit" hat das ganze ohnehin nichts zu tun.
Zitat von: rrr am 20 Januar 2020, 21:57:45
Genau so ist es aber, wenn Du CUL_HM verwendest. Es wird einfach der Stand aus dem save-file genommen, bis ein batteriebetriebener Sender etwas neues meldet.
Sicherheitskritisch sind für mich Fensterkontakte, Bewegungsmelder und Rauchmelder. Optische Fensterkontakte melden fast stündlich ihren Status, da kann man also drauf fast warten dass das von allein aktuell wird. Bewegungsmelder senden bei jeder sicherheitsrelevanten motion ohnehin neu, und Rauchmelder lassen sich per statusRequest abfragen.
Hier hatte doch neulich jemand beängstigt gefragt, warum alle seine Geräte "dead" sind, weil er ein veraltetes statefile beim Restore einspielen musste. Das hat sich quasi von allein alles wieder glatt gezogen.
Wenn eine CCU wirklich "undefined" annimmt, ist das kein schlechter Workaround. Ein frisches statefile, was also unmittelbar vor einem reboot geschrieben wurde, dürfte noch hinreichend aktuell sein (sofern reboots nicht ständig im laufenden Betrieb passieren - bei mir ist das in einer Wartungsphase, da bin ich zu Hause und es ist sicherheitstechnisch völlig Jacke, wenn in der Zeit ein Fenster auf oder zu geht).
Veraltete statefiles sollte FHEM eher verwerfen. Dann lieber "undefined". Allerdings beinhaltet ein state file auch nicht nur den allerletzten Zustand. Ist also ... schwierig.
Zitat von: Pfriemler am 21 Januar 2020, 15:55:25
Wenn eine CCU wirklich "undefined" annimmt, ist das kein schlechter Workaround.
Ich hatte hier einmal etwas darüber geschrieben:
https://homematic-forum.de/forum/viewtopic.php?f=26&t=28562&p=255398&hilit=undefiniert+badenpower#p255345
Allerdings habe ich dies aktuell nicht mehr getestet und nach nochmaligem durchlesen habe ich mittlerweile vage im Hinterkopf, dass sich an der Zustanddefinition von Aktoren nach dem CCU-Reboot im Zuge der Firmwareaktuallisierungen irgendwann etwas geändert hatte.
Wenn ich die Zeit finde, dann werde ich einmal ein paar Tests vornehmen.
.