DutyCycle-Probleme mit HMIP nach Blackout

[hubbel]

Guten Abend zusammen,

ich betreibe mein HM Setup nun seit einigen Jahren zufrieden mit raspberrymatic auf aktuell einem RPI3, an sich für mich ein optimales Setup. Meine Programme habe ich weitestgehend optimiert und diverse Loggings/Monitorings auf meine Systemwerte/Dutycycle mit Grafana & Co.

Im letzten Jahr kam es jedoch zu 3 verherenden Ausfällen ( 2 x Stromausfall, nun mit USV mitigiert, 1 x USB-Reset), bei denen meine Zentrale verrücktgespielt hat - zuletzt gestern. Ich hatte versehentlich mein RPI vom USB-Kabel getrennt, wodurch die Zentrale komplett neu gestartet wurde.
Nach dem Neustart waren lediglich HM Geräte erreichbar(ohne Probleme!), HM-IP nicht - der DutyCycle stieg nach und nach auf 99% und blieb auch über mehrere Stunden bei 99%. Ich kannte dieses Verhalten bereits von den letzten 2 Ausfällen, bei denen ich verzeifelt eine Lösung gesucht hatte (debug Logging, DC/CS monitoren, Zentrale restarten, Backup einspielen, neues Funkmodul einbauen, neues RASPI-Board, andere HW). Dieses mal habe ich zusätzlich den nano-cul am Start gehabt, um auffällige Telegramme zu finden - doch auch dort war an sich kaum etwas zu erkennen - die HM-IP Geräte haben Telegrame versendet, die Zentrale auch. Alle HM-IP Geräte haben an ihrer LED orange geleuchtet, auch wenn die Zentrale gerade neu gestartet und der DC unter 10 war.

Die einzige "Lösung" war in allen 3 Fällen das Herausnehmen der Batterien / Resetten der 230V Geräte - war die Batterie nur kurz raus, haben die Geräte sofort wieder funktioniert. Das mag bei 3-4 Geräten machbar sein, aber jenseits der 20-30 bzw bei mir 89 Geräte ist das weniger lustig.

Meine Frage: Bin ich ein Sonderfall oder gibt es dieses Problem noch unter einem aktuellen System mit gleichen Auswirkungen bei anderen Nutzern? Habe ich etwas übersehen oder gibt es eine Fehlkonfiguration? Was könnte ich noch tun, um in einem nächsten Ausfall ggf. eine Lösung zu identifizieren?


HW: RPI3+HM-MOD-RPI
OS: raspberrymatic
Firmware: 3.59.6.20211009
Addons: Historian, Cux, XML-API
Geräte: 89 Devices

Vielen Dank vorab an alle!

Gruß,
Daniel

[MichaelN]

Ich kann mir vorstellen, dass eine ungeschickte Programmierung beim CCU Start zu starker Aktivität führt.Ich würde mal alle Programme deaktivieren und dann die CCU neu starten. Dazu wäre es gut zu wissen, ob das Problem auch bei einem regulären Neustart auftritt oder nur beim harten Reset.

[hubbel]

Guten Abend,

das hatte ich vergessen - schon beim letzten Ausfall hatte ich nach dem der Restore eines Backups nicht geholfen hat, alle Programme deaktiviert.
Es sind sehr sicher nicht die Programme (ich weiß, ungeschickte Programme könnten soetwas verursachen - aber auch nicht über diese Zeitspanne, wenn man nicht einen ganz groben Schnitzer drin hat).

Das Problem trat bisher nur auf, wenn die Stromversorgung gekappt wurde - ein regulärer Restart / Software-Update macht keine Probleme.
Der nano-cul bzw asksin hatte ich auch während des Neustarts der Zentrale laufen - keine auffälligen Geräte.

Mir kam es persönlich so vor, als hätte es etwas mit der verschlüsselten Kommunikation zu tun - als könnten die Geräte bis zu einem "Neustart/Batterie-herausnehmen" nicht mit einem alten Key mit der Zentrale kommunieren.

Ich habe auch jetzt noch 6-7 Geräte, welche nicht mit der Zentrale kommunizeren können, da ich die Batterie nicht entfernt habe (6 Rauchmelder, 1 WTH Thermostat, 1 x SChließkontakt). Der Wand-Thermostat hat eine Kommunikationsstörung, DC liegt bei 12%, alle anderen Geräte sind erreichbar (8 weitere Wand-Thermostate) - würde ich die Batterie nun herausnehmen, funktioniert dieser wieder zu 99%... Bin wirklich ratlos.

[hubbel]

Guten Abend,

aktuell wieder die gleiche Symptomatik nach einem regulärem Patch auf 3.61.5.20211113 (raspimatic-update über die Einstellungen).
Aktuell nur Homematic-Geräte erreichbar, alle HM-IP Geräte sind nicht mehr anwählbar.

Dutycycle steigt und steigt. Habe jetzt eine orignal CCU3 bestellt und hoffe damit weniger Ärger zu haben, wie mit dem raspberry.
=> Wie gesagt, die HW des Raspberry wurde mehrfach getauscht, weshalb ich auch nicht all zu viel Hoffnug mit der CCU3 habe.

Hat noch wer eine Idee, bevor ich nun gleich alle Batterien der Geräte wechseln werde?

Aufflällige Meldungen:

/var/log/messages
Nov 27 17:14:13 matic-ccu local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1237, params: {"000E5569A24ACF:1","PARTY_TIME_START"}) [CallGetValue():iseXmlRpc.cpp:1435]
Nov 27 17:14:13 matic-ccu local0.err ReGaHss: ERROR: CallGetValue failed; sVal = [ReadValue():iseDOMdpHSS.cpp:124]
Nov 27 17:14:13 matic-ccu local0.warn ReGaHss: WARNING: XMLRPC 'getValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"000E5569A24ACF:1","SET_POINT_MODE"}, result: [faultCode:-5,faultString:"Unknown Parameter value for value key: SET_POINT_MODE"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Nov 27 17:14:13 matic-ccu local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1237, params: {"000E5569A24ACF:1","SET_POINT_MODE"}) [CallGetValue():iseXmlRpc.cpp:1435]
Nov 27 17:14:13 matic-ccu local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0 [ReadValue():iseDOMdpHSS.cpp:124]
Nov 27 17:14:13 matic-ccu local0.warn ReGaHss: WARNING: XMLRPC 'getValue': rpcClient.isFault() failed (url: xmlrpc://127.0.0.1:32010, params: {"001898A997FF97:1","WATERLEVEL_DETECTED"}, result: [faultCode:-5,faultString:"Unknown Parameter value for value key: WATERLEVEL_DETECTED"]) [CallXmlrpcMethod():iseXmlRpc.cpp:2608]
Nov 27 17:14:13 matic-ccu local0.err ReGaHss: ERROR: XMLRPC 'getValue' call failed (interface: 1237, params: {"001898A997FF97:1","WATERLEVEL_DETECTED"}) [CallGetValue():iseXmlRpc.cpp:1435]
Nov 27 17:14:13 matic-ccu local0.err ReGaHss: ERROR: CallGetValue failed; sVal = 0 [ReadValue():iseDOMdpHSS.cpp:124]


hmserver.log (TRACE):
Nov 27 17:16:18 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem TRACE [vert.x-eventloop-thread-2] SYSTEM: OTAU periodic start handler is trying to start a handler
Nov 27 17:16:18 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem TRACE [vert.x-eventloop-thread-2] SYSTEM: No suitable AP found - cannot start any RF update handlers
Nov 27 17:16:18 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem TRACE [vert.x-eventloop-thread-2] SYSTEM: No suitable AP found - cannot start any wired update handlers
root@matic-ccu:/var/log#

[MichaelN]

alle HM-IP Geräte sind nicht mehr anwählbar.

Was sagtest Du nochmal, wie hoch ist der CS?

[jp112sdl]

alle HM-IP Geräte sind nicht mehr anwählbar.

Was sagtest Du nochmal, wie hoch ist der CS?

HW: RPI3+HM-MOD-RPI

n/a

[MichaelN]

Das immer am falschen Ende gespart wird.
Ich dachte nur, weil

DC/CS monitoren

[hubbel]

Guten Abend,

genau, CS ist n/a aufgrund des alten Moduls - mit der CCU3 sollte es dann ab Montag das große/neue Modul sein.

Die HM-Komponenten sind ganz normal erreichbar, nur HM-IP - scheinbar hatte viewtopic.php?f=65&t=65610&start=20 jemand das gleiche Problem. Eine echte Lösung gab es auch nicht. Batterie raus/rein und es geht wieder.

Gibt es eine Möglichkeit den CS zu aktivieren mit dem alten Modul? Viele Grüße!

[hubbel]

Das immer am falschen Ende gespart wird.
Ich dachte nur, weil

DC/CS monitoren

Du meinst bzgl Raspberrymatic oder dem alten Modul? Ich nutze das Modul seit Jahren, die Probleme hatte ich früher nicht (habe aber auch selten Neustarts der CCU). Ich habe hier nicht spaaren wollen - als ich von der CCU gewechselt bin gab es meines Erachtens nur dieses Modul...
Das Monitoren bezog sich wirklich auf den DC, ich hatte hier mit dem android-modul für AskSin versucht, Problme zu identifizieren.

[MichaelN]

Das Monitoren bezog sich wirklich auf den DC

Ne, alles gut