HMCCUCHN / HMCCUDEV wechseln kurzzeitig den state auf Initalized bei FHEM-Reboot

[rrr]

Nach dem Neustart des FHEM-Servers steht der state bei sämtlichen HMCCUCHN / HMCCUDEV Geräten kurzzeitig auf "Initialized", bevor er dann auf den korrekten Wert wechselt. (Bei einem HM-Sec-SC bspw. auf "closed" bzw. "open".)

Dadurch wird natürlich ein unnötiges Event erzeugt, welches auch sämtliche Notifys und DOIFs durcheinanderbringt.
Nebenbei kann bspw. auch nicht mehr die korrekte Zeit seit dem letzten Zustandswechsel eines Fensters erfasst werden.

Warum nimmt das Gerät sich bei einem FHEM-Neustart nicht den Wert aus dem statefile, wie es auch bei per CUL_HM angebundenen HomeMatic Geräten der Fall ist?

Kann ich das irgendwie ändern??

[zap]

Du kannst es nicht ändern, aber ich. Möglicherweise sogar kurzfristig

[marvin78]

Ich bin dafür.

[rrr]

Das wäre echt super, wenn Du das kurzfristig ändern könntest...

[Grimmschak]

oh, dem Wunsch schließ ich mich auf jeden Fall an....

[eurofinder]

+1

eurofinder

[rrr]

Du kannst es nicht ändern, aber ich. Möglicherweise sogar kurzfristig

Weisst Du schon, wann Du das Update bereitstellen kannst?
Ich habe das state-Problem leider erst mitten in der Migration von CUL_HM zu HMCCU bemerkt. Ich würde aber auch ungern wieder zurück wechseln...

Im Übrigen wechseln sämtliche Readings eines HMCCUDEV/HMCCUCHN Devices bei einem Neustart zuerst auf "Initalized".
Es wäre gut wenn sämtliche Readings ihre alten Werte und Timestamps beibehalten, sofern diese keinen aktuelleren abweichenden Wert haben.

[zap]

Das nächste Update wird die 4.4 und bringt zumindest intern einige Veränderungen mit. Das erfordert etwas umfangreichere Tests als sonst. Aber ich sag mal: entweder ed klappt diese Woche oder es dauert noch. Ab nächste Woche ist der Urlaub zu Ende und ich habe wieder weniger Zeit dafür.

[rrr]

Hast Du den Part welches das Reading-Problem betrifft, denn schon fertig und könntest Ihn zum testen zur Verfügung stellen?

Ich hab probeweise mal die Zeile "readingsSingleUpdate ($dev_hash, "state", "Initialized", 1);" auskommentiert. So wird zwar der Initialized Status verhindert, aber kurz danach erhalten die Readings dennoch einen neuen Timestamp.

[zap]

Die Zeile ist schon mal korrekt. Du musst aber zumindest im IO Device im Attribut ccuflags das Flag noInitialUpdate setzen. Das verhindert, dass nach dem Start vom RPC Server alle Devices aktualisiert werden.

[rrr]

Das Flag noInitialUpdate hab ich auch schon gesetzt. Jedoch werden dadurch auch Änderungen welche während des FHEM-Ausfalls / Reboots stattfinden, nicht in FHEM aktualisiert...
Das Modul müsste beim Start vergleichen, ob die Werte sich geändert haben, und nur dann ein Update ausführen.

[frank]

wenn du das attr timestamp-on-change-reading setzt, zb ".*" für alle readings, sollten die timestamps nur aktualisieren, wenn sich der value ändert.

[rrr]

Das habe ich auch bereits gesetzt. Dadurch kommen aber dennoch (kurz nach dem Reboot) Readings durch, welche im Attribut "event-min-interval" vorkommen. Aber das wäre ja noch zu verschmerzen.

Weiterhin helfen alle diese Maßnahmen (entfernen der "readingsSingleUpdate"-Zeile und setzen des Flags "noInitialUpdate") nicht, wenn der Rechner auf welchem sowohl FHEM als auch die piVCCU laufen, rebootet wird.
Dann bleiben sämtliche HMCCUDEV/HMCCUCHN-Devices auf "Pending" stehen (RPC-Server läuft selbstverständlich). So ist eine produktive Nutzung des HMCCU-Moduls leider nicht möglich...

[zap]

Also ich nutze es produktiv, insofern scheint es doch irgendwie zu funktionieren.

Pending heißt, dass eine verpätete Initialisierung stattfindet. Das ist der Nachteil, wenn CCU und FHEM auf dem gleichen Rechner laufen bei einem Reboot ist FHEM viel schneller wieder da als die CCU. Daher muss HMCCU auf die CCU warten. Während dieser Zeit gehemmdie Devices auf pending.

[rrr]

Also bei mir bleibt der state dauerhaft auf "Pending" stehen (kann jetzt aber auch sein weil, ich die besagte "Initialized"-Zeile entfernt habe).

Solche Angaben wie "Pending","Initialized", usw. gehören aber nicht in das state-Reading bzw. STATE-Internal eines einzelnen Devices/Kanals.
Wenn ich wissen möchte, ob das Interface (in diesem Fall die VCCU) nicht läuft, dann schau in in deren State.
Von mir aus kann man das, falls gewünscht, in den hmstate eines einzelnen Devices/Kanals mit reinbauen. Aber man kann doch keinem User zumuten, sämtliche Routinen anzupassen um Unpässlichkeiten des Interfaces abzufangen.