Hallo,
maxx3105 hat sich die Mühe gemacht einen boot loader für HM Wired (Homebrew) zu entwickeln.
Zitat von: maxx3105 am 28 Juli 2026, 13:15:15So ich habe die https://github.com/maxx3105/HBWired (https://github.com/maxx3105/HBWired) und die https://github.com/maxx3105/HBW-Booter (https://github.com/maxx3105/HBW-Booter) nun auf den aktuellen Stand gebracht. Damit müssten die Änderungen nun leicht ersichtlich sein, die ich für den (Open)CCU betrieb gemacht habe.
Ein großes Danke dafür! 8)
Ich habe ein paar Tests gemacht, und mir einen Fork auf github erstellt. Erst mal hat es auf anhieb funktioniert, da aber ein weiteres Gerät mit am Bus hing, tauchten ein paar Probleme auf.
So reagierte der booter auf auf alle broadcasts. Auch habe ich das initiale timeout reduziert, da ein device reset (message 0x21 0x21) ebefalls über ein Watchdog reset arbeitet. Eventuell könnte man das ändern... jetzt dauert ein restart ~4 Sekunden länger, was auch kein Problem ist.
Meine Änderungen. Kann ein pull request erstellen, falls das ok ist...
https://github.com/maxx3105/HBW-Booter/compare/main...loetmeister:HBW-Booter:main#diff-2a3c7d892139b12b843b5534701749e1369e69be4fe47408b86c737246b8d577R416
Ich teste noch was weiter, wie es sich mit FHEM und mehr Geräten am Bus verträgt...
Im flash_tool.py ist bei mir auch was krumm... hatte in Zeile 125 das 'print' einfach rausgenommen, dann lief es durch. ::)
Flashe .\HBW-CC-WW-SPktS.ino.hex: 19354 Bytes, 0x0000..0x4B99
z z u (Booter-Einstieg) ...
-> Booter aktiv (StartupReason)
p (Blockgroesse) ...
Traceback (most recent call last):
File "C:\EigenerKram\elektronik\projekte\HBWired\booter\flash_tool.py", line 125, in <module>
if d[1][:1] == b'p': print(f" -> Booter meldet Blockgroesse {d[1][1]}")
~~~~^^^
IndexError: index out of rangePS: Änderungen an HBWired schaue ich mir noch an... den booter start habe ich über "resetSystem" gemacht. (der code ist ja schon vorhanden)
switch(frameData[0]){
case 'u': // Update (Bootloader starten)
pendingActions.resetSystem = true; // don't reset immediately, send ACK first
// der HBW-Booter erkennt WDRF und bleibt im Update-Modus
break;
}Gruß,
Thomas
Hallo,
habe das flash_tool.py Skript um einen optionalen Adressparameter erweitert, um beliebige Geräte am Bus zu adressieren. Auch die Aufhebung des sleep Modus nach Erfolg und Abbruch ergänzt, sonst würde alles eingefroren bleiben.
In meinem Test setup sieht es soweit gut aus, am "echten" bus mit vielen anderen Geräten steht der Test noch aus. :)
flash_tool.py COM9 C:\projekte\HBWired\HBW-xyz\build\arduino.avr.nano\HBW-xyz.ino.hex 0x42001234
Benutze Geraeteadresse: 0x42001234
...
Einfacher als das flash_tool.py wäre es wenn man in FHEM, am HM485_LAN device eine Upload Option hätte. So wie man dort den discovery modus starten kann. (set hm485 discovery start)
HM485 device (mit HM485d für USB Dongle)
TYPE HM485_LAN
InterfaceType HMW-SOFT-GW
Änderung in der HBWired lib habe ich erst mal in meinem dev branch gemacht.
enabled 'u' (update) command to test booter
https://github.com/loetmeister/HBWired/commit/d95d7ceff4b7202f32ef78f4119ba24470d1e9d6
Der Weg über den watchdog ist einerseits schön, da man relativ Plattform- / MCU unabhängig ist - andererseits ist das "update" Kommando nicht das einzige was den watchdog reset auslöst / auslösen könnte.
@maxx3105, was sprach gegen de Sprung zur BOOTSTART Adresse?
Gruß
Hallo Thomas,
super Tests, danke — beide Punkte waren echte Bugs, sind gefixt:
flash_tool.py: Die p-Blockgrößen-Zeile war doppelt kaputt. Die Booter-Antwort auf p ist ein ACK-Frame mit Payload [0x00, Blockgröße] — kein 'p' im ersten Byte. Die Prüfung d[1][:1]=='p' hat also nie die echte Antwort getroffen und ist bei einem kurzen Fremd-Frame (dein zweites Gerät am Bus) in den IndexError gelaufen. Jetzt auf ACK-Frame + Länge geprüft, dann greift auch die Blockgrößen-Anzeige.
Booter/Broadcasts: Du hast völlig recht — der Booter hat jeden Broadcast beantwortet. Ich lasse jetzt nur noch z/Z als Broadcast durch (die antworten bewusst nicht) und beantworte alles andere ausschließlich adressiert. Damit ist die Kollision mit anderen Geräten weg.
PR sehr gerne — oder wir gleichen kurz ab, ich habe die zwei oben schon lokal drin.
Zur BOOTSTART-Frage: Ich bin bewusst über den Watchdog gegangen, aus drei Gründen — (1) plattformunabhängig, die App braucht kein MCU-spezifisches BOOT_START und keine Sprung-/Stack-/IRQ-Akrobatik; (2) der echte Reset gibt einen definierten Registerzustand, ein direkter Sprung in die Boot-Section würde den ganzen App-Zustand mitschleppen; (3) der AskSin-Funk-OTA-Bootloader macht es genauso (wdt_enable).
Dein Einwand stimmt trotzdem: reines WDRF ist nicht eindeutig, der Device-Reset läuft ja auch über den WDT. Sauberste Lösung ohne den Plattformvorteil aufzugeben: ein Magic-Wort in .noinit zusätzlich zum WDRF. Das u-Kommando setzt es vor dem Reset, der Booter bleibt nur bei WDRF && Magic, der Device-Reset ist damit wieder eindeutig ,,App". Dein reduziertes Timeout kann als Sicherheitsnetz gerne drin bleiben.
Gruß Markus
Hallo Markus,
danke für die Details. Blockgroesse stimmt nun:
p (Blockgroesse) ...
-> Booter meldet Blockgroesse 64
Ich habe mal einen pull request mit noch ein paar kleinen Anpassungen erstellt:
https://github.com/maxx3105/HBW-Booter/pull/1
Ja, WDRF + ".noinit" variable klingt spannend. Wusste gar nicht das es so was im RAM gibt :)
Habe das erste Gerät am Bus per OTA aktualisiert. Hatte nur den Booter (also ohne app) mal ein paar Stunden laufen lassen und dann die App Datei übertragen. Hat alles ohne Probleme geklappt.
In FHEM ändert sich bei einem "getConfig" (oder FHEM restart) der D-deviceKey zu "genric" - wie erwartet, aber nach dem OTA update und einem neuen "getConfig" ist alles wieder da.
Es wird ja immer nur ein Gerät in den bootloader modus versetzt, bzw. startet einzelne Geräte. Ein interessantes Testszenario wäre noch wenn man viele Geräte nur mit booter am Bus hat, und alle zeitgleich eingeschaltet werden (Strom kommt auf den Bus) dann würden alle STARTUP_REASON und ANNOUNCE ohne Kollisionsabfrage senden. Wobei es kein retrasmit gibt und dann nach dem großen Geschrei auch schnell wider ruhe einkehrt.. ::)
Gruß,
Thomas
Hallo,
PR ist gemerged. Danke dafür.
Ich habe Claude mal an eine Fhem-Upload-Erweiterung angesetzt.
ZitatWas am echten FHEM noch zu verifizieren ist (im Code als A/B/C markiert)
Diese drei kann ich ohne laufendes FHEM nicht abschließend klären — es sind die einzigen echten Unbekannten:
A) Broadcast: reicht target='FFFFFFFF', damit CMD_SEND mode 0x00 (kein ACK) sendet? → in 00_HM485_LAN.pm prüfbar.
B) Antwort-Weg: kommt die Booter-ACK (Frame 0x19 + Payload) bis HM485_ProcessResponse? u/w stehen nicht in validRequestTypes — evtl. Liste erweitern oder Hook eine Ebene früher.
C) Payload-Format der ACK-Antwort in FHEM ($msgData) — für p sollte '0040' ankommen.
Um das "Geschrei" etwas zu sortieren könnte ich einen kleinen adress-abgeleiteten Random-Delay vor dem Announce (wie HBWired-Geräte es machen) einführen, aber kritisch ist es nicht.
Dein #TODO: add validation of sender address beim g-Announce würde ins selbe Thema fallen (richtiges Gerät im Announce-Getümmel erkennen).
Edit. Habe die Erweiterung angehängt. Bitte testen.
Hi Markus,
danke, das sieht schon vielversprechend aus... glaube die Einbindung in das HM485 Perl Modul klemmt noch etwas. Oder ich habs irgendwo versemmelt... :)
Meine Schritte:
HM485_fwUpdate.pl, als .pm hier hin kopiert:
/opt/fhem/FHEM/lib/HM485# ls
ConfigurationManager.pm Constants.pm Device.pm Devices HM485d HM485_fwUpdate.pm PeeringManager.pm Util.pm XmlConverter.pm
10_HM485.pm an gepasst:
use lib::HM485::HM485_fwUpdate;
'fwUpdate' => 'textField',nach Zeile 575 eingefügt
https://github.com/kc-GitHub/FHEM-HM485/blob/40a88b890d6aee5963e9497493f438f5fd45f124/FHEM/10_HM485.pm#L575
} elsif ($cmd eq 'fwUpdate') {
return HM485_fwu_Start($hash, $value);
# }nach Zeile 621
$value statt $a[2] und ohne schließende Klammer
https://github.com/kc-GitHub/FHEM-HM485/blob/40a88b890d6aee5963e9497493f438f5fd45f124/FHEM/10_HM485.pm#L621
foreach my $d (values %{$modules{HM485}{defptr}}) {
next unless $d->{fwu} && $d->{IODev} && $d->{IODev} == $ioHash;
HM485_fwu_OnResp($d, $msgData);
return;
}nach Zeile 2005
https://github.com/kc-GitHub/FHEM-HM485/blob/40a88b890d6aee5963e9497493f438f5fd45f124/FHEM/10_HM485.pm#L2005
2026.08.12 22:13:39 2: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: /home/mobile/HBW/HBW-CC-WW-SPktS.ino.UART_v0.14.hex -- 16520 Bytes, 0x0000..0x4087
2026.08.12 22:13:40 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 2
2026.08.12 22:13:40 5: hm485: HM485_LAN_Write TX: 221
2026.08.12 22:13:40 5: SW: fd02dd4b
2026.08.12 22:13:40 5: hm485: HM485_LAN_parseIncommingCommand: MsgId: 221 Cmd: 97
2026.08.12 22:13:40 5: hm485: HM485_LAN_parseIncommingCommand: Alive: (221) 00 AliveStatus: 00
2026.08.12 22:13:40 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 2
2026.08.12 22:13:41 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 3 at state 2
2026.08.12 22:13:41 1: HBW_CC_WW_SPktS_HBW7296375: fwUpdate FAILED (HBW_CC_WW_SPktS_HBW7296375): timeout at state 2Die hex Datei wird gelesen, und fwUpdate aufgerufen.
Leider sehe ich kein z z / Z Z oder anderes auf dem Bus. CMD_SEND scheint noch nicht zu passen.
Gruß,
Thomas
Hi Thomas,
das Log zeigt genau die Ursache, und sie liegt auf meiner Sende-Seite, nicht an deinem Einbau. Dein set-Zweig (mit $value) und der Hook waren richtig gedacht. Zwei Sachen:
1. Warum nichts auf den Bus ging (der eigentliche Bug): Meine Sende-Helfer riefen IOWrite(**$ioHash**, ...) mit dem IO-Hash auf. FHEMs IOWrite will aber das Device-Hash — es sucht sich ->{IODev} selbst, exakt wie HM485_DoSendCommand: IOWrite($hash, HM485::CMD_SEND, {target,data}). Mit dem IO-Hash sucht IOWrite dessen ->{IODev} (existiert nicht) und wirft den Frame lautlos weg → ,,timeout at state 2". Das %params-Format und die Hex-Daten waren korrekt. In der angehängten .pl gefixt (_sendAcked + _sendBroadcast).
HM485_fwUpdate.pl
2. Bitte den Hook eine Ebene höher setzen — statt in HM485_ProcessResponse in HM485_Parse, direkt nach
my $msgData = uc( unpack ('H*', substr($message, 4)));und vor if ($msgCmd == HM485::CMD_RESPONSE):
foreach my $d (values %{$modules{HM485}{defptr}}) {
next unless $d->{fwu} && $d->{IODev} && $d->{IODev} == $ioHash;
HM485::Util::Log3($ioHash, 3, 'fwUpdate RX: msgCmd='.$msgCmd.' msgData='.$msgData);
HM485_fwu_OnResp($d, $msgData);
return $ioHash->{NAME};
}So fangen wir die Booter-Antwort ab, egal ob sie als CMD_RESPONSE oder CMD_EVENT reinkommt (in ProcessResponse verpasst du den Event-Fall), und $msgData ist der volle Payload.
Dann einmal testen: jetzt sollten z z und u wirklich auf dem Bus liegen und der Booter antworten. Schick mir die fwUpdate RX:-Zeilen aus dem Log (verbose 3 reicht) — daran justieren wir den letzten offenen Punkt, den Payload-Offset: OnResp erwartet die p-Antwort als 0040 (Blockgröße bei substr 2) und die r-Antwort als reine Flash-Bytes ab Offset 0. Stehen im $msgData noch führende Bytes (Sender-Adresse o.ä.), verschieben wir die zwei substr-Offsets entsprechend — ein Einzeiler je Stelle. CRC und der ganze Ablauf sind im Trockenlauf schon durch, das ist der letzte Handgriff.
Gruß
Hallo,
ja, senden sieht schon gut aus. :)
Auf dem Bus kommt:
(das ist von einem anderen HBW device, da sehe ich nur broadcasts und das von der Zentrale kommt. 42:00:00:77 Anwortet aber)
19:36:42.480 -> R: FD:FF:FF:FF:FF:98:00:00:00:01:03:7A:6D:72
19:36:42.584 -> R: FD:FF:FF:FF:FF:1A:00:00:00:01:03:7A:4E:5C
19:36:42.658 -> R: FD:42:00:00:77:1C:00:00:00:01:03:75:CC:16
19:36:42.886 -> R: FD:42:00:00:77:1C:00:00:00:01:03:75:CC:16
19:36:43.060 -> R: FD:42:00:00:77:1C:00:00:00:01:03:75:CC:16
19:36:43.697 -> R: FD:42:00:00:77:1E:00:00:00:01:03:75:60:6A
19:36:43.899 -> R: FD:42:00:00:77:1E:00:00:00:01:03:75:60:6A
19:36:44.072 -> R: FD:42:00:00:77:1E:00:00:00:01:03:75:60:6A
19:36:44.684 -> R: FD:42:00:00:77:18:00:00:00:01:03:70:D4:E6
19:36:44.913 -> R: FD:42:00:00:77:18:00:00:00:01:03:70:D4:E6
19:36:45.115 -> R: FD:42:00:00:77:18:00:00:00:01:03:70:D4:E6
19:36:45.695 -> R: FD:42:00:00:77:1A:00:00:00:01:03:70:78:9A
19:36:45.925 -> R: FD:42:00:00:77:1A:00:00:00:01:03:70:78:9A
19:36:46.127 -> R: FD:42:00:00:77:1A:00:00:00:01:03:70:78:9A
19:36:46.708 -> R: FD:42:00:00:77:1C:00:00:00:01:03:70:9C:1C
19:36:46.939 -> R: FD:42:00:00:77:1C:00:00:00:01:03:70:9C:1C
19:36:47.141 -> R: FD:42:00:00:77:1C:00:00:00:01:03:70:9C:1C
Im fhem log:
2026.08.13 19:21:22 2: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: /home/mobile/HBW/HBW-CC-WW-SPktS.ino.UART_v0.14.hex -- 16520 Bytes, 0x0000..0x4087
2026.08.13 19:21:22 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF842000077FF08
2026.08.13 19:21:22 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF84200007741000000000248425737323936333735
2026.08.13 19:21:22 3: hm485: fwUpdate RX: msgCmd=114 msgData=59
2026.08.13 19:21:22 3: hm485: fwUpdate RX: msgCmd=114 msgData=F8FF08
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=190040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=390040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=590040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=790040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=190040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=390040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=590040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=790040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=190040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=390040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=590040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=790040
2026.08.13 19:21:23 3: hm485: fwUpdate RX: msgCmd=114 msgData=190040
2026.08.13 19:21:24 3: hm485: fwUpdate RX: msgCmd=114 msgData=390040
2026.08.13 19:21:24 3: hm485: fwUpdate RX: msgCmd=114 msgData=590040
....
2026.08.13 19:21:39 1: HBW_CC_WW_SPktS_HBW7296375: fwUpdate FAILED (HBW_CC_WW_SPktS_HBW7296375): verify mismatch @0x0000 (exp 0C9473000C949B00.. got 590040..)
Vermute das hängt dann in einer Schleife fest, da keine Antwort kommt (lief ca. 17 Sekunden). Hätte erwartet das früher abgebrochen wird, oder gar kein Flash geschrieben wird, da ja keine Bestätigung vom Booter kommt?
Gruß,
Thomas
Top — jetzt sind wir fast durch. Das Log zeigt beides: die Frames liegen auf dem Bus und der Booter antwortet (190040 & Co). Zwei Dinge waren noch drin, beide in der Auswertung der Antworten:
1. Payload-Offset. Deine fwUpdate RX:-Zeilen zeigen, dass $msgData mit dem Bus-Control-Byte anfängt — 190040 = control 19 + Payload 0040. Ich hatte die Blockgröße bei substr(,2,2) gelesen (= 00) statt beim zweiten Payload-Byte; beim Verify dasselbe. → Control-Byte wird jetzt abgeschnitten, dann erst der Payload gelesen.
2. Der eigentliche Fehler — die spontanen Broadcasts. Nach u+Reset meldet sich der Booter mit StartupReason (...FF08) und Announce (...41...), beide control 0xF8. Die kamen zwischen die ACKs, und meine Auswertung nahm sie als ,,die erwartete Antwort" → die State-Machine lief zwei Schritte vor → beim Verify kam dann folgerichtig ein w-ACK (590040) statt der Flash-Bytes. Daher der Mismatch. Fix: es werden nur noch echte ACK-Frames ausgewertet (control & 0x07 == 0x01, exakt wie der Decoder in flash_tool.py); die F8-Broadcasts werden ignoriert.
Zu deinen Fragen:
,,17 s / Schleife": kein Festhänger — die w-Schleife lief tatsächlich über alle ~258 Blöcke (daher die Zeit), nur mit Versatz; am Ende scheiterte der Verify und es brach sauber ab (inkl. Z Z).
,,Flash trotz keiner Bestätigung?": die Bestätigungen kamen (die xx0040-ACKs), sie wurden nur falsch zugeordnet. Der Booter hat also korrekt geflasht; der Verify-Fehler war der Versatz, kein echter Flash-Fehler. Die Retries im Bus-Mitschnitt kamen vom Offset-Bug (Antwort nicht als erwartete erkannt → Timeout → Wiederholung). Und keine Bricking-Sorge: der Booter schreibt Page 0 (Reset-Vektor) zuletzt und bleibt bei einem Abbruch aktiv — ein halb geflashtes Gerät startet nie versehentlich die kaputte App.
Im Trockenlauf habe ich die F8-Broadcasts jetzt bewusst mitten reingestreut → State bleibt stabil, kompletter Durchlauf bis done. Bitte nochmal testen — jetzt sollte der Verify durchlaufen und das Gerät danach mit der neuen FW announcen. Wenn vereinzelt noch Retries an Page-Grenzen auftauchen (Flash-Timing), drehen wir das 0,5-s-Timeout leicht hoch. Poste sonst wieder die fwUpdate RX:-Zeilen.
HM485_fwUpdate.pl
Gruß
Hi.
Die Erklärung klingt irgendwie plausibel, leider hängt es noch irgendwo. :)
10_HM485.pm hatte ich so belassen, nur HM485_fwUpdate.pl ersetzt.
Auf dem Bus sehe ich keine Veränderung. 0x75 (u) wird 6 mal gesendet, etc. wie zuvor auch... denke da fehlt das ACK?
FEHM logs s.u.
Was auch passiert, ist das nach dem RESPONSE TIMEOUT weiter die Flash Nachrichten gesendet werden. Soweit ich das erkenne kann, immer 9 mal die selbe Nachricht. 0x77 (w)
Es gibt auch verm. einen bug in 10_HM485.pm das "getConfig" schon mal einfriert und das device mit config status "reading" festhängt. Bisher habe ich das nur mit einem FEHM Neustart gelöst bekommen. Was genau es auslöst kann ich nicht sagen, die Wahrscheinlichkeit ist nach einem device update über den Bus relativ hoch. Eventuell sind viele Frames ein Problem... ob das hier überhaupt relevant ist weiß ich nicht. Wollte es nur erwähnen.
2026.08.13 22:08:54 2: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: /home/mobile/HBW/HBW-CC-WW-SPktS__test.ino.hex -- 16574 Bytes, 0x0000..0x40BD
2026.08.13 22:08:54 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 2
2026.08.13 22:08:54 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:08:55 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:08:56 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 5
2026.08.13 22:08:56 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:08:57 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 6
2026.08.13 22:08:57 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 6
2026.08.13 22:08:57 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:08:58 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 6
2026.08.13 22:08:58 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 6
...
2026.08.13 22:09:17 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:09:18 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 6
2026.08.13 22:09:18 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 6
2026.08.13 22:09:18 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:09:19 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 6
2026.08.13 22:09:19 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 6
2026.08.13 22:09:19 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:09:20 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 7
2026.08.13 22:09:20 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 7
2026.08.13 22:09:20 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 22:09:20 1: HBW_CC_WW_SPktS_HBW7296375: fwUpdate FAILED (HBW_CC_WW_SPktS_HBW7296375): verify mismatch @0x0000 (exp 0C9473000C949B00.. got 42000077..)
2026.08.13 22:09:21 3: HBW_CC_WW_SPktS_HBW7296375: RESPONSE TIMEOUT for 42000077
2026.08.13 22:09:22 3: HBW_CC_WW_SPktS_HBW7296375: RESPONSE TIMEOUT for 42000077
2026.08.13 22:09:23 3: HBW_CC_WW_SPktS_HBW7296375: RESPONSE TIMEOUT for 42000077
versuch 2, zuvor; mit vorheriger version:
2026.08.13 19:24:56 2: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: /home/mobile/HBW/HBW-CC-WW-SPktS.ino.UART_v0.14.hex -- 16520 Bytes, 0x0000..0x4087
2026.08.13 19:24:57 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 2
2026.08.13 19:24:57 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 19:24:58 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 19:24:59 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 5
2026.08.13 19:24:59 3: hm485: fwUpdate RX: msgCmd=97 msgData=0142000077
2026.08.13 19:25:00 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 6
2026.08.13 19:25:00 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 2 at state 6
Gruß
Hi Thomas,
Was die msgCmd-Zahlen bedeuten (aus Constants.pm nachgeschlagen): 114=0x72=RESPONSE, 101=0x65=EVENT, 97=0x61=CMD_ALIVE. Und CMD_ALIVE mit 01<Adresse> ist in HM485_Parse der NACK-Pfad = ,,Gerät hat nicht geantwortet".
In diesem Lauf kamen ausschließlich msgCmd=97-NACKs — kein einziges RESPONSE, kein EVENT. Beim Lauf um 19:21 kamen dagegen noch StartupReason + Announce (101) und echte ACKs (114 190040). Dein Gerät antwortet also inzwischen gar nicht mehr — auch nicht auf das erste u. Deine Vermutung ,,da fehlt das ACK" stimmt anscheinend, und der spätere ,,verify mismatch" war nur Folgeschaden: mein Filter ließ die 01-NACKs fälschlich als ACK durch (0x01 & 0x07 == 1) — deshalb got 42000077.
Drei Fixes in der angehängten Version:
Filter sollte jetzt korrekt sein: nur echte Bus-ACKs (control & 0x1F == 0x19). Gegen deine Log-Frames geprüft — 19/39/59/79... durch, F8...-Broadcasts und 01...-NACKs raus.
NACK-Fastfail: ein NACK bricht sofort mit klarer Meldung ab, statt 26 s in Timeouts zu laufen und als ,,verify mismatch" zu enden.
Retry-Sturm weg: mein Timeout war 0,5 s — aber 00_HM485_LAN.pm wartet nach jedem Send fest 1 s, bevor es den NACK meldet. Ich habe also nachgelegt, bevor der Transport fertig war. Jetzt 1,5 s und nur noch 1 eigener Versuch.
HM485_fwUpdate.pl
⚠️ Die Hook-Zeile braucht eine kleine Ergänzung (sonst wirkt der NACK-Fastfail nicht):
HM485_fwu_OnResp($d, $msgData, $msgCmd);Wichtiger als das Modul — zwei Verdachtspunkte am Gerät:
(a) Der Lauf um 19:24 hat vermutlich Page 0 gelöscht zurückgelassen. Der Booter löscht beim ersten w den Reset-Vektor, und meine Blockreihenfolge schreibt Page 0 zuletzt. Weil die Zuordnung damals verrutscht war, ist die w-Schleife wahrscheinlich ein bis zwei Blöcke zu früh beendet worden — und genau die letzten sind 0x0000 und 0x0040. Dann ist der Reset-Vektor 0xFFFF → die App ist ungültig → der Booter bleibt dauerhaft aktiv. Das erklärt warum die App nicht mehr auf u antwortet, es läuft gar keine App mehr.
(b) Marker-Falle, falls du den neuen Booter (FW 0x0003) schon drauf hast: Der bleibt nach u nur dann im Update-Modus, wenn die App den RAM-Marker setzt. Eine App, die noch mit der ungepatchten Lib gebaut ist, setzt ihn nicht → der Booter springt sofort zurück in die App → Update unmöglich. Falls dein HBW-CC-WW-SPktS-Sketch noch mit deiner alten Fork-Version gebaut ist: einmal mit der aktualisierten HBWired.cpp (Commit 17b97ba) neu bauen.
Häng das Gerät einmal an flash_tool.py und schau, ob sich der Booter dort noch meldet. Antwortet er dort auch nicht dann hängt es am Gerät und dann hilft nur noch der Flash per ISP.
Zum getConfig-Einfrieren: klingt nach einem eigenständigen Problem in 10_HM485.pm (Queue bleibt in .waitForResponse hängen, wenn viele Frames/NACKs kommen). Für unser Update ist es nicht die Ursache, aber nach einem Update-Abbruch mit vielen NACKs ist genau diese Situation gegeben.
Gruß
Ok, ich teste die neue Version.
Nach deiner Anmerkung habe ich das Gerät noch mal genau geprüft... interessanterweise schickt das Gerät brav seine announce message beim start, auch ein "autocreate" in FHEM und auslesen der Konfig klappt. In den Booter komme ich aber nicht mehr.
Also werde ich den booter (v0.02 erstmal) neu Flaschen und damit testen. Wenn das klappt, dann booter v0.03.
Bei der neuen Version hänge ich noch gedanklich hier fest
if(!NoApp && (!(rf & (1<<WDRF)) || !updateWanted)){
startApp();
}im Falle einer App ohne BOOT_MAGIC, wäre updateWanted immer false, d.h. in dem Vergleich oben immer true - damit auch die Oder Verknüpfung. Egal welcher reset, ich komme immer in die App (wenn es eine gibt). Einer "App noch OHNE Marker-Patch" würde das nicht helfen. Oder ich hab da einen Gedankenfehler? :-\
Ich würde den Fall gar nicht betrachten. Ist ja ok wenn der Booter nur mit WDRF + BOOT_MAGIC funktioniert. Die aktuelle HBW Geräte hatten ja noch nicht mal das "start booter" Kommando. Da kann man jetzt frisch starten... :)
Ich teste das aber auch mal in beiden Variationen...
EDIT:
Erster test, bootloader. (v0.02) Erfolgreich!
2026.08.14 22:02:42 2: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: /home/mobile/HBW/HBW-CC-WW-SPktS__test.ino.hex -- 16574 Bytes, 0x0000..0x40BD
2026.08.14 22:02:43 3: hm485: fwUpdate RX: msgCmd=114 msgData=F8FF08
2026.08.14 22:02:43 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF84200007741000000000248425737323936333735
2026.08.14 22:02:44 3: HBW_CC_WW_SPktS_HBW7296375: fwUpdate: retry 1 at state 2
2026.08.14 22:02:44 3: hm485: fwUpdate RX: msgCmd=114 msgData=19
2026.08.14 22:02:44 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF842000077FF08
2026.08.14 22:02:44 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF84200007741000000000248425737323936333735
2026.08.14 22:02:45 3: hm485: fwUpdate RX: msgCmd=114 msgData=39
2026.08.14 22:02:45 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF842000077FF08
2026.08.14 22:02:45 3: hm485: fwUpdate RX: msgCmd=114 msgData=590040
2026.08.14 22:02:45 3: hm485: fwUpdate RX: msgCmd=114 msgData=790040
2026.08.14 22:02:45 3: hm485: fwUpdate RX: msgCmd=114 msgData=190040
2026.08.14 22:02:46 3: hm485: fwUpdate RX: msgCmd=114 msgData=390040
...
2026.08.14 22:03:03 3: hm485: fwUpdate RX: msgCmd=114 msgData=390040
2026.08.14 22:03:03 3: hm485: fwUpdate RX: msgCmd=114 msgData=590C9473000C949B000C949B000C945C180C945C180C945C180C949B000C9484170C949B000C949B0
00C949B000C9466180C949B000C949B000C949B000C949B00
2026.08.14 22:03:03 3: hm485: fwUpdate RX: msgCmd=114 msgData=790C943A170C949B000C942A180C9404180C949B000C949B000C949B000C949B000C949B000C949B0
0005EBCE2613FDD83C29C7E20A3FD1F41009D23BE46DB65F8
...
2026.08.14 22:03:19 3: hm485: fwUpdate RX: msgCmd=114 msgData=19CF1296049413890D0204000000000C10E103C003A203E91547134B04FF12C4040B046B0FCF12960
49413890D020400000000E404370E00000000E504AD0D
2026.08.14 22:03:20 3: hm485: fwUpdate RX: msgCmd=101 msgData=FFFFFFFFF84200061741009C01005A48425737323937383135
2026.08.14 22:03:20 3: hm485: fwUpdate RX: msgCmd=114 msgData=39
2026.08.14 22:03:20 2: HBW_CC_WW_SPktS_HBW7296375: fwUpdate DONE (HBW_CC_WW_SPktS_HBW7296375)"retry 1 at state 2" eventuell kommt das ACK etwas langsamer als im flash_tool.py?
Sonst sieht es super aus. Reading im device (fwUpdateSatus) zeigt Fortschritt und Ergebnis an.
Habe im Anschluss getConfig gemacht und dann noch mal fwUpdate mit einer leicht veränderten hex gemacht. Leif ebenfalls sauber durch.
Der start des fwUpdate auf dem Bus:
22:02:42.772 -> R: FD:FF:FF:FF:FF:98:00:00:00:01:03:7A:6D:72
22:02:42.860 -> R: FD:FF:FF:FF:FF:1A:00:00:00:01:03:7A:4E:5C
22:02:42.933 -> R: FD:42:00:00:77:1E:00:00:00:01:03:75:60:6A
22:02:43.077 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:04:FF:08:E2:E4
22:02:43.077 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:12:41:00:00:00:00:02:48:42:57:37:32:39:36:33:37:35:44:2A
22:02:44.357 -> R: FD:42:00:00:77:18:00:00:00:01:03:75:84:EC
22:02:44.405 -> R: FD:00:00:00:01:19:42:00:00:77:02:48:90
22:02:44.405 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:04:FF:08:E2:E4
22:02:44.405 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:12:41:00:00:00:00:02:48:42:57:37:32:39:36:33:37:35:44:2A
22:02:45.588 -> R: FD:42:00:00:77:1A:00:00:00:01:03:75:28:90
22:02:45.588 -> R: FD:00:00:00:01:39:42:00:00:77:02:AC:56
22:02:45.588 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:04:FF:08:E2:E4
Ein dritter Versuch schlägt aktuell Fehl..... EDIT2: Setzte das mal hier rein. Das Problem war die App hex, nicht der fwUpdate Prozess. Auf meinem FEHM Testsystem hatte ich noch eine hex für das Gerät, mit der selben Version - aber alt und ohne start booter CMD! Die anderen Test Firmware waren neu, bloß wenn ich auf die alte gewechselt bin war dann ende...
!! kein StartupReason — Booter evtl. nicht aktiv, versuche trotzdem weiter
p (Blockgroesse) ...
w (schreibe 259 Bloecke, Page 0 zuletzt)
!! FEHLER: kein ACK @0x0080Announce kommt beim Einschalten, GetConfig geht... aber Gerät ist wieder tot, bzgl. Booter.
Wäre super, wenn man mit gedrückten Config Taster in den booter käme - leider hab ich bei allen 328p basierenden Geräten den Taster an ADC7 gehängt... da geht nix außer ADC. Kein digital IO, glaube noch nicht mal Komparator.... :-|
Gruß,
Thomas
super
Zum retry 1 at state 2: Habe ich Claude deinen Bus-Mitschnitt durchgerechnen lassen — es ist kein zu langsames ACK, sondern ein fehlendes:
42.933 u #1 ctrl 0x1E -> ACK müsste ctrl 0x79 sein -> KOMMT NICHT
43.077 Booter StartupReason + Announce (fw 0002) = Gerät hat resettet
44.357 u #2 (mein Retry nach 1,4 s) ctrl 0x18
44.405 ACK ctrl 0x19 ✓ (passt exakt: (0x18>>1)&3 = 0 -> 0x19)
Das Gerät hat u #1 also verarbeitet (es resettet ja 144 ms später in den Booter), nur sein ACK taucht nicht auf. Warum flash_tool.py das nie gemerkt hat: das wartet nach dem ersten u gar nicht auf ein ACK, sondern schläft stur 1,5 s. Das Modul wartet — und sieht deshalb, was vorher unsichtbar war.
Woran es liegt (Zeitrechnung): Der ACK-Frame ist 13 Byte = bei 19200 8E1 7,45 ms Sendezeit; danach bleiben bis zum wdt_enable(WDTO_15MS) nur ~7,6 ms. sendFrameSingle() macht zwar ein serial->flush() bevor DE auf LOW geht, das Frame sollte also rausgehen — aber die Reserve ist dünn, und im Zweifel kollidiert es mit dem Reset bzw. der DE-Umschaltung. Falls du es sauber haben willst, ist der Einzeiler in HBWired.cpp im u-Handler:
wdt_enable(WDTO_60MS); // statt WDTO_15MS: ACK sicher komplett draußen
Kostet 45 ms mehr vor dem Reset, ändert am Protokoll nichts. Nötig ist es nicht — der Retry fängt es sauber ab (der Booter läuft dann schon und ACKt), Kosten ~1,5 s einmalig pro Update.
Edit:
Verdacht Nummer eins: läuft auf dem Gerät jetzt Booter v0.03? Dann ist das genau die Marker-Falle — und dein Einwand von gestern stimmt: v0.03 bleibt nur bei WDRF + BOOT_MAGIC im Update-Modus. Eine App, die noch ohne den Marker-Patch gebaut ist, setzt ihn nicht → der Booter springt sofort in die App zurück → kein StartupReason, und der erste w läuft auf ,,kein ACK @0x0080" (das ist der erste gesendete Datenblock, weil Page 0 zuletzt kommt). Passt 1:1 zu deinem Bild ,,Announce ok, getConfig ok, aber Booter tot".
Schau im Mitschnitt, ob das Gerät das u ACKt.
ACK kommt → App ist in Ordnung, der Booter springt zurück ⇒ Marker fehlt ⇒ App einmal mit der gepatchten HBWired.cpp (Commit 17b97ba) neu bauen, dann geht's wieder.
Kein ACK → die App erreicht ihren u-Handler nicht. Dann entweder ohne Booter-Handler gebaut, oder zeroCommunication war nicht aktiv: Die App braucht zwei z direkt hintereinander — kommt dazwischen ein anderer Broadcast (Announce eines Nachbargeräts!), setzt zStartCounter zurück und das u wird ignoriert. Bei mehreren Geräten am Bus ist das gut möglich.
Mit v0.02 solltest du in beiden Fällen wieder reinkommen — der kennt den Marker nicht.
Zum Config-Taster: das geht, auch an ADC7. 🙂
Du hast recht, dass ADC7 kein digitales IO und keinen Komparator hat — aber der ADC selbst funktioniert im Bootloader genauso wie in der App. Der Booter kann den Pin einfach messen: Taster gegen GND zieht den Wert nach unten, offen hält der Pull-up/Spannungsteiler ihn oben. Rund 60 Byte Code, und wir haben ~1,1 KB frei:
/* Config-Taster an ADC7 abfragen (analog, kein digitales IO noetig) */
static uint8_t configPressed(void){
ADMUX = (1<<REFS0) | 7; /* AVcc, Kanal ADC7 */
ADCSRA = (1<<ADEN)|(1<<ADPS2)|(1<<ADPS1)|(1<<ADPS0); /* ADC an, /128 */
ADCSRA |= (1<<ADSC); while(ADCSRA & (1<<ADSC)); /* Dummy-Wandlung */
ADCSRA |= (1<<ADSC); while(ADCSRA & (1<<ADSC)); /* echte Messung */
uint16_t v = ADC;
ADCSRA = 0; /* ADC wieder aus */
return (v < 512); /* gedrueckt = LOW */
}
Aufgerufen ganz am Anfang von main(), vor der Reset-Quellen-Entscheidung: gedrückt → im Booter bleiben, egal was MCUSR und Marker sagen.
Das ist pro Gerät nur eine Pin-Angabe (bei 328p ADC7, bei 32A/644P/1284P kann es ein normaler Portpin sein — der ADC-Weg funktioniert dort aber genauso).
Danke! Ich baue das mit dem Taster mal ein... das wäre Parktisch eine Notfall "debrick" Funktion zu haben :)
Falls man doch mal eine falsche hex nimmt...
Bzgl. dem letzten Test, dass das Gerät sich nicht mehr updaten lässt: Das Problem war die App hex, nicht der fwUpdate Prozess. Auf meinem FEHM Testsystem hatte ich noch eine hex für das Gerät, mit der selben Version - aber alt und ohne start booter CMD! Die anderen Test Firmware waren neu, bloß wenn ich auf die alte gewechselt bin war dann ende...
Mit aktueller App hex: Die letzten 3 fw updates liefen Erfolgreich und ohne "retry at state 2". Auf dem Bus sieht es aber für mich gleich aus. Auch die Zeiten scheinen nicht groß abzuweichen.
23:34:08.702 -> R: FD:FF:FF:FF:FF:18:00:00:00:01:03:7A:E2:20
23:34:08.804 -> R: FD:FF:FF:FF:FF:1A:00:00:00:01:03:7A:4E:5C
23:34:08.882 -> R: FD:42:00:00:77:1A:00:00:00:01:03:75:28:90
23:34:09.017 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:04:FF:08:E2:E4
23:34:09.017 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:12:41:00:00:00:00:14:48:42:57:37:32:39:36:33:37:35:5A:C2
23:34:09.088 -> R: FD:42:00:00:77:1A:00:00:00:01:03:75:28:90
23:34:09.120 -> R: FD:00:00:00:01:39:42:00:00:77:02:AC:56
23:34:09.120 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:04:FF:08:E2:E4
23:34:09.120 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:12:41:00:00:00:00:14:48:42:57:37:32:39:36:33:37:35:5A:C2
23:34:10.331 -> R: FD:42:00:00:77:1C:00:00:00:01:03:75:CC:16
23:34:10.372 -> R: FD:00:00:00:01:59:42:00:00:77:02:91:1E
23:34:10.372 -> R: FD:FF:FF:FF:FF:F8:42:00:00:77:04:FF:08:E2:E4
Falls noch mal die retry Meldung kommt würde ich von WDTO_15MS auf WDTO_30MS gehen - für mehr Sicherheit beim restart / bootstart.
Ich teste aktuell weiterhin mit booter 0.02. Hatte da zum testen den App / watchdog check rausgenommen um immer die ca. 4 sekunden im booter zu landen. Da ich aber meine hex ohne bootstart als Quelle identifiziert habe kann ich mal 0.03 probieren.
EDIT: "Das Gerät hat u #1 also verarbeitet (es resettet ja 144 ms später in den Booter), nur sein ACK taucht nicht auf. " --> das fehlende ACK aus der App nach "u" lag an meiner HBWired.cpp. Ich hatte das neue Verhalten (reset / booter) mit weniger Änderungen nachgebaut, leider ein "return" übersehen :)
Gruß
Perfekt, ich habe das FHEM-Modul ins Github-Repo nachgezogen. Danke für deine Mitarbeit.
Danke auch! :)
Hab noch ein paar klein Ergänzen gemacht, bzw. den Konfig Taster eingebaut. Die ADC Variante für den Atmel 328p ist getestet. Die GPIO Version für 328pb noch nicht...
https://github.com/maxx3105/HBW-Booter/pull/2
Ich hatte auch HM485_fwUpdate in mein "richtiges" FHEM eingebaut und ein FW update gemacht... leider abgebrochen. Da gibt es ein paar DOIFs, die Befehle and HM Geräte schicken (Teilw. minütlich). Mit z z werden alle HM Geräte still, FHEM schickt aber munter weiter und dann (da kein ACK) 3 mal... was natürlich auch im FW update Prozess passiert ist.
2026.08.16 14:15:44 2: HBW_DIS_Key_4_HBW7296855: fwUpdate: /home/pi/hbw_firware/HBW-DIS-Key-4.ino.UART_v0.36.hex -- 16946 Bytes, 0x0000..0x4231
2026.08.16 14:15:46 1: HBW_DIS_Key_4_HBW7296855: fwUpdate FAILED (HBW_DIS_Key_4_HBW7296855): keine Antwort vom Geraet (NACK) bei state 4 -- Geraet im Booter? App mit u-Handler? Bus/Adresse ok?
SET_LEVEL an 0x42000271 kommt dazwischen:
16.08.2026 14:15:44 1 CCU 4294967295 Broadcast INFO START_ZERO_COMMUNICATION 7A FD FF FF FF FF 18 00 00 00 01 03 7A E2 20
16.08.2026 14:15:44 1 CCU 4294967295 Broadcast INFO START_ZERO_COMMUNICATION 7A FD FF FF FF FF 1A 00 00 00 01 03 7A 4E 5C
16.08.2026 14:15:44 1 CCU 1107296855 0x42000257 INFO START_BOOTER 75 FD 42 00 02 57 1A 00 00 00 01 03 75 60 6A
16.08.2026 14:15:44 1107296855 0x42000257 1 CCU ACK FD 00 00 00 01 39 42 00 02 57 02 EC 5E
16.08.2026 14:15:44 1107296855 0x42000257 4294967295 Broadcast INFO STARTUP_REASON Watchdog FD FF FF FF FF F8 42 00 02 57 04 FF 08 AA 7C
16.08.2026 14:15:44 1107296855 0x42000257 4294967295 Broadcast INFO ANNOUNCE channel: 0 Type: 0 HW-Version: 0 FW-Version: 0.4 FD FF FF FF FF F8 42 00 02 57 12 41 00 00 00 00 04 48 42 57 37 32 39 36 38 35 35 AC E8
16.08.2026 14:15:46 1 CCU 1107296881 0x42000271 INFO SET_LEVEL 78-00-30 FD 42 00 02 71 18 00 00 00 01 05 78 00 30 04 86
16.08.2026 14:15:46 1 CCU 1107296881 0x42000271 INFO SET_LEVEL 78-00-30 FD 42 00 02 71 18 00 00 00 01 05 78 00 30 04 86
16.08.2026 14:15:46 1 CCU 1107296881 0x42000271 INFO SET_LEVEL 78-00-30 FD 42 00 02 71 18 00 00 00 01 05 78 00 30 04 86
16.08.2026 14:15:47 1 CCU 1107296855 0x42000257 INFO START_BOOTER 75 FD 42 00 02 57 1C 00 00 00 01 03 75 84 EC
16.08.2026 14:15:47 1107296855 0x42000257 1 CCU ACK FD 00 00 00 01 59 42 00 02 57 02 D1 16
16.08.2026 14:15:47 UNDEFINED 3F 3F
16.08.2026 14:15:47 1107296855 0x42000257 4294967295 Broadcast INFO STARTUP_REASON Watchdog FD FF FF FF FF F8 42 00 02 57 04 FF 08 AA 7C
Wie hast du das bei deinem HMW Gateway gelöst? Einfach HM485_fwUpdate mehrfach neu senden lassen?
Würde HM485_fwUpdate eigentlich mit originalen EQ3 HMW Geräten kompatibel sein? Oder haben die ein anderes Format für die Firmware?
Gruß,
Thomas
PR ist gemergt. Der Abbruch war ein Bug — nicht deine DOIFs. Im Bus-Log ist das u in State 4 sauber quittiert (ACK 0x59). Der NACK, der abgebrochen hat, galt aber 42000271 — dem SET_LEVEL-Gerät, nicht 42000257. Der Hook leitet jeden Frame ans Update-Gerät weiter, und meine NACK-Erkennung hat die Adresse nicht geprüft. Gefixt HM485_fwUpdate.pl , dazu gleich noch die Zuordnung per msgId: sonst könnte ein ACK eines anderen Geräts (hat ja auch control 0x19) mitten im Update als ,,meins" gelten und alles verschieben. Die Hook-Zeile braucht dafür $msgId zusätzlich:
HM485_fwu_OnResp($d, $msgData, $msgCmd, $msgId);
Ohne $msgId läuft es weiter wie bisher — die Adressprüfung beim NACK wirkt auch so.
Mein eigenbau HMW-Gateway besitzt den Bus während des Flashens allein. busFlashRun() wird aus dem Hauptloop blockierend aufgerufen und kehrt erst zurück, wenn der Flash durch ist; solange wird die LAN-/CCU-Seite überhaupt nicht bedient. Da kann sich nichts dazwischenschieben.
An mein "richtiges" Homematic habe ich mich damit noch nicht ran getraut. Ich habe bereits ein hmw-lgw-o-dr-gs-eu zerschossen und wie du weist gibt's dafür keinen Ersatz mehr.
In FHEM ist das strukturell anders: Das Modul teilt sich den Bus mit allem, was FHEM sonst tut. Mein Fix verhindert jetzt, dass Fremdverkehr das Update abbricht — aber die Frames liegen weiter auf dem Bus und stören (Kollisionen, dazu die 3 Wiederholungen der stummen Geräte). Kurzfristig würde ich die betreffenden DOIFs fürs Update schlicht abschalten (attr <doif> disable 1). Sauber wäre, dass FHEM während fwUpdate gar nichts anderes sendet — also im IO-Device andere CMD_SEND blockieren oder zurückstellen, solange ein Update läuft. Das wäre ein weiterer kleiner Eingriff in 00_HM485_LAN.pm; sag, ob du das willst, dann baue ich es.
Zu den eQ-3-Originalgeräten: Format und Protokoll passen, der Rest ist offen.
Firmware-Format: Die HMW-Modul-Firmware in der CCU-fwmap ist normales Intel-HEX, unverschlüsselt — mein Parser liest die direkt. (Verschlüsselt sind nur die .eq3-Container für Gateway/Coprozessor.)
Protokoll: identisch — hs485d spricht dieselbe Folge u/p/w/r/g, genau die fährt das Modul.
Der Haken: Das Originalgerät muss auf u in seinen eigenen Bootloader springen. Das ist uns nie gelungen: Bei einem HMW-Sen-SC-12-DR (v3.01) kam das ACK auf u, danach blieb das Gerät still. Die Ursache ist bis heute ungeklärt — unsere Disassembly deutete auf einen fehlenden Booter-Einstieg hin, aber das war die App-Hex, der eq3-Bootloader liegt separat in der Boot-Section, und einen erfolgreichen Referenz-Mitschnitt (echtes ELV-LGW) hatten wir nie. Ich würde also sagen: einen Versuch wert, aber mit einem entbehrlichen Gerät und im Wissen, dass wir nicht sagen können, was der eq3-Booter bei einem Abbruch macht.
Zum PR #2 — gefällt mir, vor allem dass der Idle-Timeout wieder auf 25 s zurückgeht (mit dem Marker ist die Verkürzung ja gegenstandslos). Drei Punkte:
Klammer-Bug in configPressed():
#if defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328__) && defined BUTTON_ADC_ONLY && BUTTON_BIT >= 6
&& bindet stärker als ||, das liest sich also als 328P || (328 && ADC_ONLY && BIT>=6). Für den 328P ist die Bedingung allein durch defined(__AVR_ATmega328P__) wahr — die Guards BUTTON_ADC_ONLY und BUTTON_BIT >= 6 sind wirkungslos. Wer auf einem 328P einen digitalen Pin nutzen will, landet still im ADC-Zweig. Fix:
#if (defined(__AVR_ATmega328P__) || defined(__AVR_ATmega328__)) && defined(BUTTON_ADC_ONLY) && (BUTTON_BIT >= 6)GPIO-Zweig ohne Pull-up (der ungetestete): Du setzt nur DDR auf Eingang, aktivierst aber keinen Pull-up. Ein offener Eingang liest zufällig — das Gerät bliebe sporadisch im Booter hängen. Es fehlt ein BUTTON_PORT-Define plus:
BUTTON_DDR &= ~(1<<BUTTON_BIT);
BUTTON_PORT |= (1<<BUTTON_BIT); /* interner Pull-up */
_delay_us(10); /* einschwingen lassen */
return !(BUTTON_PIN & (1<<BUTTON_BIT));
(Es sei denn, deine Platinen haben einen externen Pull-up — dann bitte im Kommentar festhalten.)
USE_BUTTON 1 als Default: Auf einer Platine ohne Taster hängt ADC6 in der Luft; ein Messwert unter 250 ist dann Zufall — und das Gerät startet ohne erkennbaren Grund im Booter. Ich würde entweder auf 0 defaulten oder den Punkt deutlich im Kommentar vermerken.
Kleinigkeiten: Der Kommentar hinter FW_VERSION 0x0004 nennt noch 0x0003: RAM-Marker — der Taster gehört dazu. Und gut zu wissen: Ein per Taster erzwungener Booter-Start endet nach ~25 s trotzdem im Idle-Timeout, falls die App gültig ist — man hat also ein Zeitfenster, kein Dauerzustand. Das ist meiner Meinung nach richtig so, sollte aber im Kommentar stehen.
Zitat von: maxx3105 am 16 August 2026, 16:10:38PR ist gemergt. Der Abbruch war ein Bug
Danke! Werde ich die Tage mal aktualisieren und testen.
Eventuell hat ja Thorsten noch mal Zeit und Lust das zu reviewen und evtl. in das Repo https://github.com/kc-GitHub/FHEM-HM485/ einzubinden... dann bräuchte ich es nicht vom update auszuschließen. Oder einen eigene Fork zu pflegen O:-)
Zitat von: maxx3105Kurzfristig würde ich die betreffenden DOIFs fürs Update schlicht abschalten
Ich hatte es genau so gemacht, würde aber nicht immer wissen welches DOIF / AT / Notify da grade sendet. Wenn jetzt, mit deinem fix, das update nur etwas länger dauert - durch die Wiederholungen, aber zu ende läuft ist es evtl. schon robust genug.
Zitat von: maxx3105Der Haken: Das Originalgerät muss auf u in seinen eigenen Bootloader springen. Das ist uns nie gelungen: Bei einem HMW-Sen-SC-12-DR (v3.01) kam das ACK auf u, danach blieb das Gerät still
Ich habe HMW_LC_Sw2_DR - ein ACK auf START_BOOTER und GET_PACKET_SIZE bekomme ich, aber keine Daten (keine PACKET_SIZE).
hbw_booter.cDanke für checken der Änderungen. Ja, nutzte fast immer interne Pull-ups. Hab ich vergessen zu aktivieren.
Zitat von: maxx3105USE_BUTTON 1 als Default
Wäre ok... ist vermutlich die sichere Variante. Nach ~25 s würde man dennoch in der Firmware landen, aber zufälliges Verhalten ist immer schlecht :)
EDITDie letzte HM485_fwUpdate.pl hat gut funktioniert. Habe zwei Geräte aktualisiert. Beim zweiten hatte ich während der "verify" Phase (lesen des EEPROM) ein paar SET Befehle abgeschickt. Haben den Prozess aber nicht gestört.
Gruß,
Thomas