hallo zusammen, meine ccu2 will wieder zurück auf 3.47.15. jemand eine idee? vielen dank.
vg aus tirol

Hi.

Bist Du sicher, dass Du da nicht was verwechselst? Für die CCU2 ist die 2.47.18 aktuell, für die CCU3 die 3.47.18. Welche Zentrale hast Du denn da nun am Start und welche Version hast Du versucht da einzuspielen?

LG,
Marc

Hallo zusammen,
ich hatte in meine CCU2 die Version 3.47.18 eingespielt und danach tierischen Ärger mit den HomematicIP-Komponenten gehabt. Daraufhin habe ich mich an den Support von eq-3 gewendet hier ist die Antwort:

Die am Dienstag veröffentlichte Version der CCU2 Firmware hat eine vermeintliche Verbesserung der Homematic IP Komponenten enthalten, welche allerdings bei einigen Kunden zu einem Fehlverhalten der Messdatenerfassung und die Gruppenfunktionalitäten führte. Aus diesem Grund wurde die FW zunächst wieder zurückgezogen. Bitte installieren Sie wieder die Version 2.47.15

Gruß

Andre

Danke für die Information -> habe das im CCU2-Firmware Artikel vermerkt.

Frage mal so in die Runde hat jemand mit der CCU3 und diesem Update auch einen relativ hohen Duty Cycle. Der steht selbst nach dem Neustart bei 99%.

Liegen bei Dir evtl. nun haufenweise Konfigurationsdaten an, die übertragen werden wollen?

Ich habe das gleiche Problem mit der CCU3 und der Version 3.47.18. Es wird immer ein sehr hoher Duty Cycle angezeigt. Seit heute bietet er mir die 3.47.15, also die alte Version, wieder als Update an. Weiß jemand was da dahinter steckt? Wurde die 18er zurückgezogen?

Der Download wurde ebenfalls auf der eQ-3 Seite entfernt - sieht also schwer danach aus. Über den hohen Duty-Cycle wird auch von anderen Usern berichtet:

• Diskussion im HomeMatic-Forum

Ich schaue mal, ob ich dazu morgen weitere Informationen erhalten kann...

Jens Maus hat im Forum dazu folgendes geschrieben:

Meinen Informationen nach wurde hier im HmIP Teil (HMIPServer) versucht durch Anpassungen/Änderungen von Timeouts Netzwerkkommunikationsproblemen entgegen zu wirken die damit zusammen hängen/hingen, das bei der XMLRPC Kommunikation mit dem HMIPServer es dazu kommen kann/konnte, das dieser die komplette XMLRPC Kommunikation auf Grund von einzelnen, nicht mehr verfügbaren (lauschenden) XMLRPC Clients eingestellt hat. D.h. wenn z.B. ein Client sich für die XMLRPC Kommunikation registriert, dann aber nicht ordentlich abmeldet bzw. z.B. eine Smartphone App einfach nicht mehr verfügbar ist weil das Smartphone eben z.B. ausser Reichweite ist, dann kann es dazu kommen das beim Versenden von Events via XMLRPC der interne XMLRPC Serverdienst im HMIPServer der die Clientkommunikation sequentiell abarbeitet ins Stocken gerät weil er eben versucht die Events an einen nicht mehr lauschenden Client auszuliefern. Und durch die interne Art und Weise der Abarbeitung dieser Eventauslieferungen kann es dann leider dazu kommen, das der HMIPServer bis zum Eintreten eines entsprechenden Timeouts in der Event-Auslieferung komplett blockiert wird und folglich auch z.B. die interne XMLRPC basierte Kommunikation mit der WebUI ins Stocken bzw. zum kompletten Erliegen kommt.

Und nun gab es eben von der x.47.15 zur x.47.18 eine Anpassung bei der die Timeouts von ursprünglich 10-15 Minuten auf ca. 5 Sekunden reduziert wurde um dem HMIPServer zu ermöglichen schneller auf solche nicht mehr verfügbaren XMLRPC Clients zu reagieren um nicht die gesamte XMLRPC basierte Eventauslieferung für einen sehr langen Zeitraum zu blockieren. Als jedoch die x.47.18 dann für die CCU2 herausgegeben wurde zeigte sich leider, das wohl bei gewissen Installationen dieses kurze Timeout auch negative Effekte in ähnlichem Ausmaß hervorbrachte einfach weil die CCU2 selbst nicht performant genug ist/war um diese Timeout-Schwelle bei der normalen Kommunikation einzuhalten. Daraufhin wurde dann recht schnell mit der x.47.20 durch eine erneute Erhöhung der Timeouts im Bereich von wenigen Minuten versucht entgegen zu wirken. Und wie sich bis jetzt zeigte hat dies anscheinend auch zumindest bezogen auf die CCU2 den gewünschten Erfolg gebracht. Bei der CCU3 bzw. RaspberryMatic gab es jedoch bis zum Release der 2.47.20 keinerlei Hinweise das die CCU3/OCCU/RaspberryMatic Version des HMIPServer auch davon substantiell betroffen ist und man hier durch ein 3.47.20 release reagieren müsste.

Wie sich aber in den letzten Tagen wohl zeigte, scheint hier das Problem zumindest in abgeschwächter Form auch zu existieren und so scheint es nun so zu sein, dass es wohl in naher Zukunft eine weitere 3.47.x Version geben wird die die selben Anpassungen in den Netzwerktimeouts bei der XMLRPC Kommunikation mitbringen wird. Und sobald diese dann herausgebracht wurde bzw. eine entsprechende OCCU Version gibt wird natürlich dann auch RaspberryMatic von dieser erneuten Anpassung profitieren. Ich hoffe das bringt etwas Licht ins Dunkel.

Mit der heute erschienenen Version 3.47.22 sollte dieses Problem nun behoben sein.