JRiemann hat geschrieben: ↑03.09.2018, 18:13
esbol hat geschrieben: ↑03.09.2018, 16:13
Du NICHTS über mich, und trotzdem wirst Du hier beleidigend!
Nun mal ganz langsam!!! Dir ist aber schon klar das Dir mehrere User antworten und das Du gerade Antworten verschiedener Nutzer vermischt?
Wenn Du so dünnhäutig bist und allgemeine Formulierungen persönlich nimmst obwohl 2x darauf hingewiesen wurde das es nicht persönlich gemeint ist, dann tut es mir Leid. Zumindest können wir alle auf den patzigen und fordernden Ton verzichten!
Wen ich hier aus Versehen jemanden zu Unrecht angepflaumt habe, dann tut es mir leid und ich entschuldige mich.
So, um mal konstruktiv zu werden, anbei ein Bild, was z.B. zu sehen ist, wenn man einen exemplarischen HmIP-PS nach dem "Ereignis" bei mir in der Geräteliste anschaut. Er zeigt keinerlei Informationen und Kanäle mehr an. Es sind meist, aber nicht immer, alle HmIP-PS betroffen, mitunter aber auch die HmIP-FSM gleichermaßen. Andere Geräte (auch batteriebetriebene) zeigen manchmal sinnvolle Daten, manchmal nicht. Die eTRV z.B. zeigen oft den Zustand manuell/aus, obwohl sie korrekt auf Automatic laufen. Keines der Geräte ist noch über die Web-Oberfläche bedienbar. Manuelle Änderungen an den Geräten kommen nicht mehr an der CCU2 an (auch die batteriebetriebenen eTRV kommunizieren dann!). Ich habe zur Sicherheit auch schon mal einen halben Tag gewartet, ob sich das Ganze "einschwingt".
Die CCU2 führt dann keinerlei Programme mehr aus, auch die nicht, die gar keine Geräte benutzen. Die Web-Oberfläche der CCU2 ist dann zäh bis unbenutzbar. Alleine, um diesen Screenschot zu kriegen, habe ich fast 10 min. gebraucht. Meine Vermutung ist, dass irgendein Programm forever auf klare Daten eines Geräts wartet, aber keine bekommt, der Rest dann nicht zum Zuge kommt. Welches das Programm sein könnte, und ob das wirklich so ist, ist für mich mit Bordmitteln nicht herauszubekommen, es könnte auch jedesmal ein anderes sein, abhängig vom Gerät, das gerade nicht kommuniziert.
Es gibt keinerlei Kommunikationsstörungen, weder in der Oberfläche noch in den Logs (in /var/log), nie. Auch sonst finde ich den Logs nichts Auffälliges.
Das Phänomen tritt nach ca. 1/3 der Reboots auf, aber mitunter auch im laufenden Betrieb. Ca. 2/3 der Reboots laufen durch, die CCU2 läuft dazwischen 1-3 Wochen ohne Störung. Das einzige was bisher half, waren "reboots" per SSH (wenn die Oberfläche unerträglich langsam ist oder nicht mehr reagiert), ggfs. eben auch mehrfach. Nach dreimal Reboot läuft die CCU2 eigentlich immer wieder problemlos.
Programmfehler schließe ich inzwischen aus, denn alle Programme laufen im Betrieb über Tage und Wochen problemlos und sind mehrfach geprüft.
Es gibt einige wenige Skripte (4 an der Zahl) mit system.Exec Aufrufen, aber auch hier ist sichergestellt, dass die Skripte fehlerfrei sind und nicht stehen bleiben können (tun sie auch nicht). Die Skripte schalten A/V-Receiver per wget oder triggern Push-Nachrichten/SMS via Cloudmatic. Das Problem tritt auch auf, wenn diese Programme/Skripte inaktiv geschaltet sind, also gar nicht aufgerufen werden.
Hardware-Defekte könnten sein, aber dann müßte es eigentlich Kommunikationsstörungen o.ä. geben, auch in den Logs sollten Fehler zu sehen sein.
Es läuft ausser hm-print-1.2a keine Erweiterung auf der CCU2, die ist aber mit Cloudmatic verbunden.
Zusätzlich läuft eine homebridge-homematic auf Docker auf einem Syno.
Die homebridge ist übrigens auch nicht die Ursache, das Phänomen tritt auch auf, wenn sie nicht läuft, nur eben seltener (was wiederum auf ein Lastproblem hindeutet).
Einziger Hinweis für "Ursachen" bisher (nachdem ich alles mögliche schon ausgeschlossen habe) : die "Hänger" sind eindeutig mit einem erhöhten Aktivitätslevel der CCU2 korreliert, treten also nach dem Reboot auf, wenn viele Programm-Schaltvorgänge hintereinander laufen oder die homebridge mal viel abfragt, dennoch kein wirklich klares Muster erkennbar.
Weitere Infos:
Die HmIP-PS (und alle anderen HmIP-Geräte), die mal ein FW-Update erfahren hatten, wurden danach ordnungsgemäss abgemeldet, resettet auf Werkseinstellungen und neu angemeldet (was für eine Arbeit...).
free -m zeigt kein Speicherproblem (meist noch min. 25-30% frei).
Es sind keine Zombies oder andere ungewöhnliche Prozesse zu finden.
Es finden sich auch posthum keine Prozesse, die ungewöhnlich viel CPU fressen, wenn die Oberfläche nach dem Ereignis so schnarch-langsam ist, die Shell (per SSH) ist ansprechbar und agil.
Der DC (mit Skript von alchy ermittelt, das ohne CuXD!) geht nie über 20.
Der HmIP-PS unten ist ca. 3 m von der CCU2 weg, und hat LineOfSight. Auch der Ort der CCU2 spielt keine Rolle (habe das Ding auch mal einfach "bewegt").
Alle Geräte sind auch noch per Direktverknüpfung schalt-/ansprechbar, sind also nicht "offline", wenn die CCU nicht mehr mit ihnen kommuniziert.
Ein Backup und Logs dazu habe ich vor Monaten auch schonmal an eq-3 geschickt, ohne Ergebnis, auch eq-3 findet nichts Ungewöhnliches.
Es wurde übrigens mit dem Update auf 2.35.16 besser, seither ist die CCU2 im Normalbetrieb bei mir merklich agiler geworden, die Schwuppdizität der Oberfläche ist fühlbar besser als vorher, die "Hänger" treten im Normalbetrieb seltener auf (vorher einmal die Woche, jetzt läuft das Ding auch schonmal zwei/drei Wochen durch). Auch das deutet auf Lastprobleme hin.
Generell habe ich den Eindruck, dass die CCU2 mit den vielen HmIP-Geräten an die Grenzen der Leistungsfähigkeit stösst.
Die CCU3 ist jetzt bestellt (nachdem es hier keine größeren "Unfälle" bei der Umstellung gab) und ich bin gespannt, ob das Phänomen danach noch/wieder auftritt.
