CCU3 Firmware 3.47.15

[dannyh]

viewtopic.php?f=26&t=51824&start=10#p520017

So, nun habe ich das Problem gelöst.
1. Der USB-Stick konnte nicht schreiben. Fehler: Please run fsck.
2. Das CCU-Historian hatte Probleme gemacht. Das Plugin nochmals reingeladen.

So, nun sollte alles wieder funktionieren.

Gruess aus der Schweiz ...
DannyH

[Knallochse]

Iqst es richtig, dass HMIP Geräte ab jetzt nicht mehr abgelernt und neu angelernt werden müssen nach einen Update eines HMIP Gerätes?

Ja, das ist richtig!

Zu 100% scheint das noch nicht zu funktionieren.
Meine HMIP-eTRV wiesen nach dem Update auf 2.2.8 zwar alle Neuerungen (z.Bsp. Flüstermodus) auf, jedoch erzeugte eine schwache Batterie keine Servicemeldung in der WebUI (auf dem Thermostat Display wurde Batterie schwach angezeigt)
Meine Tests ergaben das gleiche Ergebnis bei den anderen HMIP-eTRV. Einen HMIP-eTRV habe ich ab und wieder angelernt, danach wurde eine Batteriemeldung als Servicemeldung im WebUI erzeugt.

[jmaus]

Iqst es richtig, dass HMIP Geräte ab jetzt nicht mehr abgelernt und neu angelernt werden müssen nach einen Update eines HMIP Gerätes?

Ja, das ist richtig!

Zu 100% scheint das noch nicht zu funktionieren.
Meine HMIP-eTRV wiesen nach dem Update auf 2.2.8 zwar alle Neuerungen (z.Bsp. Flüstermodus) auf, jedoch erzeugte eine schwache Batterie keine Servicemeldung in der WebUI (auf dem Thermostat Display wurde Batterie schwach angezeigt)
Meine Tests ergaben das gleiche Ergebnis bei den anderen HMIP-eTRV. Einen HMIP-eTRV habe ich ab und wieder angelernt, danach wurde eine Batteriemeldung als Servicemeldung im WebUI erzeugt.

Meines Wissens werden Batteriewarnungen in anderen Zyklen übertragen als andere Funktelegramme (Temperaturänderung). D.h. Also du hast vermutlich einfach nicht lang genug gewartet bis deine eTRV wieder eine neidrige Batteriemeödung ausgesendet haben.

Es ist also weiterhin wie so oft: Hier bringen viele leider nicht die notwendige Geduld auf und resetten Geräte viel zu aktionistisch statt einfach mal einen halben bis ganzen Tag zu warten bis sich das system wieder eingependelt hat...

[Knallochse]

Es ist also weiterhin wie so oft: Hier bringen viele leider nicht die notwendige Geduld auf und resetten Geräte viel zu aktionistisch statt einfach mal einen halben bis ganzen Tag zu warten bis sich das system wieder eingependelt hat...

Woher wissen Sie denn, wie lange ich auf die Servicemeldung gewartet hatte?

[deimos]

Hi,

Meines Wissens werden Batteriewarnungen in anderen Zyklen übertragen als andere Funktelegramme (Temperaturänderung). D.h. Also du hast vermutlich einfach nicht lang genug gewartet bis deine eTRV wieder eine neidrige Batteriemeödung ausgesendet haben.

Woher kommt das Wissen? Bei den BidCos Geräten wird das Batterieflag bei jeder zyklischen Nachricht mit übertragen und das in einer Form, welche die Nachrichtengröße nicht beeinflusst. Mir fällt kein guter Grund ein, warum das bei HmIP anders gemacht werden sollte.

Viele Grüße
Alex

[sidamos]

Ist es richtig, dass HMIP Geräte ab jetzt nicht mehr abgelernt und neu angelernt werden müssen nach einen Update eines HMIP Gerätes?
Habe mehrere HMIP-WTH2 Thermostate die noch auf ein Update warten.

Das ging bei mir schon mit der 3.45.7. Musste mich nur aus der Web-UI abmelden und anmelden.
Bei den Heizkörper-Thermostaten musste bei allen eine Adaptierfahrt gemacht werden (ist wohl normal nach Reset) und ein paar waren danach im falschen Modus.

[Matsch]

Das ging bei mir schon mit der 3.45.7. Musste mich nur aus der Web-UI abmelden und anmelden.

Das ist m.E. ein Trugschluß, denn noch gibt es keine Firmware der CCU, die diese Neuerung enthält (Changelog).
Natürlich funktioniert alles auch ohne ab- und anlernen nach einem Update, aber das gilt eben nur für alle Datenpunkte, die sich in der neuen Version gegenüber der alten nicht geändert haben! Haben sich Datenpunkte geändert oder sind neu hinzugekommen, dann wird diese Änderung ohne erneutem Ab- und Anlernen eben auch bis heute noch nicht wirksam, weil wohl die Datenpunkte ausschließlich bei einem Anlernvorgang in die CCU übernommen werden.

[sidamos]

Das ist m.E. ein Trugschluß, denn noch gibt es keine Firmware der CCU, die diese Neuerung enthält (Changelog).
Natürlich funktioniert alles auch ohne ab- und anlernen nach einem Update, aber das gilt eben nur für alle Datenpunkte, die sich in der neuen Version gegenüber der alten nicht geändert haben! Haben sich Datenpunkte geändert oder sind neu hinzugekommen, dann wird diese Änderung ohne erneutem Ab- und Anlernen eben auch bis heute noch nicht wirksam.

Das stimmt definitiv so nicht. Ich habe einen HmIP-PSM aktualisiert, mich ab- und angemeldet und dann waren die neuen Kanäle da. Zu geänderten Kanälen kann ich keine Aussage machen.

[Matsch]

Ich kann aber im Changelog der letzten Updates keinerlei Aussage dazu sehen, obwohl es ja extra angekündigt war

Vielleicht bisher nur bei einzelnen Geräten? Von sehr vielen HmIP-Geräten ist ja noch immer keine aktuelle Firmware im Download erhältlich (mit der ehemaligen Begründung, man müsse die Geräteupdates nochmal überarbeiten und an die neue Funktion zum automatischen Übernehmen der Datenpunkte bei Update erst noch anpassen).

[blackhole]

[ Sorry, diesen Beitrag hatte ich gestern fälschlicherweise im Thread zur CCU2-Firmware v2.47.15 erstellt.¯\_(ツ)_/¯ ]

Mir ist gestern ein im Vergleich zur Vorgänger-Firmware erhöhter Duty-Cycle-Wert -unter vergleichbaren, "ruhigen" Bedinungen- aufgefallen. Nach heutigen Nachforschungen bin ich erneut auf die immer noch nicht zurückgeschraubten zyklischen Aufrufe von setHWClock.sh und SetInterfaceClock gestoßen.

An dieser Stelle also noch einmal der Weg für die Korrektur der zyklischen Aufrufe von setHWClock.sh und SetInterfaceClock auf die seit vielen Jahren bewährten Default-Werte von eQ-3:

1. Partition beschreibar machen:

   Code: Alles auswählen

   mount -o rw,remount /

2. Editieren von /etc/crontab.root und die ersten zwei Zeilen wie folgt anpassen:

   Code: Alles auswählen

   12 4 * * * /bin/setHWClock.sh >/dev/null 2>/dev/null
   14 4 * * * /bin/SetInterfaceClock

3. Partition wieder schreibschützen:

   Code: Alles auswählen

   mount -o ro,remount /

4. Crond neustarten:

   Code: Alles auswählen

   /etc/init.d/S98crond restart

5. Abschließende Kontrolle mittels:

   Code: Alles auswählen

   crontab -l

Etwa eine Stunde nach der Korrektur, war der Duty-Cycle-Wert wieder meiner Installation angemessen.