hoher Duty Cycle durch Fehler Hue Bridge ?

[romeoalfa1975]

Nur mal so am Rande:
Ich hatte bis vor 2 Wochen eine CCU mit FW 3.45.7 - DC durchgehend < 20 %.
Nun habe ich aus speziellen Gründen das System auf 3 CCUs mit FW 3.42.22 erweitert und seitdem in der Summe einen DC zwischen 40 und 50 % - bei ansonsten gleichem Fuhrpark.
Habe i. M. aber keine Zeit, der Sache auf den Grund zu gehen.

Das ist interessant!
Als ich vor wenigen Wochen noch mit der 3.47.15 bzw. .18 gefahren bin, war der DC im Ruhezustand bei mir ziemlich genau zwischen 15% und 18%.
Ebenfalls bei gleicher Konstellation der Geräte. Erst seit dem Update auf die 3.47.22 sind mir diese hohen Ausreißer, die immer scheinbar grundlos für eine Stunde auftreten, aufgefallen.

Hatte dazu auch mal eq-3 angeschrieben, Antwort:
"Generell sollte ein System um die 90 Geräte einen Grund DC von maximal 10-15% haben. Möglicherweise sind einige Geräte vom Grundempfangswert nicht sauber zu erreichen und senden daher häufiger Datensätze. Oder die CCU liegt etwas zu dicht am Router, hier sollte mind. 1 Meter Abstand bestehen."

Die Sache mit dem "nicht sauber erreichen" könnte evtl. noch in Frage kommen, aber wie gesagt: Ich habe nichts an den Geräten und an den Standorten verändert.

@Daimler: Ich bin gespannt, ob Du der Ursache auf die Schliche kommen kannst

[Daimler]

Erst seit dem Update auf die 3.47.22 sind mir diese hohen Ausreißer

Wie geschrieben, sind das bei mir keine Ausreißer, sondern der kontinuierliche DC-Stand.
Ist hier auch grundsätzlich kein Problem, da der DC sich ja über 3 CCUs verteilt.
War nur interessant, dass der DC-Anstieg parallel mit dem ..22er FW-Update fiel.
Zurück auf eine CCU geht leider nicht mehr so ohne weiteres, sonst würde ich das noch einmal testen - aber der Aufwand ist mir dann doch zu hoch.

Wobei mich das System gerade Lügen straft - erstmalig unter 40 %.
Die Geräte an GW 2 und 3 hängen jetzt überwiegend an den neuen CCUs - daher 0 %
Zwar immer noch 1 Drittel mehr als vorher - aber evtl. muss ich nur nochmals 2 Wochen warten.

- Und du dann auch

DC.JPG (24.48 KiB) 1323 mal betrachtet

[romeoalfa1975]

Moin,

gestern Abend bei ca. 30% DC zu Bett gegangen und extra WLAN vorher ausgeschaltet, während der Nacht dann:

0:30 Uhr: Anstieg auf 100%
1:30 Uhr: Fall auf 0%
3:00 Uhr: Ab hier steigt der DC wieder auf die "normalen" 30% an.

ich habe jetzt mal im Log geschaut, und dort nach dem schon mal erwähnten "CCU2" Eintrag filtern lassen.

Dort erscheint dann:

Code: Alles auswählen

Nov 15 00:32:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 80%
Nov 15 00:33:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 85%
Nov 15 00:34:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 87%
Nov 15 00:35:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 91%
Nov 15 00:36:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 95%
Nov 15 00:37:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 15 00:38:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 100%
Nov 15 00:39:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 98%
Nov 15 00:40:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 15 00:41:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 15 00:42:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 15 00:43:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 15 00:44:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 96%
Nov 15 00:45:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 96%
Nov 15 00:46:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 96%
Nov 15 00:47:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 96%
Nov 15 00:48:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 96%
Nov 15 00:49:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 93%
Nov 15 00:50:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 93%
Nov 15 00:51:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 93%
Nov 15 00:52:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 93%
Nov 15 00:53:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 93%
Nov 15 00:54:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 91%
Nov 15 00:55:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 91%
Nov 15 00:56:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 91%
Nov 15 00:57:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 91%
Nov 15 00:58:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 91%
Nov 15 00:59:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 87%
Nov 15 01:00:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 87%
Nov 15 01:01:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 87%
Nov 15 01:02:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 87%
Nov 15 01:03:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 87%
Nov 15 01:04:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 15 01:05:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 15 01:06:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 15 01:07:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 15 01:08:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 15 01:09:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 83%
Nov 15 01:10:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 83%
Nov 15 01:11:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 83%
Nov 15 01:12:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 83%
Nov 15 01:13:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 83%
Nov 15 01:14:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 81%
Nov 15 01:15:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 81%
Nov 15 01:16:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 81%
Nov 15 01:17:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 81%
Nov 15 01:18:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 81%

Hier scheint alles über 80% DC geloggt zu sein. Die QEQ-Nummer dort ist der "normale" Homematic Funk, so wie ich das sehe. Kann es sein, dass der hohe DC gar nicht durch irgendwelche HmIP-Komponenten verursacht wird, sondern durch den HM-Funk?

Und noch etwas interessantes fällt mir auf:

Wenn ich in der RaspberryMatic auf Einstellungen -> Systemsteuerung -> LAN-Gateway Konfiguration gehe,
dann sehe ich hier den HM-RCV-50 BidCoS-RF mit der Nummer QEQ0145281 (siehe Log).

Wenn ich meine zweite CCU3 in Betrieb nehme und dort ebenfalls diesen Punkt aufsuche,
sehe ich EBENFALLS den HM-RCV-50 BidCoS-RF mit der Nummer QEQ0145281.

Kann hier etwas nicht stimmen? Haben hier beide Geräte dieselbe Nummer QEQ0145281 ?

[Daimler]

Hi,

bitte nochmal für mich zum Verständnis:
Welche Hardware (CCU) hast du jetzt eigentlich genau?
Welches Funkmodul ist da drauf?
Hast du zusätzliche Lan-Gateways?

dann sehe ich hier den HM-RCV-50 BidCoS-RF mit der Nummer QEQ0145281

Und diese ID bleibt auch da stehen und wechselt nicht nach ein paar Sekunden auf 'Standard'?

[romeoalfa1975]

Hallo Günter

also ich habe:

1x original CCU3 mit RaspberryMatic mit der Funkmodulnummer QEQ0145281 (ja, wechselt auf "Standard")
1x original CCU3 mit original Firmware (als Ersatzgerät) mit ebenfalls der Funkmodulnummer QEQ0145281
keinerlei Gateways usw.

An den Geräten wurden keinerlei Modifikationen vorgenommen.

Dass beide dieselbe Nummer des Funkmoduls zeigen, macht mich stutzig.
Habe bei der Ersatz-CCU3 (aktuell keine Geräte angelernt) jetzt mal zum Spaß einen Factory-Reset gemacht: Nun wird dort eine neue QEQ... angezeigt.

Ich hatte vor einigen Wochen mal den Test gemacht und ein Backup auf der zweiten CCU eingespielt, um zu sehen, ob dies im Notfall auch funktioniert.
Kann es durch Backup-hin-und-her-testerei dazu gekommen sein, dass plötzlich beide Geräte dieselbe Nummer im Funkmodul hatten und sich gegenseitig beeinflusst haben?

[Daimler]

Hi,

1x original CCU3 mit RaspberryMatic mit der Funkmodulnummer QEQ0145281

Aha - OK.
Ich war immer der Meinung, das die Ori-CCU3 das RPI-RF-MOD Funkmodul onBoard hätte.

(ja, wechselt auf "Standard")

Bist du dir wirklich sicher, dass dies bei beiden CCUs der Fall ist?
Das kann eigentlich nicht sein.

Kann es durch Backup-hin-und-her-testerei dazu gekommen sein, dass plötzlich beide Geräte dieselbe Nummer im Funkmodul hatten und sich gegenseitig beeinflusst haben?

Ja - die ID steht im Backup!
Aber wenn du dann in Systemsteuerung --> Lan Gateway auf Einstellen gehst und 'Standard' auswählst, sollte / muss sich die ID ändern.
Aber das (ja, wechselt auf "Standard") kann (bei der 2. CCU) nicht sein!

P.S.
Ich gehe übrigens heute wieder auf die alte FW zurück.
Bin heute nacht mit IP-Servicemeldungen zugemüllt / mailt worden, weil auch mich dieser hier bereits oft beschriebene HM-IP <--> FW 47.22 Bug getroffen hat und keine IP-Geräte mehr ansprechbar waren..

[romeoalfa1975]

(ja, wechselt auf "Standard")

Bist du dir wirklich sicher, dass dies bei beiden CCUs der Fall ist?
Das kann eigentlich nicht sein.

Ja, ich bin mir ganz sicher - daher war meine Verwunderung auch so groß.
Wenn ich in die Systemsteuerung (sowohl bei RM-Firmware als auch bei der original-CCU3) gehe und dann auf LAN-Gateway, erscheinen jeweils erst kurz die QEQ... Nummern und werden dann automatisch durch "(Standard)" ersetzt.

Nach dem Werksreset hat die CCU3 nun eine neue QEQ-Nummer (Wahrscheinlich die ursprüngliche!)

Vielleicht sollte ich jetzt mal warten, ob der DC sich beruhigt und andernfalls vielleicht auch noch mal die Vorgängerversion installieren?

Danke übrigens, Günter, für Deine schnellen Antworten.

[romeoalfa1975]

Guten Morgen.

Habe heute morgen wieder dasselbe gehabt.
Den ganzen Abend DC zwischen 30-40%, dann nachts plötzlich 100%, danach sinkend, dann ca. eine Stunde exakt 0%.
Ich glaube mittlerweile nicht, dass das irgendwie mit der hue Bridge zusammenhängt.

Vielleicht hat jemand noch eine Idee, was man noch mal versuchen könnte.

[Daimler]

Hi,

ich sehe hier 3 Möglichkeiten:
1.
einen Syslog-Server verwenden / aufsetzen, die Logs auf 'Alles protokollieren' stellen und auf den Syslog schreiben.
(Dachte, ich hätte das hier bereits geschrieben - war aber wohl in einem anderen Fred)
So hast du ein Log über den gesamten Zeitraum, welches du auf Ursachen durchforsten kannst.

Im Zweifelsfall kannst du das dann auch hier hochladen und es findet sich idR immer jemand, der dann etwas findet.
Ich bin dann aber leider raus - die Logs sind für mich ein rotes Tuch.

2.
Da du ja R-Matic einsetzt und verm. den geforderten Obolus entrichtet hast , setze einen Pi als Gateway auf und schwenke nach und nach die Geräte auf das Gateway um.
(Bin mir nur nicht sicher, wie weit das Gateway von der CCU mindestens entfernt sein sollte, damit hier keine Störungen entstehen?)
Irgendwann sollte der DC Sprung von der CCU auf das Gateway umziehen.

3.
Alle Batteriegeräte um die Batterien erleichtern - Geduld bewahren - DC beobachten.
Wenn immer noch - die üblichen Verdächtigen mit C26 abklemmen - Geduld bewahren - DC beobachten.

Wünsche dir auf jeden Fall viel Erfolg bei der Behebung des Problems.

[romeoalfa1975]

Hallo Günter,

danke für die Tipps.
Ich werde mal Schritt für Schritt vorgehen und schauen, was passiert.
Muss mich nur erst mal belesen, wie 1) und 2) funktioniert. Bin normalerweise eher der Plug&Play-Anwender

Wenn ich alle Batterien entferne, entsteht dann nicht auch ein erhöhter DC seitens der CCU?
Und der C26 war - glaube ich - eher ein Problem beim klassischen Homematic, aber nicht bei IP?