Firmware Upgrade von HM-LC-Dim1T-PI-3 fehlgeschlagen [erledigt]

[cybtrash]

Hallo,

in meinem jugendlichen Leichtsinn / Ignoranz des "Never touch a running system" habe ich gestern Abends noch ein Firmware Update beim HM-LC-Dim1T-PI-3 Dimmer von Homematic gestartet (hatte 2.8, wollte auf 2.9.5). Leider ist das Update fehlgeschlagen. Meine Zentrale ist ein Raspberry Pi mit CUL und der TS-FW 0.31.

Im Log steht folgendes:

2019.08.03 00:07:10 2: CUL_HM fwUpdate started for StromDose
2019.08.03 00:07:10 3: CUL_HM set StromDose fwUpdate /home/pi/HM-LC-Dim1T-Pl-3_update_V2_9_0005_150730.eq3
2019.08.03 00:07:10 2: CUL_HM fwUpdate StromDose entered mode. IO-speed: fast
2019.08.03 00:07:11 3: TSCUL_ParseTsHM: CUL0 HM NO NUFFER FREE to 394297/StromDose:  482269 A FF86 00183932 00 27 1B 00CA ABC101 394297 C19E8B12E2B115869C26ED1B880E180FCAB491D9C9BC64B92680CC665689 _fup _sfail
2019.08.03 00:07:11 2: TSCUL_condUpdateHM: CUL0 new condition ERROR-Overload
2019.08.03 00:07:11 3: TSCUL_ParseTsHM: CUL0 HM NO NUFFER FREE to 394297/StromDose:  482296 A FF86 00183932 00 0F 1C 20CA ABC101 394297 93E004EF9053 _fup _sfail
2019.08.03 00:07:11 2: TSCUL_condUpdateHM: CUL0 new condition ok
2019.08.03 00:07:16 2: TSCUL_condUpdateHM: CUL0 new condition ERROR-Overload
2019.08.03 00:07:16 2: TSCUL_condUpdateHM: CUL0 new condition ok
2019.08.03 00:07:17 3: LogHist CUL0:  482443 A F783 00184100 01 27 17 00CA ABC101 394297 B7B0E99D71A7984265A096C9E33DBE2FF5BFAA02238F6E114B26ED553BEF _fup _CCAdly:4 _dhmSt:192
2019.08.03 00:07:17 3: LogHist CUL0:  482466 A F783 00184124 01 27 18 00CA ABC101 394297 F86E0677A6B7E1FBA7EA73632DF30132FB37659ABADBCAC3B7793E9FF5AF _fup _CCAdly:4 _dhmSt:216
2019.08.03 00:07:17 3: LogHist CUL0:  482491 A F783 00184148 01 27 19 00CA ABC101 394297 D0077326139EC3B681A3AF53ADEC15ADEB50FD03A11AD945CF816746CCCA _fup _CCAdly:4 _dhmSt:240
2019.08.03 00:07:17 3: LogHist CUL0:  482513 A F783 00184172 01 27 1A 00CA ABC101 394297 CA00F1FA25062E29687D0DFDFA82A0A5B100414DE78AED500E31C380F0C8 _fup _CCAdly:4 _dhmSt:264
2019.08.03 00:07:17 3: LogHist CUL0:  487280 A F783 00188936 01 27 13 00CA ABC101 394297 01122BA04B7FEC07CA6CB6454E05B5DF823A242D7B4C14737384999D63DA _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487302 A F783 00188960 01 27 14 00CA ABC101 394297 FF70B4D81F2EBD4E1268DA3E0DD7DF6398BC2A25DA360F134D231EB34691 _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487326 A FF83 00188984 01 27 15 00CA ABC101 394297 B3505B05CCA790B493FD95A30B2F1EDCF7015C23E18A6DE685403C39648F _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487350 A F783 00189008 01 27 16 00CA ABC101 394297 4532690D6FBE149F4E0DB35FCDC665F29428B14D62AB3311F9F319616C23 _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487374 A F783 00189032 01 27 17 00CA ABC101 394297 B7B0E99D71A7984265A096C9E33DBE2FF5BFAA02238F6E114B26ED553BEF _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487398 A F783 00189056 01 27 18 00CA ABC101 394297 F86E0677A6B7E1FBA7EA73632DF30132FB37659ABADBCAC3B7793E9FF5AF _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487422 A F783 00189080 01 27 19 00CA ABC101 394297 D0077326139EC3B681A3AF53ADEC15ADEB50FD03A11AD945CF816746CCCA _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487446 A F783 00189104 01 27 1A 00CA ABC101 394297 CA00F1FA25062E29687D0DFDFA82A0A5B100414DE78AED500E31C380F0C8 _fup _CCAdly:4
2019.08.03 00:07:17 3: LogHist CUL0:  487470 A F783 00189128 01 27 1B 00CA ABC101 394297 C19E8B12E2B115869C26ED1B880E180FCAB491D9C9BC64B92680CC665689 _fup _CCAdly:4

Das Gerät jetzt blinkt nur noch sehr schnell mit der roten LED, es hängt warscheinlich im Bootloader-Modus fest?

Weitere Update-Versuche schlagen fehl mit der gleichen Meldung.

Jetzt habe ich zwei Ideen, wie ich das Gerät noch selbst retten könnte:

1) Das Gerät ist ja noch auf meinem Raspberry gepeert gewesen (ohne AES). Von einem Kumpel könnte ich mir seine CCU-3 ausleihen, an FHEM anbinden und dann versuchen, über die CCU-3 als IO-Device das Firmware-Update zu starten? Direkt von der CCU wirds ja nicht gehen, weil das Gerät dort nicht angebunden ist. Das Gerät lässt sich in diesem Zustand jetzt ja nicht mehr neu peeren.

2) Das Gerät manuell flashen? Es gibt ja den "Asksin_OTA_Bootloader" (https://github.com/kc-GitHub/Asksin_OTA_Bootloader), mit dem man eine alternative FW auf einen anderen HM-Aktor laden kann. Ggf. kann ich hiermit die Firmware-Datei auf den Dimmer manuell laden über eine Kabelverbindung? Löten / AVRdude Sachen sind mir ein Begriff, da ich viel mit Arduino etc spiele. Leider weiss ich nicht genau, wo ich was anschließen muss. Könnt ihr mir helfen?
Also welche Raspberr GPIO Pins soll ich wo anschließen / anlöten auf der Platine? Es gibt ein paar freie Flächen mit der Bezeichnung "PRG1", das klingt doch verdächtig?

Hier zwei Fotos:

[MadMax-FHEM]

Einbindung über CCU3 als IODev wird nicht gehen, weil CCU3 nicht einfach ein IODev ist (soweit ich weiß) sondern die Einbindung in fhem per HMCCU-Modul geschieht.
Ganz andere Baustelle...

Wenn das Gerät noch in der CCU vorhanden ist, du keinen Reset (oder ablernen) vor dem Einbinden in fhem gemacht hast, dann sollte es direkt über die CCU3 auch gehen...

Deine Anmerkung bzgl AES ist mir unklar...
...hast du nun AES oder nicht!?
Weil wenn du AES (mit eigenem Schlüssel) hast, wird es mit der CCU3 wohl nicht (mehr) gehen...

Auch nicht, wenn sich die HMID zur CCU3 unterscheidet (siehe Reset bzw. ablernen)...


Deinen 2. Weg kann ich nicht einschätzen...

Aber so wie ich die Meldung beim schnell drüber fliegen gedeutet hab ist der erste Versuch wegen "overload" abgebrochen...

Warten bis wieder "Funkluft" da ist (1% Regel) und dann noch mal versuchen!?

Wie ist die Verbindung von CUL (davon halte ich NIX!!) zum Gerät.
Nicht, dass die zu schlecht ist, Telegramme (zu oft) wiederholt werden müssen -> overload...

Evtl. (wenn nicht schon getan) eine vccu definieren und ein HMOD-PCB besorgen (20€) und den danm als (zusätzliches) IO und dann darüber den FW-Update...

(und den CUL gleich rauswerfen)

Gruß, Joachim

[cybtrash]

Danke MadMax.

Einbindung über CCU3 als IODev wird nicht gehen, weil CCU3 nicht einfach ein IODev ist (soweit ich weiß) sondern die Einbindung in fhem per HMCCU-Modul geschieht.
Ganz andere Baustelle...

Ok, schade...

Wenn das Gerät noch in der CCU vorhanden ist, du keinen Reset (oder ablernen) vor dem Einbinden in fhem gemacht hast, dann sollte es direkt über die CCU3 auch gehen...

Das Gerät ist bisher nur in "FHEM" angelernt worden über das CUL. Ich habe keine CCU von eq3, ich könnte mir aber eine ausleihen, nur das bringt dann scheinbar nicht viel.

Deine Anmerkung bzgl AES ist mir unklar...
...hast du nun AES oder nicht!?
Weil wenn du AES (mit eigenem Schlüssel) hast, wird es mit der CCU3 wohl nicht (mehr) gehen...

Nein, für das Gerät hatte ich keinen AES-Schlüssel eingetragen.

Evtl. (wenn nicht schon getan) eine vccu definieren und ein HMOD-PCB besorgen (20€) und den danm als (zusätzliches) IO und dann darüber den FW-Update...

Das wird dann wohl meine nächste Option werden, wenn ich keine Ideen finde bezüglich des direkten Flashens über Kabelverbindung.

[MadMax-FHEM]

Einfach warten und noch mal probieren wäre meine erste Option an deiner Stelle...

Poste doch mal ein list von dem Gerät, nur um zu sehen was die RSSI etc. machen...

Hast du hminfo definiert?

Da kannst du dir auch mal den "Kommunikationszustand" ausgeben lassen...

Gruß, Joachim

[cybtrash]

Das hatte leider wieder nicht geklappt.

Aber ich habe dieses Linux-Tool "hmcfgusb" gefunden und damit hat es sofort funktioniert !

Ich freue mich, dass es wieder funktioniert und lasse erst mal die Finger von solchen Aktionen..