CCU3 Duty Cycle auf 100%, drei mal am Tag für 30 min

[Sat_Dad]

Hallo Spezialisten,

ich brauch mal dringend Euren Rat bei folgendem Problem:
seit Ende Okt 2019 fährt mein System ca. drei Mal amTag, gegen 01:00, 13:00, 14:00, in einen Duty Cycle von 100%. Der Zustand dauert dann ca. 30 min bis dann der Wert <10%, der Normalzustand, wieder erreicht wird.

Das System besteht aus:
- CCU3 aktuelles Release
- drei LAN Gateways EU und ein Config Adapter (der alte runde)
- CUXD aktuelles Release 2.3.4 , Phiips Hue und das EMAIl Addon sind installiert
- CCU Historian und Openhab greifen auf das System zu, allerdings auch schon eine Ewigkeit
- Skripte verwende ich nur zum Auslesen meiner Stromzähler (HM-ES-TX-WM) und das Servicemail Skript
(von Alchy alte Version 1.8 allerdings im Moment deaktiviert).

Das System lief bis Ende Okt 2019 stabil (so stabil wie die Funkkomponenten der Homematic Serie halt sind).
Änderungen wurden nicht vorgenommen, jedenfalls nicht wissentlich.

Zum Fehlerbild:
- erst fährt der Duty Cycle auf der CCU und/oder einem LAN Gate langsam hoch
- es sind allerdings nur die CCU und ein Gateway betroffen, allerdings nicht immer dieselben. Der Umzug von Komponenten von einen zum
anderen Gateway oder zurück auf die CCU, soweit möglich, brachte keine Veränderung.
- dann bekomme ich ein oder mehrere Fehlermeldungen:

Code: Alles auswählen

ccu3-webui user.err rfd: CCU2BidcosRemoteInterface::RemoveDeviceWakeupRequest(): Failed remotely

- in der Zeit keine m.E relevanten Fehlermeldungen o.ä.

Code: Alles auswählen

ccu3-webui local0.warn ReGaHss: WARNING: XMLRPC 'setValue': rpcClient.isFault() failed 

oder

Code: Alles auswählen

ccu3-webui user.err rfd: Can't remove device remotely

solche in der Art habe ich schon ewig und für letztere gibt es ja wohl auch keine Lösung
- irgendwann häufen sich dann die Fehlermeldungen

Code: Alles auswählen

ccu3-webui user.err rfd: CCU2BidcosRemoteInterface::RemoveDeviceWakeupRequest(): Failed remotely

- dies endet dann in einem Bufferüberlauf:

Code: Alles auswählen

ccu3-webui user.err kernel: [20393.429792] eq3loop: eq3loop_write_master() mmd_bidcos: not enough space in buffers. free space = 2,
   required space = 24

- nach ca. 30 min kehrt das System wieder in den Normalzustand zurück
- in der Zeit und dannach keine anderen Fehlermeldungen
- wenn ich mir die Logs des DC in der Zeit ansehe, dann ist interessant, dass die Spitzen des Duty Cycle in der Zeit vom 28. Okt bis 04. Nov
drei Mal am Tag von 20% auf 50 % hochgeschaukelt haben, der Peak jeden Tag ein bisschen höher, um dann ab 4. Nov dreimal immer die 100%
zu erreichen.

Ein Backup von Ende Okt habe ich bereits eingespielt. Interessanter Weise zeigt dies nun dasselbe Phänomen.

Offensichtlich versucht das System eine Komponente zum Löschen zu erreichen.
Da ich keine Veränderungen vorgenommen habe und der Fehler so regelmässig auftritt vermute ich, dass es einen Job gibt, der versucht die Datenbank der Devices aufzuräumen.
Die allgegenwärtigen Hinweise auf Amok laufende Batteriesensoren etc. würde ich ausschließen, die senden die letzten Wochen alle brav ihre Werte.
Einzig, ich habe in der Zeit, allerdings nach dem ersten Auftreten des Problems, eine zweite Instanz von OpenhHab und CUHIstorian auf das System losgelassen, da ich die Protokollierung auf eine andere Maschine umziehen wollte.

Vielleicht hat ja einer von Euch eine Tip , wie ich den Fehler, zumal er so regelmäßig auftritt, weiter eingrenzen kann.
Irgendwie habe ich nur eine begrenzte Motivation alles from the scretch neu aufzubauen.

vorab vielen Dank
Detlef

[Xel66]

Ich würde damit anfangen zu schauen, welche Programme exakt zu diesen Uhrzeiten gestartet werden. Wenn es immer zur gleichen Zeit ist, dann muss es mehr oder minder eine Zeitsteuerung sein. Vermutlich spricht diese viele Geräte nacheinander an oder Du hast eine Schleife programmiert, in der ein Gerät bei Aktualisierung seines Status immer wieder das Programm ansteuert.

Gruß Xel66

[Sat_Dad]

Hallo Xel66,

ok, meine Beschreibung war unvollständig,
a) passiert nicht immer exakt zu den Zeiten, so plus/ minus 30 min
b) habe ich keine Programme, die zu den Zeiten ausgeführt werden

Im Wesentlichen dient das System zur Überwachung/ Protokollierung .

Die einzigen zykischen Progamme die laufen ist
c) meine Rollosteuerung (helligkeitsgesteuert, also derzeit kurz nach 07:00 rauf und um 05:00 runter, und die mit Verzögerung, also nacheinander )
d) meine Haus- und Gartenbleuchtung, an bei Dunkelheit und aus um 21:00 und 23:00
e) meine Beleuchtung für Carport und Eingang ist so eingestellt, dass sie nur Morgens zwischen 05:30 und 08:00 und Abends zwischen 17:00 und 21:30 aktiviert ist (den ganzen Katzen und sonstigen Tierchen, die Nachts mein Licht einschalten wollen geschuldet )

Danke für die schnelle Reaktion, aber das war es leider nicht, zumal auch die Programme schon seit Jahren laufen.

Evtl. noch ein Hinweis: ich habe das System vor ca einem Jahr über ein Backup aus einer CCU2 aufgebaut, evtl. hier eine Inkompatibilität, aber warum die erst jetzt zuschlagen sollte.
In der Zeit kam nur die Philips Hue, das allerdings auch schon vor Monaten und die sollte im Funkbeeich ja wohl keine Rolle spielen.

Gruß
Detlef

[twoxx]

Hallo Detlef,

wie ist die Aufteilung der Komponenten?

Welche sind Homematic Classic und welche sind Homematic IP?
Manche Homematic-Classic Komponenten liefern bei bestimmten Firmwares plötzlich hohen Dutycycle (beispielsweise die Homematic-Classic Bewegungsmelder ab einer bestimmten Firmware).

Wie ist der Funkempfang der Komponenten zur CCU/zu den Gateways? (was sagt DevConfig?)

Die Tatsache das Du Gateways nutzt, lässt mich vermuten dass Du schon an der einen oder anderen Stelle mal Empfangsstörungen hattest.
Hat sich hier was geändert? Bauliche Veränderungen im Gebäude? Vielleicht tut sich dadurch eine Komponente jetzt schwer mit der Kommunikation.

Sofern du nicht die Zeit für An- Abmelden der Komponenten und Neuaufbau des Systems verwenden willst, könntest Du ein Backup
erstellen und die CCU3 auf Raspymatic umstellen (kein Upgrade, sondern Firmware neu einspielen und dann ein CCU3-Backup auf die
Raspymatic einspielen - so wie Du es von der CCU2 her gemacht hast).

Alternativ:
Hast Du vor Installation der CCU3 ein Backup der mikro-SD Karte gemacht? Dann könntest Du sofort die CCU3 nochmal frisch mit einer neuen Homematic-Firmware betanken und nochmal das letzte CCU-Backup einspielen.

Sofern Du keine Original "Start-CCU3-mikro SD Karte" mehr hast:
Die neueste Raspymatic Firmware auf die Mikro-SD-Karte schreiben, darin dann die neueste CCU3-Firmware als "Upgrade" einspielen.
und dann das letzte CCU3-Backup wieder einspielen.

Dann hast du ein "frisches System" und kannst nochmal schauen.

Vielleicht ist dann dem Spuck schon ein Ende gesetzt.

[manfredh]

c) meine Rollosteuerung (helligkeitsgesteuert, also derzeit kurz nach 07:00 rauf und um 05:00 runter, und die mit Verzögerung, also nacheinander )

Gerade solche Programme sind - falsch angelegt - Kandidaten für das Hochtreiben des DC.

Beispiel (die Rolläden sollen hochfahren, wenn es hell ist, aber nicht vor 7 Uhr):

Code: Alles auswählen

Wenn
 Helligkeitswert größer 60 bei Aktualisierung auslösen
 und
 Uhrzeit 7:00 bis 9:00
Dann
 Alle Rollläden hoch

Sobald der Wert die 30 erreicht, fängt das Senden an. Jedesmal, wenn der Wert aktualisiert wird (also der Sensor einen Wert sendet), wird das Programm getriggert und das Dann ausgeführt. Schließlich steht ja da "bei Aktualisierung (das Programm) auslösen".
Das Ganze passiert dann mglw. alle 3 Minuten bis das Zeitfenster um 9 Uhr verlassen wird.

Also suche nach Programmzeilen mit "bei Aktualisierung..." und analysiere sie entsprechend.

[Sat_Dad]

Hallo,

@Xel66:
- ich verwende fast nur Classic, ausser zwei HM IP SLO
- RSSI liegen unter -80dBm, nur zwei/drei mal in der Gegend von -90dBm
- die Gateways nutze ich zur Reichweitenverlängerung im Garten, Carport und Keller dank massiver Betonwände
- heute Nacht das System auf einen Raspmatic umgezogen, der Fehler ist alledings auch mit umgezogen
- Firmware würde ich auch ausschließen, keine Änderungen im fraglichen Zeitraum

@manfredh:
- die Rollos steuere ich über eine SysVariable, die sich die Helligkeit per "Änderung" holt und dann werden die Rollos in Abhängigkeit dieser Variable in einem eigenen Programm per Änderung gefahren
- die anderen Programm sind ähnlich aufgebaut, auslösen bei "Änderung", weitere Bedingungen wie Zeitfenster im "prüfen"

Da das System bis Ende Okt stabil lief und ich weder an Programmen noch Hardware Änderungen vorgenommen habe, kann es eigentlich nur eine Funkkomponente sein, die aus der Reihe tanzt.
Habe den LogLevel mal auf "alles loggen" hochgedreht, aber die Auswertung des Logs ist hinreichend schwierig wenn man nicht weiß nach was man suchen soll.

Danke erst einmal für die Hilfe, für weitere sachdienliche Hinweise bin ich dankbar

Gruß
Detlef

[Xel66]

Da das System bis Ende Okt stabil lief und ich weder an Programmen noch Hardware Änderungen vorgenommen habe, kann es eigentlich nur eine Funkkomponente sein, die aus der Reihe tanzt.

Da die Auswirkung der Duty Cycle ist, ist die Ursache mit an Sicherheit grenzender Wahrscheinlichkeit eine Funkkomponente. Es kann aber eben auch die CCU bzw. eines der laufenden Programme sein. Alle Programme, die in irgendeiner Weise auf "bei Aktualisierung" triggern sind verdächtig.

Was ist seit Ende Oktober anders? Vermutlich laufen seit dieser Zeit irgendwelche Heizungssteuerungen. Temperatursensoren mit ihrer zyklischen Meldung der Daten sind bei falscher Programmierung auch ein Duty Cycle-Treiber, wenn Geräte stetig mit dem aktuellen Zustand angesteuert werden.

Einen Aktor, der eingeschaltet ist kann man nicht weiter einschalten, man kann ihm aber den Befehl geben, den er auch schön quittiert und die Ausführung zurückgemeldet. Was auch wieder quittiert wird. Alles das belastet den Duty Cycle, aber passieren tut offensichtlich nichts. Ohne Kenntnis Deiner Programmierung ist da schlecht zu analysieren. Das musst Du auf Grund der gegebenen Hinweise selbst tun.

Gruß Xel66

[alchy]

Habe den LogLevel mal auf "alles loggen" hochgedreht, aber die Auswertung des Logs ist hinreichend schwierig wenn man nicht weiß nach was man suchen soll.

Funk auf alles loggen und Fehlerprotokoll posten (geht natürlich auch per PN)
Günstig wäre natürlich, wenn das Fehlerprotokoll auch den Zeitbereich enthält, wo der DutyCycle schön hoch ist.

Alchy

[Sat_Dad]

Hallo Alchy,

danke für das Angebot, aber seit ein paar Tage ist wieder Ruhe.Damit auch kein Fehlerlog mehr das man auswerten könnte.

Interessant ist der Post von dtp "CCU3 verschluckt sich gerade täglich um ca. 13:30 Uhr".
Eine ganz ähnliche Situation mit dem zyklischen Auftreten um 13:00.
Wenn ich neue "Fehler" Daten habe melde ich mich wieder.
Gruß
Detlef

[alchy]

Interessant ist der Post von dtp "CCU3 verschluckt sich gerade täglich um ca. 13:30 Uhr".
Eine ganz ähnliche Situation mit dem zyklischen Auftreten um 13:00.

ähnlich?
Es fährt in München auch täglich 13:30 mehrere Züge los und ein Flieger hebt auch ab.
Du hast einen ansteigenden DutyCycle vs. dtp hat das überhaupt nicht.
Er bekommt "nur" Servicemeldungen aber ohne einen Anstieg des DutyCycle.

Es nur an der Uhrzeit fest zu machen, ist weit hergeholt. Auch ich hatte schon meine regelmäßigen Züge und Flüge in Form einer >> sterbenden Energieversorgung <<
Sogar schon mehrfach jeweils mit DutyCycle Anstieg.
Aber auch schon zu Zeiten, da gab es den DutyCycle noch gar nicht offiziell. (den Post finde ich aber nicht) Da kann ich mich auch daran erinnern, das ich vermehrt Servicemeldungen erhalten habe.

Alchy