Firmwareupdate- was ist wirklich zu tun

[starry99]

Servus!
In Sachen Firmware-Update auf HM-IP Komponenten habe ich schon die unterschiedlichsten Vorgangsweisen gehört:
Von einfach Update starten und gut ist bis hin zu Werksreset auf allen Teilen, löschen aller Daten/Programme/Verknüpfungen und "neu anfangen". Zweiteres mag ich kaum glauben, da das in größeren Systemen ja Unmengen an Arbeit bedeuten würde....
Oder merkt sich die CCU (oder das Thermostat?) meine Einstellungen??

Darf ich daher höflichst um eine Klarstellung bitten, was nun wirklich in welcher Reihenfolge zu tun ist und vor allem warum.

Konkret geht es um etliche HMIP-eTRV, die von 1.6.3 auf 2.0.2 gebracht werden sollen.
Auf die CCU2 mit 2.31.25 wurde die neue FW-2.0.2. hochgeladen und die Thermostate bieten mir den Update unter Einstellungen->Geräte->"ThermostatX" > Einstellungen als verfügbares Update an.
Was nun?

Zusatzfrage: Macht es einen Unterschied ob die Thermostate nur ihr eigenes Wochenprogramm abfahren ODER in div. Direkt-Verknüpfungen und/oder Programmen enthalten ist?

Vielen Dank im Voraus!

[Roland M.]

Hallo!

Von einfach Update starten und gut ist bis hin zu Werksreset auf allen Teilen, löschen aller Daten/Programme/Verknüpfungen und "neu anfangen".

Als Faustregel kann man sagen: wenn bei einem Firmwareupdate neue Funktionen hinzukommen, ist das Gerät von der CCU ab- und neu anzumelden. Ob man da einen Werksreset des Gerätes gleich mit macht, ist kein zusätzlicher Aufwand mehr und gibt mehr Sicherheit.
Natürlich sind beim Ablernen von der CCU die Programm betroffen. Und ja, das ist je nach Installation viel Aufwand, die wieder einzurichten bzw. adaptieren.

Auf die CCU2 mit 2.31.25 wurde die neue FW-2.0.2. hochgeladen und die Thermostate bieten mir den Update unter Einstellungen->Geräte->"ThermostatX" > Einstellungen als verfügbares Update an.
Was nun?

Na ja, wenn du schon die FW hochgeladen hast, wirst du ja einen Grund dazu gehabt haben!
Im Ernst, bei Geräte-FW bin ich eher vorsichtig.
Ich lese mir da immer das Change-Log durch, ob Fehler behoben werden, die auch mich betroffen haben, oder ob neue Funktionen dazugekommen sind, die für mich interessant sind.
Wenn nein, dann lass ich auch einmal Fünf gerade sein.

Zusatzfrage: Macht es einen Unterschied ob die Thermostate nur ihr eigenes Wochenprogramm abfahren ODER in div. Direkt-Verknüpfungen und/oder Programmen enthalten ist?

Bei den Heizungsreglern und Wandthermostaten gibt es eigentlich nur drei Zustände:
- der Heizungsregler arbeitet selbstständig (Wochenprogramm)
- der Heizungsregler bekommt vom Wandthermostat als Master seine Befehle (Direktverknüpfungen)
- ein Programm auf der CCU gibt die Solltemperaturen vor

Aus meiner Sicht sollte man versuchen, die Geräte alleine arbeiten zu lassen (egal ob als Gruppe mit einem Raumthermostaten oder ohne) und nur in Ausnahmefällen die CCU das eingestellte Wochenprogramm übersteuern zu lassen - Beispiel Schichtdienst: "Schalte morgen die Heizung früher (als üblich) ein".
Nicht nur bei den Heizungsreglern, sondern auch bei Lichtschaltungen sind daher Direktverknüpfungen zu bevorzugen und Programme nur dort einzusetzen, wo DV nicht mehr alleine zum Ziel führen.

Die Kunst der Hausautomation ist aus meiner Sicht, das System so zu installieren, dass möglichst viele Komponenten ausfallen dürfen, ohne das es zu wesentlichen Beeinträchtigungen kommt. Der Ausfall der CCU ist so eine Sache...


Roland

[Familienvater]

Hi,

wenn im Changelog der Gerätefirmware steht, das man das Gerät nach dem Update Ab- und wieder Anlernen soll, dann würde ich das auch so machen, sonst macht das nämlich die Zentrale "irgendwann unangekündigt" von selbst, und das ist immer der Moment, wo man es am wenigsten braucht. Das gleiche gilt leider auch, wenn im Changelog der Geräte-Firmware nichts zum Thema Ab- und wieder Anlernen steht, der nächste oder übernächste Neustart der Zentrale wird Dir dann zeigen, ob es wirklich nicht notwendig war, oder ob es nur vergessen wurde, den Hinweis in das Changelog zu packen.
Und egal ob Du oder die Zentrale den Aktor ablernt, dabei fliegt er aus allen Programmen/DVs etc. raus, und Du musst Dir vorher merken, wo der überall drin war.

Aus der Erfahrung mit einem HmIP-BSM würde ich inzwischen immer zusätzlich nach dem Ablernen einen "lokalen" Werksreset am abgelernten Gerät machen, auch wenn das angeblich beim Ablernen von der Zentrale automatisch passiert, bei meinem BSM ist ein lokaler Werksreset ein echter Werksreset gewesen, das Ablernen war eher ohne Werksreset, da haben teilweise noch von mir verschlimmbesserte Konfig-Optionen im Aktor selbst überlebt.

Das das alles nicht Optimal ist, weiß auch EQ3, und die arbeiten an einer Lösung. Wann die fertig ist, und wie fehlerfrei die dann funktionieren wird, steht in den Sternen. Da Du das Update schon auf dem Aktor hast, liegt es in Deinen Händen, den "Update" Knopf zu drücken, um die Firmware im Aktor zu aktvieren, danach hast Du wahrscheinlich auf jeden Fall einen Haufen Arbeit vor Dir...

Der Familienvater

[NickHM]

Guten Morgen

es gibt zu dem Thema nichts offizielles. Du könntest natürlich noch mal eq-3 anschreiben und fragen.

Es gibt Erfahrungswerte. Und das Ergebnis ist , wie oben schon beschrieben, eine mittlere Katastrophe, weil die Zustände nicht nachvollziehbar scheinen.

Meine Erfahrung mit verschiedenen HMIP Geräten nach FW Update
- nach dem Update startet das Gerät neu und kann ganz normal in der Geräteliste sein oder auch im Posteingang. Manchmal auch erst nach einem CCU Neustart im Posteingang.
- wenn unter Einstellungen / Geräte noch etwas zu sehen ist, kann man das Risiko eingehen und nichts weiter tun. Meist ist dort eine Seite "keine Parameter einstellbar"
- Ablernen des Gerätes geht bei HMIP nur mit Werkreset.
- Nach dem Ablernen ist das Gerät nicht aus der Geräteliste raus. CCU- Neustart.
- Am Gerät selbst einen Werkreset durchzuführen kann nicht schaden und das Gerät ist gleich wieder im Anlernmodus. Da habe ich erlebt, dass das Gerät wieder in der CCU auftaucht (ggf. Posteingang) ohne das ich auf der CCU den Anlernvorgang gestartet habe.
- das Gegenteil gab es auch, Gerät lässt sich offenbar nicht anlernen. Dann nach dem CCU Neustart warten bis des DC runter ist, Werkreset am Gerät , anlernen

Jedenfalls habe ich noch keine funktionierende Technik gefunden, die einen zuverlässigen Arbeitsablauf ergibt. Klar ist bei mir, dass auch mehrmaliges Löschen des Gerätes in der CCU nichts bewirkt, auch nicht mit Abmelden. Erst ein Neustart räumt die Geräteliste auf. Das Gerät kann unter Einstellungen Geräte oder unter Status / Bedienung sichtbar bleiben, ganz weg war es selten.

In den Programmen kann man vorher das Gerät durch ein anderes ersetzen. Als Platzhalter. Dann ist wenigstens das Programm nicht kaputt. Hinterher einfach wieder den Dummy gegen das Original austauschen.
Die Direktverknüpfungen aufschreiben oder ausdrucken.

Ob es besser ist, vorher alle Direktverknüpfungen zu löschen, damit diese auch aus den Partnern raus sind, kann ich nicht sagen. Ich hatte bisher keine HMIP Geräte mit Direktverknüpfungen, da ich versuche HMIP zu vermeiden, so weit möglich. Vielleicht schreibt die CCU ja auch die Direktverknüpfungen wieder in die neu angelernten Geräte, da in der CCU hinterlegt. Keine Ahnung.

Ansonsten geht es mir wie Familienvater. Unnötige Updates bei HMIP vermeiden.

IHMO war es sogar so, dass nach einem CCU Neustart oder nach einem Neustart des Gerätes die hochgeladene FW weg ist bzw. in der CCU nicht mehr angezeigt wird. Das bedeutet, nach dem nächsten Batterie Wechsel ist der Updatebutton verschwunden und die CCU fängt an die FW neu in das Gerät zu übertragen. Es sei denn, Du löschst die FW von der CCU.

[Roland M.]

Hallo!

Noch ein Nachtrag von mir: FW-Updates für gerade neu gekaufte Geräte erledige ich immer auf meiner Test-CCU. Da kann man herumspielen und testen, der DC ist relativ egal und da stört auch kein erzwungener CCU-Neustart. Wenn alles ok ist, wird das neue Gerät mit aktueller Firmware ins Produktivsystem gebracht.

Aber zugegeben, nicht jeder hat eine Test- (oder Backup-) CCU.


Roland

[Gluehwurm]

Man merkt ziemlich schnell, ob ein ab- und wieder anlernen notwendig gewesen wäre. Es funktioniert dann halt nicht mehr richtig. Um das von vornherein zu umgehen haben andere, und ich auch, die Prozedur empfohlen. Zwischenzeitlich scheint es (zumindest bei den Thermostaten) ohne zu gehen. Hier habe ich allerdings über den AP geupdatet, daher keine Erfahrung mit der CCU.

Zusatzfrage: Macht es einen Unterschied ob die Thermostate nur ihr eigenes Wochenprogramm abfahren ODER in div. Direkt-Verknüpfungen und/oder Programmen enthalten ist?

Jeder Schaltpunkt wird vom HK-Thermostat "abgefahren". In DVs (ausser beim TFK) sind keine Schaltpunkte enthalten, nur im verknüpften Wandthermostat oder verknüpften HK-Thermostat. Hier siegt jeweils der letzte.

Kann aber ziemlich einfach ausprobiert werden.

Gruß
Bruno

[starry99]

Danke für die vielen Antworten.
Es scheint in der Tat ein Trauerspiel zu sein.
Auch wenn ich im Bereich Homematic recht neu bin, darf ich doch auf viele Berufsjahre Heimautomation zurückblicken.
Daher finde ich es ja schon fast absurd, dass man sich mit diesem System auch an den Profi wendet. Welcher Gewerbebetrieb würde sich solch ein System antun, bei dem er nicht einmal vorher weiß, ob ein Firmware-Update (aus welchem Grund auch immer!) entweder 1 Stunde oder 2 Tage Arbeit bedeutet??!!

Zurück zum Thema: Ich gehe davon aus, dass der ganze Update-Prozess auf Seiten der CCU so abläuft, dass es für jede Kombination Produkt/FW-Stand sowas wie ein Config-File (z.B. XML) gibt, indem das Mapping der einzelnen Parameter sowie die Bezeichnung für das Web-GUI drinnensteht. = Was im HmIP_Device_Documentation.pdf drinsteht.

Die ganze Verwirrung vonwegen Geht/GehtNicht bzw. Ablernen/NichtAblernen etc. entsteht dann vielleicht aus einem oder mehreren der folgenden Faktoren:
* Funktion und/oder Bezeichnung eines Datenpunkts/Parameter wird geändert OHNE die (technisch) dahinterliegende Parameter-ID zu ändern.
Was also früher die Isttemp. war, ist nun der Öffnunggrad eines Thermostats (Extremfall ). Kuddelmuddel garantiert....
* Das Mapping, welches CCU-ConfigFile für welches Produkt verwendet wird, wird nur einmalig beim Anlernen hergestellt; die CCU bekommt also gar nicht mit, wenn sich die FW eines Aktors/Sensors geändert hat und verwendet weiterhin das "alte" Config-File = Mapping.
* Der Upgradeprozess im Sensor/Aktor selbst läuft so bescheiden ab, dass existierende Einstellungen nicht sauber in die (eventuell geänderten) Parameter-IDs zurückgeschrieben werden bzw. neue Datenpunkte saubere default-Werte bekommen.
* Das Wechseln des Config-Files für ein Gerät in der CCU wird nicht sauber in die bestehenden DV und Programme übernommen wie z.B. Verknüpfungen auf geänderte Datenpunkte umgebogen bzw. dem User eine konkrete Meldung ausgegeben, dass der Datenpunkt xyz in der neuen Version nicht mehr enthalten ist, er/sie also seine Logik umbauen muss.
* Der Prozess der Synchronisierung zwischen Gerät und CCU läuft nicht sauber ab, sodass man "bei null starten" muss, um die beiden Enden sicher auf gleichen Stand zu bringen.

Im Endeffekt ist es aber auch komplett egal. Es ist ein echtes Armutszeugnis für einen Hersteller sein System auf solch wackelige Beine zu stellen.

[Familienvater]

Hi,

was genau im Hintergrund abläuft, weiß von uns keiner, für HM-Devices gibt es die XML Device-config-Files, für HmIP nicht (ich habe zumindest noch nichts dahingehend gefunden). Ich gehe davon aus, das ein Teil der Informationen hardcoded im HmIP-Server vorliegt, und damit mit jedem Update des HmIP-Servers (also Firmwareupdate der Zentrale) ggf. die Rega beim Abgleich der "bekannten" Parameter auf einmal andere/neue/unbekannte Parameter erhält, und dann das Ding einfach "Zwangsabgemeldet" wird, um intern aufzuräumen und neu anzufangen.
Manchmal kann man das "nachvollziehen", wenn z.B. ein Gerät durch Firmwareupdate die Wochenprogramm-Schaltmöglichkeit bekommen hat, da gibt es einen komplett neuen Kanal.
Bei bestehenden Datenpunkten wäre sicherlich soetwas wie ein Map-File aus "Kanal:Datenpunkt ALT" wird "Kanal Neu:Datenpunkt NEU" die einfachste Möglichkeit (zumindest was das automatische Umstellen von WebUI-Klick-Programmen angeht, aber HM-Script KANN so eine Logik nicht korrigieren, dann müsste das als permanente Übersetzungtabelle im Hintergrund mitlaufen, immer wenn der alte "Name" angefragt wird, muss auf den neuen Übersetzt werden, gibt es dabei "Kollisionen", oder keine Eindeutigkeit, verloren...)

Der Familienvater

[Gluehwurm]

Es gibt die .dev-Files in "/usr/local/etc/config/crRFD/data", auf den HMIP-Server greifen die Teile bei Verwendung einer CCU wohl nur für eine Berechnung des Schlüssels mit dem Funkmodul zu. Die Datenpunkte bleiben (zumindest überwiegend )

Genaue Ursachen kenne ich nicht, allerdings muss man sich bei eq-3 immer bewusst sein, daß die Sachen sehr lange "Spielzeugcharakter" haben. Auch beim normalen HM hat es länger gedauert, bis es funktioniert. Mit HMIP habe die noch eine Schippe draufgelegt. Neue Technologie und verkaufen ist wichtig ...

[NickHM]

Guten Abend

eine Sache stimmt in jedem Fall, denn das ist nachvollziehbar

Die CCU bekommt bestimmte Parameter der HMIP Komponenten nur ein mal beim anlernen mitgeteilt. Das betrifft u.a. den FW Stand des Aktors / Sensors.
Ein gerät hat FW 1.0
Backup der CCU
Das Gerät bekommt FW 2.0
In der CCU steht zu diesem Zeitpunkt 2.0 da die CCU den Updatevorgang ja mitbekommen hat.
Das backup wird in die CCU zurück gespielt.
Das Gerät hat laut CCU wieder FW 1.0 und "Update verfügbar" wird angezeigt. Die CCU liest nicht den wirklichen Zustand des Gerätes aus.

Die ganze Problematik mit HMIP und FW Update kann auch an der Verschlüsselung liegen. Beim Anlernen wird da was berechnet und gespeichert. Vielleicht ist der Schlüsselteil im Gerät nach einem FW Update einfach weg, weil der Speicherbereich überschrieben wird.
Das sind aber alles nur Vermutungen. Wenn die alle als Frage an eq-3 bestellt werden sollten, müsste Kassel eine Woche dauern