flash-ota mit HM-CFG-USB2 produziert nur MISSING ACK

Begonnen von farion, 22 Januar 2016, 20:21:04

Vorheriges Thema - Nächstes Thema

farion

Hi,

habe einige HM-LC-Sw1PBU-FM mit der alternativen Firmware. Das initiale Aufspielen des Bootloaders und der Firmware habe ich per verlötet mit einem Raspberry gemacht.

Um einige Probleme mit der alternativen Firmware in den Griff zu bekommen würde ich mit dieser gerne ein wenig herumprobieren. Problem ist, ich kann offensichtlich nicht OTA flashen.

Ich habe einen HM-CFG-LAN und einen HM-CFG-USB2 an FHEM hängen (Raspi). Beide verwenden die gleiche hmid (die originalID des HM-CFG-LAN ... im Folgenden CXXXXX).

Um zu flashen gehe ich wie folgt vor.

(1) hmland stoppen => korrekterweise zeigt FHEM das auch an.

(2) per flash-ota die Firmware aufspielen
(DXXXXX ist die Id des HM-LC-Sw1PBU-FM)

Und das sieht dann so aus:



$ ./flash-ota -f /root/FIRMWARE_DXXXXX.eq3  -D DXXXXX -C CXXXXX
HomeMatic OTA flasher version 0.102-git

Reading firmware from /root/FIRMWARE_DXXXXX.eq3...
Firmware with 224 blocks successfully read.
usb-transfer took more than 100ms (2565ms), this may lead to timing problems!
HM-CFG-USB firmware version: 967, used credits: 37%


HM-CFG-USB opened

Entering 10k-mode
Sending device with hmid DXXXXX to bootloader

Missing ACK!

Missing ACK!

Missing ACK!

Missing ACK!
Failed to send device to bootloader, please enter bootloader manually.
Waiting for device with HMID DXXXXX


Interessanterweise geht die Lampe aus (falls sie vorher an war) sobald "Sending device with hmid DXXXXX to bootloader" kommt. Danach ist der Schalter auch "tot", weder manuell noch über FHEM lässt er sich steuern. Hilft nur den Strom wegzunehmen. Danach geht dann wieder alles. Also irgendwie scheint er schon den Modus zu wechseln. Die MISSING ACK kommen denke ich auch wirklich vom Schalter ... aber warum. Mit FHEM geht doch alles. Ideen?

Gruss Frieder
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

farion

Habe mal parallel zu Flashversuch den Event-Monitor mit dem HM-CFG-LAN laufen lassen und da bekomme ich 4x pro MISSING ACK so was hier:

2016-01-22 20:29:41 CUL_HM WZ.LichtSofa sabotageAttack_ErrIoAttack cnt: 40

Den Wert sieht man auch in den FHEM-Readings. Andere Schalter, die ich noch nicht versucht habe zu flashen haben das Reading nicht.

Der Schalter fühlt sich offensichtlich bedroht.
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

#2
ZitatDer Schalter fühlt sich offensichtlich bedroht.
nee. fhem merkt, dass du ein device durch ein fremdes io von ausserhalb attakierst.

edit:

Waiting for device with HMID DXXXXX
du musst den schalter in den bootloader schicken. steht sicher im wiki.
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

farion

#3
Hi,

die Hilfe von flash-ota sagt, dass das automatisch geht.

Optional parameters for automatically sending device to bootloader
   -C      HMID of central (3 hex-bytes, no prefix, e.g. ABCDEF)
   -D      HMID of device (3 hex-bytes, no prefix, e.g. 123456)
   -K      KNO:KEY AES key-number and key (hex) separated by colon (Fhem hmKey attribute)

Irgendwas passiert ja auch mit dem Schalter, weil wie gesagt, das Licht geht aus und die internen peers funktionieren auch nicht mehr.

Im Wiki (http://www.fhemwiki.de/wiki/HM-LC-Sw1PBU-FM_Alternative_Firmware#3._Bootloader_aktivieren) steht noch, Strom an und Config-Taster gedrückt halten ... hatte ich auch schon probiert, ergab aber das gleiche Ergebnis.
Ich werde das aber nochmal probieren, das hatte ich weniger oft wie das automatische Flashen gemacht.

PS: Ja was die Sabotage-Meldung sagt habe ich jetzt auch kapiert ... ich dachte noch dass vllt der LAN-Adapter irgendwie einen NACK schickt und habe darauf hin den LAN-Adapter vom Strom getrennt ... passiert das gleiche ... nur FHEM kriegts halt nicht mehr mit.
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

sniffe mal wie im wiki homematic sniffen beschrieben, dann ersparst du dir das spekulieren.  :)
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

farion

#5
2016.01.22 21:51:40.746 0: HMLAN_Send:  HMUSB1 S:S6B1B5B9A stat:  00 t:00000000 d:01 r:6B1B5B9A m:0A 3011 CXXXXX DXXXXX CA
2016.01.22 21:51:42.580 0: HMLAN_Parse: HMUSB1 R:R6B1B5B9A stat:0008 t:00000000 d:FF r:7FFF     m:0A 3011 CXXXXX DXXXXX CA
2016.01.22 21:51:42.582 0: HMLAN_Parse: HMUSB1 no ACK from DXXXXX


Es passiert das. Wenn ich das richtige interpretiere passiert also nichts ... der Schalter antwortet nicht?

Ich denke, dass ich den Schalter nicht in den Bootloader bekomme. Ich bekomme ihn in einen Status in dem er nicht mehr "normal" funktioniert, aber offensichtlich ist das nicht der Bootloader?

Edit: Das Ganze war jetzt übrigens per fhem gemacht und nicht per flash-ota ... ist aber das gleiche Verhalten.
In FHEM sehe ich auch noch das Reading: fwUpdate := fail:notInBootLoader

Wie komme ich in den Bootloader? Und in "was" wird der Schalter dann versetzt wenn ich per FHEM oder flash-ota versuche den Bootloader zu starten?
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

du musst das flashtool starten und wenn es auf den schalter wartet, dann setzt du ihn in den bootloader mit strom weg und taster gedrückt halten beim wiederanschalten. du hälst den taster am besten so lange, bis die led anfängt zu flackern. ab diesem moment sollte das übertragen beginnen.
am besten 2 m abstand zum hmusb. den hmusb eventuell zu beginn ab-/anstecken, damit er genügend credits hat.

ZitatIch bekomme ihn in einen Status in dem er nicht mehr "normal" funktioniert,
im bootloader funktioniert er nicht normal.
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

farion

Ich bin der Meinung, dass ich genau das schon probiert habe.

Allerdings fing bei mir die LED nie an zu leuchten ... habe bestimmt 30Sekunden gedrückt.

Da muss ich aber warten bis hier wieder jemand wach wird ... Sicherungskasten und Schalter sind 10m voneinander entfernt, das schaffe ich nicht alleine, da brauche ich Hilfe.

Der Abstand ist aktuell mehr ... ~6m ... habe eine rssi von -60 ... evtl. ist das das Problem? Gelesen habe ich dass es erst ab -70/-75 problematisch wird. Schalten geht auf die Entfernung zumindest. Müsste ich den Raspi zum Schalter tragen oder ne Linux VM anwerfen. Weil unter MacOSX geht der HM-CFG-USB2 ja leider nicht. Naja das kriege ich hin. Also 2m ...

Genug Credits hat der USB ... flash-ota startet den auch automatisch neu wenn nicht genug Credits da sind. Also erzählt es zumindest.

Das Problem mit diesem "nicht-normal" Modus ist ja aber, dass es laut FHEM und flash-ota eben nicht der Bootloader ist. Kann auch sein dass der Schalter da komplett weg ist. Weder die LED leuchtet noch sonst was, der ist komplett tot und zu senden scheint er ja dann auch nichts mehr ... sehr mysteriös.
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

am besten mal das in den bootloader setzen des schalters sniffen. da muss eine message vom schalter kommen. wenn die nicht kommt, brauchst du nicht weiter machen, da das flashtool nicht startet.
ich habe das flashen immer über das eq3-tool (windows) gemacht.
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

farion

Ich mache in FHEM:
set WZ.LichtSofa fwUpdate /tmp/FIRMWARE_DXXXXX.eq3

Logge das:

2016.01.22 22:55:41.009 0: HMLAN_Send:  HMUSB1 S:+DXXXXX,00,01,00
2016.01.22 22:55:41.012 0: HMLAN_Send:  HMUSB1 S:S6B55F4A2 stat:  00 t:00000000 d:01 r:6B55F4A2 m:0A 3011 CXXXXX DXXXXX CA
2016.01.22 22:55:42.873 0: HMLAN_Parse: HMUSB1 R:R6B55F4A2 stat:0008 t:00000000 d:FF r:7FFF     m:0A 3011 CXXXXX DXXXXX CA
2016.01.22 22:55:42.877 0: HMLAN_Parse: HMUSB1 no ACK from DXXXXX


Stelle fest:
- Das Licht geht aus
- Der Schalter ist in dem "nicht-normal"-Modus
- Reading: fwUpdate := fail:notInBootLoader

Tue mir etwas schwer den Log zu lesen. Vielleicht kannst du mir da bei der Deutung helfen. Am Ende kam auf jeden Fall wieder kein ACK. Die erste Zeile ist der Befehl das Gerät in den Bootloader zu schicken?
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

update über fhem funktioniert nicht mit dem schalter.
du sollst loggen, wenn der schalter spannung bekommt. das umschalten in den bootloader.
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

farion

Okay, habe jetzt eine Kombination aus Kugelschreiber und Gaffa-Tape bemüht um den Config-Knopf zu drücken.

Den USB-Adapter habe ich per hmland an FHEM gelassen und per "tail -f fhem-2016-01.log  | grep -i DXXXXX" nach logmeldungen Ausschau gehalten.

Ich habe zwei Versuche gemacht:

(1) Strom an den Schalter ohne Config-Knopf
Keine Nachricht. Schalter funktioniert normal (lässt sich über FHEM steuern).

(2) Strom an den Schalter mit Config-Knopf gedrückt halten während der Strom kommt.
LED leuchtet auch nach 1 Minute nicht auf. Keine Nachricht. Schalter funktioniert normal (lässt sich über FHEM steuern).
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

ich würde es nochmal ohne grep probieren. theoretisch kann der bootloader auch eine andere adresse haben.
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

farion

#13
2016.01.23 10:51:24.071 0: HMLAN_Parse: HMUSB1 R:EDXXXXX   stat:0000 t:02CB024D d:FF r:FFCC     m:00 A410 DXXXXX CXXXXX 0604000000
2016.01.23 10:51:24.239 0: HMLAN_Parse: HMUSB1 R:EEXXXXX   stat:0000 t:02CB026A d:FF r:FFC6     m:00 A410 EXXXXX CXXXXX 0604000000
2016.01.23 10:51:24.775 0: HMLAN_Parse: HMUSB1 R:EDXXXXX   stat:0000 t:02CB0508 d:FF r:FFCC     m:01 A410 DXXXXX CXXXXX 0603000000
2016.01.23 10:51:24.946 0: HMLAN_Parse: HMUSB1 R:EDXXXXX   stat:0000 t:02CB0508 d:FF r:FFCC     m:01 A410 DXXXXX CXXXXX 0603000000
2016.01.23 10:51:24.958 0: HMLAN_Parse: HMUSB1 R:EEXXXXX   stat:0000 t:02CB0524 d:FF r:FFC6     m:01 A410 EXXXXX CXXXXX 0603000000
2016.01.23 10:51:25.479 0: HMLAN_Parse: HMUSB1 R:EFXXXXX   stat:0000 t:02CB07CC d:FF r:FFC1     m:01 A410 FXXXXX CXXXXX 0603000000
2016.01.23 10:51:25.959 0: HMLAN_Parse: HMUSB1 R:EGXXXXX   stat:0000 t:02CB09C1 d:FF r:FFC6     m:00 A410 GXXXXX CXXXXX 06010000
2016.01.23 10:51:26.791 0: HMLAN_Parse: HMUSB1 R:ERXXXXX   stat:0000 t:02CB0CF1 d:FF r:FFC1     m:00 A410 RXXXXX CXXXXX 06016430


Legende:
CXXXXX = HMID
DXXXXX = HM-LC-Sw1PBU-FM mit customFW den ich versuche zu flashen
FXXXXX = anderer HM-LC-Sw1PBU-FM mit customFW
GXXXXX = anderer HM-LC-Sw1PBU-FM mit originalFW
RXXXXX = Rollladenaktor (HM-LC-Bl1PBU-FM)

Also irgendwie kam jetzt was an ... aber das Verhalten ist immer noch gleich ... die LED leuchtet nicht wenn ich den Config-Button drücke, egal wie lang. Der Schalter funktioniert quasi direkt normal.

edit: Nach was suche ich eigentlich. Wie müsste denn so eine Bootloadernachricht aussehen?
Fhem5.8@Raspi3|~70xHomematic|KM271|1Wire|DoorPi mit DoorPiBoard|GarageDoorSingleButton|Graphite

frank

du musst da nichts verschleiern, kann sowieso jeder mitsniffen.

2014.10.24 12:18:16.698 0: HMLAN_Parse: hmlan1 R:E266E75   stat:0000 t:08B25141 d:FF r:FFC5     m:00 0010 266E75 000000 004B455131313039373937
ich denke so sollte die msg aussehen. der schalter sendet seine seriennummer.

wenn deine aufzeichnungen stimmen, hat der schalter vermutlich keinen bootloader. hast du evevntuell beim flashen der fw wieder gelöscht.
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