HM-TC-IT-WM-W-EU Firmwareupdate fehlgeschlagen

Begonnen von edition, 13 Dezember 2016, 16:02:44

Vorheriges Thema - Nächstes Thema

edition

Hallo zusammen

Wie im Titel beschrieben, habe ich versucht, bei einem TC ein Firmwareupdate durchzuführen, weil die Einstellungen für die Hysterese nicht zu ändern waren.
Ich habe dazu auf der eQ3 Homepage die aktuelle Firmware heruntergeladen und ins fhem Verzeichnis meines Raspberry Pi kopiert. Unter fhem habe ich dann set <HM-TC-xxx> fwUpdate und den Dateinamen der tar.gz Datei angegeben, nachdem ich den TC zuvor in den Updatemodus versetzt habe. Es erschien eine Fehlermeldung, die ich als falsche Dateigröße gewertet habe. Also habe ich das Archiv entpackt und nur die eq3 Datei ins fhem Verzeichnis kopiert. Nachdem ich den Vorgang erneut an gestartet habe, schien es zu funktionieren.
Am Ende scheint das Update aber nicht gelungen zu sein, weil im Display des TC nun CrC steht. Auch das Entfernen der Batterien und das löschen aus fhem brachte keinen Erfolg.
Kann ich das Teil nun noch retten, oder habe ich es zerstört?

Gruß
edition

Pfriemler

Ist zwar nicht genau das Gerät, aber guck doch mal in diesem Beitrag nach möglichen Stolperfallen.

Firmwareupdates sind bei mir u.a. fehlgeschlagen, wenn ich von meinen beiden IOs HMLAN und HMUART ersten nicht offline gesetzt habe.

Die wichtigste Botschaft sollte aber sein: Ja, das Ding ist noch zu retten.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

automatisierer

Womit hast du versucht das Update aufzuspielen? HMlan geht meines Wissens nach nicht.

edition

#3
Vielen Dank für die raschen Antworten.
Wenn ich mir den von Pfriemler empfohlenen Beitrag ansehe, lag ich also mit dem entpacken des Archivs nicht falsch (das war meine größte Sorge).
Allerdings habe ich das Gerät mittlerweile aus der Konfiguration gelöscht, sodass ich es nicht einfach noch mal versuchen kann um dann den Datenverkehr zu sniffen. Ich müsste erst mal neu pairen. Aber wie?

Ich habe eine gesicherte fhem.cfg von August. Da ist das Gerät noch vorhanden. Kann ich die dazugehörigen Zeilen einfach in die aktuelle fhem.cfg einfügen, um das Gerät wieder einzubinden?

Ich nutze übrigens einen Pi mit aufgestecktem SCC im Homematic Modus.

edition

edition

#4
Ich habe einfach einmal versucht, die Zeilen aus der gesicherten fhem.cfg in die aktuelle einzufügen.
Das Gerät ist jetzt wieder vorhanden. Wenn ich nun das Update ausführe, erscheint im Eventmonitor folgendes:
2016-12-14 16:17:23 CUL_HM Temp_Feuchte_Partyraum CMDs_FWupdate
2016-12-14 16:17:23 CUL_HM Temp_Feuchte_Partyraum set_fwUpdate hm_tc_it_wm_w_eu_update_V1_3_002_150827.eq3
2016-12-14 16:17:33 CUL_HM Temp_Feuchte_Partyraum fwUpdate: fail:notInBootLoader
2016-12-14 16:17:33 CUL_HM Temp_Feuchte_Partyraum CMDs_done_FWupdate


Ein weitere Versuch mit 30sec. Wartezeit ergibt:

2016-12-14 16:26:27 CUL_HM Temp_Feuchte_Partyraum CMDs_FWupdate
2016-12-14 16:26:27 CUL_HM Temp_Feuchte_Partyraum set_fwUpdate hm_tc_it_wm_w_eu_update_V1_3_002_150827.eq3 30
2016-12-14 16:28:53 CUL_HM Temp_Feuchte_Partyraum fwUpdate: fail:Block185
2016-12-14 16:28:53 CUL_HM Temp_Feuchte_Partyraum CMDs_done_FWupdate


Ist die Datei nicht in Ordnung, oder ein Übertragungsfehler?

Beta-User

Hallo,

versuch's doch mal damit (aus dem Wiki zum HM-ES-TX-WM):
Firmwareupdate

Das Gerät lässt sich in den Updatemodus versetzen, im dem die Batterien zunächst entfernt, dann beim Einsetzen die Anlerntaste gedrückt bleibt. die Leuchtdiode blinkt dann rot im schnellen Takt. Das FHEM-Kommando zum Senden der Firmware per set <devicename> fwUpdate <Firmwaredatei.eq3> muss vor dem Einlegen der Batterie (+ ">" Taste) aufgegeben werden. Erfolgt zum Zeitpunkt des Anstartens im Updatemodus keine Sendung der Firmware wird der Zählersensor normal gebootet. Die Meldung <devicename> fwUpdate: fail:notInBootLoader im Filelog erscheint, wenn das FHEM fwUpdate Kommando zu spät gesendet wurde.

Der Update dauert etwa eine Minute. Während des Updates blinkt die Diode rot in kurzen Intervallen. Nach erfolgreichen Update muss der Sensor auf die Werkseinstellungen zurückgesetzt (">" Taste 4 Sekunden drücken (Display zeigt reS), kurz warten, ">" noch mal 4 Sekunden drücken - Zählersensor rebootet), aus der FHEM Konfiguration entfernt und neu angelernt werden.


Das mit dem Entfernen aus der config würde ich allerdings erst mal lassen, evtl. reicht ein einfaches pairen.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

edition

Ich habe die Wartezeit beim ersten Versuch nicht angegeben. Ein Versuch mit Wartezeit ergibt eine Fehlermeldung (siehe oben).

@Beta-User

Ich wollte das Gerät wieder hinzufügen, weil ich es zuvor entfernt hatte. Pairen ging ja nicht, weil das Gerät ja nicht startet, aufgrund des fehlgeschlagenen Updates.

Beta-User

OK, da hat sich wohl was überschnitten.

Meine Anleitung war dafür, dass man das Teil überhaupt erst mal wieder in den update-Modus bekommt. Das hat ja offensichtlich schon ohne die Anleitung geklappt.
Das mit Dem Löschen war aus der zitierten Anleitung und macht - jedenfalls bis zu einen erfolgreichen Update - m.E. keinen Sinn, ein einfaches Neupairen sollte eigentlich ausreichen.

Ansonsten teile ich die Vermutung, dass das update-file korrupt ist. Also nochmal ruterladen und entpacken. Evtl. ist es auch ein Problem aus der Funk-Ecke (zu nah oder weit vom HMUART weg)....

Viel Erfolg jedenfalls noch.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

edition

Ok, ich habe die Datei vom raspberry gelöscht, neu von der eq3 Seite geladen, entpackt und die eq3 Datei wieder auf den raspberry ins fhem Verzeichnis kopiert. Die Dateirechte habe ich auf 777 gesetzt und die Einstellungen für verbose etc. wie im Empfohlenen Beitrag eingestellt.
Jetzt habe ich den Fehler bereits im Block 2. Im Eventmonitor sind immer nur die 4 Zeilen zu sehen, die oben schon angegeben sind. Im Log steht dagegen wesentlich mehr. Allerdings kann ich damit nicht allzuviel anfangen. erschwerend kommt dazu, das hier nebenbei alle Rollläden runtergefahren sind. Ich poste dennoch einmal was dort steht. Vielleicht kann das ja jemand zerlegen und den Fehler finden.
2016.12.14 16:59:24 5: CUL_HM Temp_Feuchte_Partyraum protEvent:CMDs_FWupdate
2016.12.14 16:59:24 2: CUL_HM fwUpdate started for Temp_Feuchte_Partyraum
2016.12.14 16:59:24 4: CUL_send:  SCCAs 0A 0A 3011 000FFF 39C631 CA
2016.12.14 16:59:24 3: CUL_HM set Temp_Feuchte_Partyraum fwUpdate hm_tc_it_wm_w_eu_update_V1_3_002_150827.eq3 30
2016.12.14 16:59:26 4: CUL_Parse: SCC A 0B 90 A258 18DC5C 1918CE 000027 -54.5
2016.12.14 16:59:26 4: CUL_Parse: SCC A 0E 90 8202 1918CE 18DC5C 010100003B41 -41.5
2016.12.14 16:59:31 4: CUL_Parse: SCC A 14 00 0010 39C631 000000 004D45513036303533303218 -62
2016.12.14 16:59:31 2: CUL_HM fwUpdate Temp_Feuchte_Partyraum entered mode. IO-speed: fast
2016.12.14 16:59:31 4: CUL_send:  SCCAs 0F 0B 00CB 000FFF 39C631 105B11F81547
2016.12.14 16:59:31 4: CUL_send:  SCCAR     
2016.12.14 16:59:31 5: CUL_HM fwUpdate write block 1 of 213: 10 messages
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 0D 00CA 000FFF 39C631 012263EE8C0DCB3CC8A28A4B3E3D48E75E304E06E44559325D179FFC1608
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 0E 00CA 000FFF 39C631 BFCC4F142002B8C96AA4035B994A7901E7ECE06338A6FC2E361DBFDBAECA
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 0F 00CA 000FFF 39C631 2F5BACC5BCFE7DE6118A37F0A064DAB198049A37A25DCEB8D40016BB60CD
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 10 00CA 000FFF 39C631 A25EDA95B19A7B88E90CB55CA1AB05E604B61CF4A20CB7AF6DFB6FB384E2
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 11 00CA 000FFF 39C631 4B05B9CD5A136323BAB425A1883A70A218FE4319386CDDAEAA22EF40AAD2
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 12 00CA 000FFF 39C631 B58BE1230B95A8B70E32590064358A6FEF50E7D34FCBF8ACB6AD5F7E1898
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 13 00CA 000FFF 39C631 0F9F4E9175212202DFDD66F0A8C960C9A5102B9F8D2C962474AB1942E474
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 14 00CA 000FFF 39C631 91AD2E504DF6CCFD18C99AB04E02D54FFA5C3A08152E897D6B517626808C
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 15 00CA 000FFF 39C631 5ED6E557079B8CFF6CE1345B040F2C452C37E2972140F701EFAD9920A336
2016.12.14 16:59:31 4: CUL_send:  SCCAs 1F 16 20CA 000FFF 39C631 390BE8B601AD77697BB09C7ADD5089D5AD248EAAD5D6
2016.12.14 16:59:31 5: CUL_HM fwUpdate write block 2 of 213: 10 messages
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 17 00CA 000FFF 39C631 0122FFF43CD8F68FA590563C5E25F007344E09CD65416F698E7B493313FD
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 18 00CA 000FFF 39C631 800D62032488B1A1C9B0205C2259F2D6E2782E16411CEFFE2F74FBD4CA28
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 19 00CA 000FFF 39C631 C0F6C7284D9F703CF5B493BB721AF6BFD242BC33202527C34CED275700A4
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 1A 00CA 000FFF 39C631 F196F9579343C0E3F911EA570341376A99115FCF96FB8D4E44EDC7A0530B
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 1B 00CA 000FFF 39C631 B47838F55F035EA49FC2DBB84A63A4BC7D43DD83F1F3AF312A79F676A71F
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 1C 00CA 000FFF 39C631 A1F354DEBC80C34580EA2B7B4DC2FE984B78A76510CB19C261C1F17894D2
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 1D 00CA 000FFF 39C631 9F44BE00387F99CC943D7BB22903E335E02CA956271C888364EF9180D308
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 1E 00CA 000FFF 39C631 3DD6F319AE50554C9B7EF1BB1615386336C8015F7DB414FCB245D33192DE
2016.12.14 16:59:31 4: CUL_send:  SCCAs 27 1F 00CA 000FFF 39C631 CCB10F6CB0A3EE7CB12329E0962A7559AE4C3D678BE0200A79DB7A4322B1
2016.12.14 16:59:31 4: CUL_send:  SCCAs 1F 20 20CA 000FFF 39C631 903D98AC5B924375761F565528A8496C624E22C01FD0
2016.12.14 16:59:36 4: CUL_send:  SCCAr     
2016.12.14 16:59:36 5: CUL_HM Temp_Feuchte_Partyraum protEvent:CMDs_done_FWupdate
2016.12.14 16:59:36 2: CUL_HM fwUpdate Temp_Feuchte_Partyraum end. IO-speed: normal
2016.12.14 16:59:49 4: CUL_Parse: SCC A 0C F6 8670 113D92 000000 00D2380E -67
2016.12.14 16:59:55 4: CUL_Parse: SCC A 0C 7F 8470 432E60 000000 009B44F3 -80.5
2016.12.14 16:59:58 4: CUL_Parse: SCC A 0C D1 8670 180A7D 000000 00DB3617 -62.5

Otto123

Hi,

und auch immer dran denken: der IO darf nicht im Overload stehen!

Ansonsten siehe auch hier meine Notizen.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

TomWest

Hi,

Firmware Updates fand ich auch immer schwierig. Im ersten Versuch hat es fast nie geklappt. Bei mir lag es auch an der Entfernung zum CUL, ich habe jetzt einen Platz gefunden, an dem es funktioniert und lege alle HM Geräte dort ab. Auch zu nah kann Schwierigkeiten machen!

Ich musste auch immer mit der Verzögerung beim Update arbeiten, dann am TC Batterien raus und den Update Modus gestartet. Irgendwann ging es dann.

Viel Erfolg,
Thomas
FHEM on R-π - HM-TC-IT-WM-W-EU - HM-LC-Sw1-FM - HM-SCI-3-FM - HM-CC-RT-DN

Otto123

Zitat von: TomWest am 15 Dezember 2016, 09:07:36
Ich musste auch immer mit der Verzögerung beim Update arbeiten, dann am TC Batterien raus und den Update Modus gestartet. Irgendwann ging es dann.
Das ist aber beim normalen Update normalerweise überhaupt nicht notwendig! -> https://wiki.fhem.de/wiki/HomeMatic_Firmware_Update.
Vor allem nicht beim HM-TC-IT-WM-W-EU.

Nur wenn es schief ging...

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Joker

Ich hatte mit den Firmwareupdates auch schon meine liebe Not, aber bisher lies sich am Ende jedes Device erfolgreich flashen.

Wenn Du jetzt immer ein "fwUpdate: fail:Blockxxx" kriegst ist das Device zumindest im Bootloader und das Update läuft an. Und die Datei OK ist (hast du ja schon neu entpackt etc) dann kann es eigentlich nur an der Übertragung liegen (war bei mir auch schon öfters so).
Das Gerät mal auf ca. 1m an das IO ran bringen, dann sollte es klappen (ich habe da auch ab und an mehrere Versuche gebraucht).

frank

kann deine fw des scc überhaupt in den 100k modus für das update umschalten? soweit ich mich erinnere, müsste nach jeder übertragung eines blocks, jeweils ein ack des tc-it zu sehen sein. diese fehlen hier aber in deinem log.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

edition

Ich hoffe doch, das mein SCC für Firmwareupdates geeignet ist. Auszug aus den Internals:
VERSION  V 1.66 CSM868