Homematic Wired (W)LAN Gateway

[maxx3105]

Hallo Miteinander,

Da das originale HMW-LGW-O-DR-GS-EU nicht mehr produziert wird habe ich mich Hilfe einer KI dann gemacht einen Ersatz zu bauen. Welche Anforderungen soll das für FHEM erfüllen? Die Hardware läuft aktuell auf einem ESP32 somit kann es per LAN als auch WLAN angebunden werden. Serial und Passphrase. WebServer zur Konfiguration habe ich bereits eingeplant. AES AN/AUS hätte ich auch eingeplant. Habt ihr noch anregungen?

LG Markus 

[maxx3105]

Das Gateway läuft soweit. Bitte ausführlich testen.
https://github.com/maxx3105/HMW-Gateway-Pro

[Ralf9]

Hallo Markus,

die Idee hatte ich auch schon, aber ich habe den Code von der HM485_Protocol.pm nicht komplett verstanden.

Ich habe über Deinen Code mal drüber geschaut.
In der HM485_Protocol.pm wird nach dem Senden auf eine Antwort oder ack gewartet und dann ggf die die Nachricht bis zu zwei mal wiederholt, ich konnte dazu in Deinem Code nichts finden.
https://github.com/kc-GitHub/FHEM-HM485/blob/master/FHEM/lib/HM485/HM485d/HM485_Protocol.pm

In der Protokollbeschreibung steht dazu folgendes:

1.1.1. Vermeidung von Kollisionen auf dem RS485 Bus
Das Protokoll auf dem Bus muss Multimaster-Eigenschaften unterstützen. Es existiert mit der CCU zwar eine Zentrale
die auch die Kommunikation steuert, einzelne Module müssen aber auch ohne Aufforderung durch diese Senden
können. Z.B. bei anliegenden Events (Tastendrücke, geänderte Sensordaten usw.)

Die Informationen zur Kollisionsvermeidung sind derzeit Vermutungen von mir. Ggf. bedarf es noch einer weiteren
Überprüfung Vermutlich werden CSMA/CA Techniken eingesetzt.

- Die Module "überwachen" permanent den Bus (Carrier Sense)

- Ist der Bus für eine bestimmte Zeit (DIFS*) frei (welche muss noch rausgefunden werden) wartet das Modul
noch eine zufällige Zeit (Backoff) (ggf. auch abhängig der Geräteadresse).
Ist der Bus weiterhin frei, kann das Modul senden.

- Nach vollständigem Empfang einer Nachricht wartet das Modul noch eine gewisse Zeit (SIFS**) und sendet
dann die ACK Nachricht oder die Antwort.

- Bleibt die Antwort aus (missing ACK) wird nach einer Wartezeit (EIFS***) die Nachricht bis zu zwei mal wie-
derholt.

Gruß Ralf

[maxx3105]

Ich habe deine Frage an Claude (KI) weitergeleitet weil die ganze Programmierung meine Kenntnis etwas übersteigt.

Hallo Ralf,

guter Punkt — und du suchst genau richtig, nur an der falschen Stelle. Die Wiederhol-Logik fehlt im Gateway mit Absicht, weil sie dort nicht hingehört. Verräterisch ist der Pfad deiner eigenen Datei: HM485/HM485d/HM485_Protocol.pm liegt im HM485d, also im Daemon — nicht im LGW. Bei einer echten CCU steckt dieselbe Logik im hs485d.

Man muss drei Dinge trennen, die in der Protokollbeschreibung zusammen stehen:

1. ,,Bleibt die Antwort aus → bis zu 2× wiederholen" (EIFS).
Das ist End-zu-End-Retransmission und die macht der Master, nicht das Gateway. Das LGW ist nur ein Modem/Transceiver: Es nimmt ein S-Kommando von der CCU an, legt das eingebettete Busframe einmal auf den Bus und gibt die Geräteantwort als r zurück. Kommt keine Antwort, gibt es kein r — und der Master (bei dir FHEM/HM485_Protocol.pm, bei mir die CCU/hs485d) schickt das S erneut. Würde das Gateway zusätzlich selbst wiederholen, hättest du Doppel-Sends. Das deckt sich mit meinen Bus-Mitschnitten des Original-LGW: Auf der LAN-Seite gibt es ein S-Kommando mit Mode-Byte (0xC8 = Unicast+ACK / 0x00 = Broadcast), die CCU schickt genau ein S und erwartet genau ein r; wiederholt wird oben.

2. ,,Nach Empfang SIFS abwarten, dann ACK senden".
Das macht mein Gateway — es ist die einzige ACK-Ebene, die tatsächlich ins LGW gehört. In busAck() schicke ich nach jeder adressierten Geräteantwort ein len02-Null-Frame (Control-Basis 0x19 + txSeqNum) zurück, damit das Gerät aufhört, seine Antwort zu wiederholen. Das hatte ich anfangs vergessen — Folge: Geräte sendeten ihre Antwort 3× und gaben auf. Seit busAck drin ist, läuft die Interrogation sauber durch.

3. ,,Bus überwachen (Carrier Sense), DIFS-Idle, Backoff" (CSMA/CA).
Hier bin ich ehrlich: Mein ESP32-LGW macht vor dem Senden aktuell keinen expliziten Carrier-Sense — es sendet direkt. In meinem Python-Prototyp ist es drin (_wait_idle() = DIFS, plus send_acked() mit 3 Retries, Werte aus HBWired: DIFS ~210–310 ms, ACKWAITTIME 200 ms), aber das ist der Standalone-Master-Modus, wo Python die CCU komplett ersetzt. Im LGW-Betrieb trage ich das (noch) nicht nach, weil der Verkehr fast durchweg Frage→Antwort ist (strikt halb-duplex, das Gerät hat gerade keinen Sendegrund, wenn ich sende) und weil kollidierende spontane Events doppelt abgesichert sind: Das sendende Gerät macht selbst Carrier-Sense + 3 Retries, und der Master retryt Ende-zu-Ende. Eine einzelne verlorene Kollision wird also so oder so wiederholt. Das Original-LGW macht Carrier-Sense vermutlich in seiner Firmware; wenn du in deiner Umgebung (viele Sensoren/Taster = viel spontaner Verkehr) tatsächlich Kollisionen siehst, baue ich den _wait_idle()-Ansatz gern auch ins Gateway ein — es ist im Grunde: vor busSend() warten, bis der Bus X ms still war, plus kleiner Zufalls-Backoff.

Kurz: Ebene 1 (dein Fund) ist Absicht und liegt im Daemon, Ebene 2 ist drin (busAck), Ebene 3 ist eine bewusste Vereinfachung, die man bei Bedarf nachrüsten kann.

[Ralf9]

Das LGW ist nur ein Modem/Transceiver

Das ist dann aber kein Gateway sondern nur ein Netzwerk-RS485-Adapter ähnlich dem WIZ108SR.
Da passt es dann, es muss nicht auf eine Antwort gewartet und dann ggf die die Nachricht bis zu zwei mal wiederholt werden, das macht ja der HM485d.
Die FHEM Definition müsste ungefähr so aussehen:

Code Auswählen Erweitern

define hm485 HM485_LAN localhost:2000
attr hm485 HM485d_device 192.168.0.x:1000
Bei einem richtigen Gateway wird der HM485d Daemon nicht benötigt.