HomeBrewWired - Diskussion zum Tutorial

[maxx3105]

Hallo Thomas,

Ich habe den OWN_ADDRESS Part der XML's im HBWired fork wieder entfernt da in fhem ohnehin mit

Code Auswählen Erweitern

set <dev> raw 4061<4 Byte> funktioniert. Auf der OpenCCU gibt es diese Möglichkeit leider nicht. Ich habe das in eni ADDON der CCU verschoben da dies ohnehin für den reibungslosen Betrieb der HBW Gerät von Vorteil ist. Damit der HBWired fork wieder commit konform bleibt.

Freut mich das es "richtigen" Bus nun auch funktioniert.

Den mega32 hatte ich integriert um meine zerschossenen HMW Geräte wieder lauffähig zu bekommen.

Grüße Markus

Edit: An den BUS Kommandos habe ich auch etwas herum gespielt.
**ELV-Grundbefehlssatz — 11 Befehle, vollständig 📄**

| Kmd | Hex | Richtung | Bedeutung |
|---|---|---|---|
| `K` | 0x4B | ↔ | Key-Event: `K <sensor> <zielaktor> <event>`; Event-Bits `RRYYTTEE` — `EE` 00=gedrückt/01=gehalten/10=losgelassen, `TT` Zähler je Loslassen, `YY` Tastentyp (Toggle/Hoch/Runter) |
| `s` | 0x73 | →Gerät | Aktor setzen: `s <sensor> <zielaktor> <aktion>` |
| `S` | 0x53 | →Gerät | Aktorzustand abfragen → Antwort: Aktornummer + Zustand |
| `h` | 0x68 | →Gerät | Modultyp + Hardware-Version (je 1 Byte), z. B. `1B 00` |
| `v` | 0x76 | →Gerät | Firmware-Version, `03 04` = v3.04 |
| `!` | 0x21 | →Gerät | Reset — **zweites Byte muss ebenfalls `!` sein**, sonst wird verworfen |
| `C` | 0x43 | →Gerät | Konfiguration neu aus dem EEPROM lesen |
| `R` | 0x52 | →Gerät | EEPROM lesen `<addrHi addrLo len>`, max. **64 Byte**; Antwort = **rohe Bytes ohne cmd-Prefix** |
| `W` | 0x57 | →Gerät | EEPROM schreiben `<addrHi addrLo len data...>`, laut ELV max. **32 Byte** je Nachricht |
| `q` | 0x71 | ↔ | **Zieladresse hinzufügen** — Peering ohne EEPROM-Schreibzugriff, mit Eingangs- und Aktornummer |
| `c` | 0x63 | ↔ | **Zieladresse löschen** — Gegenstück zu `q` |

**`Q` (0x51) ist das Peering-Kommando — nicht `q`/`c` ✅ (23.08.2026 am Bus gemessen)**

Die frühere Annahme, `q`/`c` seien der Anlernweg ohne PC, konnte ich nicht bestätigen. In keinem
einzigen Mitschnitt dieser Sitzung tauchte `q` oder `c` auf. Stattdessen:

| Kmd | Hex | Richtung | Bedeutung |
|---|---|---|---|
| `Q` | 0x51 | Sensor → Aktor | `Q <Sensorkanal> <Aktorkanal>`, **Unicast**, ~50 ms nach dem Key-Broadcast |

Gemessen beim Direktverknüpfen H21-Taste → H20-Dimmer ohne Zentrale:
`51 00 02` und `51 01 02`. Danach hält **der Sensor** beide Peer-Records selbst (0x0356).

[loetmeister]

Hi,

es spricht ja nix dagegen die Geräteadresse per config / XML ändern zu können... auch wenn es mit dem RAW Befehl klappt, ist das schon praktisch.
Habe mal ein wenig probiert... was mit FEHM funktioniert, und hoffendlich auch per CCU:
Write EEPROM macht die Prüfung auf ownAddressWritable, wird aber erst mit 'C' / readConfig(), nach Beendigung aller EEPROM write, per handleAfterReadConfig() übernommen.
Wenn ein 'C' immer nach Abarbeitung aller 'W' kommt, dann sollte das so klappen. Beim RAW cmd 0x4061... setze ich dann bloß pendingActions.readAddress und afterReadConfig = true, dann verhält es sich genau so.

So sieht es im Debug log aus: (neben OWN_ADDRESS gibt es noch LOGGING_TIME, daher zwei 'W')

Code Auswählen Erweitern

22:18:04.430 -> R: FD:42:00:00:63:1A:00:00:00:01:0A:57:03:FC:7C:04:42:00:00:63:3E:56
22:18:04.430 -> C: Write EEPROM
22:18:04.430 -> frameDataLen: 8 adrStart: 1020
22:18:04.430 -> T: FD:00:00:00:01:39:42:00:00:63:02:D6:FC
22:18:04.529 -> R: FD:42:00:00:63:1C:00:00:00:01:07:57:00:01:01:0B:4B:72
22:18:04.529 -> C: Write EEPROM
22:18:04.529 -> T: FD:00:00:00:01:59:42:00:00:63:02:EB:B4
22:18:04.529 -> R: FD:42:00:00:63:1E:00:00:00:01:03:43:E0:F8
22:18:04.529 -> T: FD:00:00:00:01:79:42:00:00:63:02:0F:72
22:18:04.533 -> Applied new Addr

Die Prüfung auf Länge und Start Adresse hatte ich vor den loop gesetzt...
frameDataLength == 8 && adrStart >= E2END - 4 - weiß nicht ob das bei der CCU auch passt? Die Adresse ist ja eigentlich mit index="0x03FC" aus der XML vorgegeben...

Code Auswählen Erweitern

         case 'W':                                                               // Write EEPROM
            if(frameDataLength == frameData[3] + 4) {
               hbwdebug(F("C: Write EEPROM\n"));
               adrStart = ((uint16_t)(frameData[1]) << 8) | frameData[2];  // start adress of eeprom
               bool ownAddressWritable = false;
               // if(frameData[3] < 10) {
               if(frameDataLength == 8 && adrStart >= E2END - 4) {
                 for(byte i = 4; i < frameDataLength; i++) {
                   // if((adrStart+i-4 > E2END - 4) && frameData[i] != 0xFF) {
                   if(frameData[i] != 0xFF) {
                     ownAddressWritable = true;
                     break;
                   }
                 }
               }
               for(byte i = 4; i < frameDataLength; i++){
                 writeEEPROM(adrStart+i-4, frameData[i], ownAddressWritable);
               }
               /* Erst 'C' / readConfig(), nach Beendigung aller EEPROM write, uebernimmt
   im loop() die neue Adresse per handleAfterReadConfig() -- kein Neustart noetig. */
               if (!pendingActions.readAddress) pendingActions.readAddress = ownAddressWritable;
            };
Bei einem reset (EEPROM alles auf 0xFF) sehe ich

Code Auswählen Erweitern

R: FD:42:00:00:65:1C:00:00:00:01:16:57:03:F0:10:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:69:FC:7E
C: Write EEPROMStart 0x3F0? müsste dann die letzten 4 Byte überschreiben. Wobei mir nicht klar ist warum das die Startadresse ist, da ja nur 4 Byte in der XML angegeben sind. Wir immer in 16 Byte Blöcken gelöscht?

Gruß,
Thomas