[HBW] booter für HM Wired (OTA updates)

[loetmeister]

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.

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[maxx3105]

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 Du darfst diesen Dateianhang nicht ansehen.  , 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:

Code Auswählen Erweitern

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():

Code Auswählen Erweitern

#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:

Code Auswählen Erweitern

#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:

Code Auswählen Erweitern

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.