HMCCU: Nach Update RaspberryMatic und Neustart der HMCCU Prozesse FM auf CCU

[isy]

Hallo zusammen,
nach Update RaspberryMatic auf die Versionn 3.63.8.20220330 und Neustart FHEM per shutdown/restart oder Neustart der RPC Prozesse über HMCCU gibt es eine FM auf CCU für jedes Gerät: "Gerätekommunikation gestört". Diese FM verschwinden nach und nach, jedoch nicht bei allen Geräte von selbst, sondern z.B. auch nach Auslösung einer Aktion oder eben gar nicht. Besonderheiten an den Geräten sehe ich nicht. Die FM lassen sich auf der CCU nicht bestätigen (grau).

Siehe auch Timeout FM in FHEM Log (letzte Zeile)

Diese CCU Fehlermeldungen treten nur auf, wenn ich in FHEM die RPC Server oder FHEM neu starte. Also ohne FHEM Verbindung, keine Fehler auf der CCU.
Daher habe ich hier im Forum das Problem beschrieben.

RaspberryMatic läuft auf einem PI3 mit SD-Karte, Auslastung aktuell mit laufenden RPC-Server 4% Duty Cycle (ich habe nur 5 Geräte mit HM-IP, kein BidCos, sonst aber eher 0%).
In FHEM läuft HMCCU 5.0 220431743

FHEM und RaspberryMatic Log-Auszüge in der Anlage.

VG Helmut

[juemuc]

Hallo,

da dies Fehlermeldungen der CCU sind, hat dies aus meiner Sicht nichts mit FHEM zu tun. Diese werden halt nach FHEM übergeben. Du musst somit das Problem mit der CCU lösen.

Viele Grüße
Jürgen

[isy]

Wie ich feststellte, entstehen die Meldungen "Kommunikationsfehler" mit dem Start der Fhem RPC Prozesse. Im CCU Log stehen haufenweise RPC bedingte Fehlermeldungen.

Daher denke ich, könnte das Problem in FHEM liegen.

[isy]

Habe mir heute morgen noch die CCU angeschaut. RPC-Server 0% Duty Cycle und keine Fehler mehr im Log.
Daraus schließe ich, dass die Kommunikationsfehler nach dem FW Update nicht an der aktuellen Version liegen, sondern eher im Startup-Prozess nach FW Update o.ä der CCU.
Ich habe mal eine schnelle microSDHC bestellt. Beim Update meldet die CCU einen Performanceengpass auf der SD-Karte. Vielleicht liegt die Situation darin begründet.

[Rewe2000]

Hallo Helmut,

ich hatte vor einigen Monaten ähnliche Probleme beim Neustart von Fhem, auch bei mir brachten viele Geräte auf der CCU Kommunikationsstörungen. Komischerweise konnte ich nie ermitteln woran das genau lag, bei mir half ein "noInitialUpdate" bei den RPC-Servern.

Einen Versuch wäre es wert: https://forum.fhem.de/index.php/topic,98287.msg948106.html#msg948106
Nach einem Neustart von Fhem dauert es dann einige Stunden bis alle Zustände in Fhem wieder passen, ich konne damals damit leben, zumindest konnte ich Fhem wieder problemlos starten.
Aktuell benötige ich "noInitialUpdate" nicht mehr, Fhem startet seit der HMCCU Version 5.0 bei mir wieder so wie es soll.

Mehr zu dem bei dir beschriebenen Fehler kann da sicherlich zap dazu beisteuer.

Gruß Reinhard

[isy]

Hallo Reinhard,
das ist eine wertvolle Info, Danke dafür. Auch der verlinkte Thread liest sich spannend.
Ich bleibe da auf alle Fälle dran und schaue mal, was die schnelle microSD verändert (wenn überhaupt....)

Meine (eher geratenen) Vermutungen:
- Performanceprobleme auf der CCU durch "Aufräumen" nach FW Update und langsamer SD-Karte.
- Performanceprobleme auf der CCU durch Start der FHEM RPC-Prozesse, womöglich mit höchster Prio auf der CCU und "Abhängen" der HM Devices
- Verändertes Timing der neuen CCU Version.

Viele Grüße und einen schönen Sonntag,
Helmut

[isy]

Hallo zusammen,
heute kam die neue SD-Karte Extreme U3 an Stelle einer alten Ultra.
Kurz: Bringt nichts am Raspi 3.
Nach Start der FHEM RPC Prozesse gehen alle CCU Devices auf "Gerätekommunikation gestört".
Gut, das Thema verschwindet nach einiger Zeit, aber schön ist das nicht.

Das Attribut "noInitialUpdate" finde ich im Umfeld der HMCCU-5.0 220431743 Implementierung  (also in der CCU Def bzw. den RPC Defs) nicht.

[Rewe2000]

Hallo Helmut,

guck mal unter dem Attribut ccuflags, hier kannst du zusätzlich noch einen Haken bei noInitialUpdate setzen.
Ich hatte dies bei HMCCU und allen RPC-Devices gesetzt.

Sollten die Fehler verschwunden sein, so dauert es halt nach einem Neustart einige Stunden, bis alle Zustände der HM und HMIP Geräte wieder aktualisiert werden. Ändert sich jedoch der Zustand am Device, so wird natürlich sofort aktualisiert.
Es könnte nur Probleme geben, wenn jemand während des Neustarts ein Fenster öffnet, Fhem meint dann es wäre geschlossen, bis sich das Gerät mit dem aktuellen Zustand turnusgemäß wieder bei CCUx meldet, passt dann der Zustand nicht.

Viel Erfolg
Gruß Reinhard

[isy]

Hallo Reinhard,
ich habe die Settings entsprechend angepasst.
HMCCU per "Off" beendet und die CCU neu gestartet.
Es gibt keine Kommunikationsfehler und alle Devices funktionieren, ohne dass ich das tiefer getestet habe, wie gewohnt.
FHEM fragt jedoch die Devices nicht mehr ab. Das konnte man bisher an den aktualisierten Readings sehen, die jetzt fehlen zum Neustart.

Also erstmal ist Ruhe auf der CCU evtl. findet Zap eine bessere Lösung

Vielen Dank für den Tipp,
Helmut

[Rewe2000]

Hallo Helmut,

es freut mich, dass bei die der Neustart wieder fehlerfrei funktioniert.
Ich kämpfte vor einigen Jahren mit dem gleichen Problem, selbst ein Umzug von CCU2 auf Raspberrymatic (CCU3) hat das Problem nicht beseitigt. Erst vor einigen Wochen habe ich bei mir das "noInitialUpdate" (nach dem Update auf HMCCU 5.0), aus den ccuflags wieder entfernt (bei HMCCU und allen RPC-Servern) mein Fhem startet nun wieder ohne Probleme.
Auch zap hatte sich seinerzeit bemüht bei mir und noch einem User den Grund zu finden, leider erfolglos. Hoffentlich hast du mehr Erfolg die Ursache hierfür zu finden, ich hatte damals immer schweißnasse Hände, wenn ich einen Neustart von Fhem ausführen sollte.

Das mit dem verspäteten Aktualisieren der Devices war für mich nicht das große Problem, den bei der nächsten geplanten Funk-Sendung passt ja der Zustand wieder, das sind bei Energiezählern nur einige Minuten, bei Rauchmeldern aber natürlich einige Stunden. In jedem Fall sollte aber bei Statusänderung der Devices sofort eine Aktualisierung erfolgen, so war es zumindes bei meinen Fenstrekontakten.

Viel Erfolg
Gruß Reinhard

[isy]

Hallo Reinhard,
ja, dein Tipp hat funktioniert. Super.

Ich bin mir gar nicht sicher, ob das Problem schon immer auftrat, oder erst nach dem Versionswechsel. Ich habe halt nie darauf geachtet.
Mal abwarten!

VG Helmut

[Rewe2000]

Hallo,

jetzt bin ich auch wieder unter den "Glücklichen", ein Neustart der Raspberrymatic und Fhem bringt über 20 nicht erreichbare Device.
Ich setze jetzt mal lieber wieder noInitialUpdate bei den ccuflags, damit mein System zumindest wieder nach einem Spannungsausfall hochfährt, sollte ich mal nicht in der Nähe sein. Lieber verzichte ich auf aktuelle Zustände direkt nach dem Neustart.
Keine Ahnung weshalb dies nur bei sehr wenigen Usern auftritt.

Gruß Reinhard

[isy]

Hallo Reinhard,
Ja, dad bleibt  ein  seltsames Verhalten.
Aber dein Tipp funktioniert, ich habe das attr drin gelassen bis heute