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
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.
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 DXXXXXdu musst den schalter in den bootloader schicken. steht sicher im wiki.
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.
sniffe mal wie im wiki homematic sniffen beschrieben, dann ersparst du dir das spekulieren. :)
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?
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.
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.
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.
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?
update über fhem funktioniert nicht mit dem schalter.
du sollst loggen, wenn der schalter spannung bekommt. das umschalten in den bootloader.
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).
ich würde es nochmal ohne grep probieren. theoretisch kann der bootloader auch eine andere adresse haben.
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?
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.
Ich habe eigentlich streng nach Anleitung erst den Bootloader und dann die Firmware geflashed.
Sieht wohl so aus als müsste ich doch nochmal löten. Kann ich das dann irgendwie überprüfen?
Nach meinem Verständnis des Bootloaders sollte der Schalter, also die Firmware doch gar nicht starten wenn es keinen Bootloader gibt?
ZitatNach meinem Verständnis des Bootloaders sollte der Schalter, also die Firmware doch gar nicht starten wenn es keinen Bootloader gibt?
der bootloader ist ja eigentlich auch nur eine fw. wenn wirklich beide fw's vorhanden sind, wird nach spgswiederkehr immer die bootloader-fw gestartet. wenn der bootloader nichts flashen soll, und eine weitere fw ist vorhanden, startet er die application-fw.
ich würde, wie im wiki beschrieben, nur den bootloader über kabel flashen. die normale fw gleich ota (kabel noch angelötet lassen). wenn dann alles funktioniert, kabel ablöten, zusammenbauen, freuen. 8)
Langsam werd ich schlauer. Danke!
Dann vermute ich mal, dass ich mit dem application-fw flashen immer die bootloader-fw überschrieben habe.
Das würde zumindest all meine Symptome erklären.
Habe grade heute meinen neuen Raspi2 bekommen. Den werde ich erstmal einrichten, dann habe ich den alten Raspi1 frei um ihn als programmer zu verwenden. Brauche ich wohl ein paar Tage, bis ich dann zum Löten komme. Ich melde mich wenn ich Erfolg oder Fragen habe :),
Probier mal Schalter-nach-unten während du den Strom verbindest, einige Schalter (neuere Firmware) gehen dadurch in den FW-update modus.
Ansonsten probier mal ne standard-firmware falls du missing ack bekommst, ob das denn klappt, wenn ja, dann ist die custom-firmware nicht korrekt.