HMLANGW mit ESP32/HM-MOD-RPI-PCB

[andyboeh]

TL;DR
Das Projekt ist ein Port von "hmlangw" auf ESP32, zu finden unter https://github.com/andyboeh/esphome-hmlgw

--------
Ich verwende Homegear und habe lange nach Möglichkeiten gesucht, ein Funkmodul per TCP/IP anzubinden. Da ich an zentraler Stelle einen OpenWrt-Router habe, war es naheliegend, ein USB-Modul an den Router anzustecken. Mittels "hmlangw" funktioniert das auch sehr gut.

Nun suchte ich für die Erweiterung des Funkbereichs ein einfaches LAN-Gateway, idealerweise mit PoE, da bei mir LAN-Dosen in allen Räumen vorhanden sind. Leider unterstützt Homegear ser2net und ähnliche Bridges nicht besonders gut, weshalb eigentlich nur das HMLANGW in Frage kommt.

In letzter Zeit arbeite ich viel mit Home Assistant und ESPHome, deshalb wollte ich einen ESP32 (den gibt's mit PoE) dafür verwenden. Ich habe hardwaremäßig ein HM-MOD-RPI-PCB an I/O-Pins des ESP32 angeschlossen (inklusive Reset-Leitung!) und eine HMLANGW-Emulation für ESPHome gebaut (also das alte "hmlangw" auf ESP32 portiert). Ich verwende derzeit IO5 (RX), IO17 (TX) und IO33 (Reset).

Mir fehlen noch Langzeiterfahrungen, aber die ersten Tests mit einem WT32-ETH01 sind sehr positiv. Code und Beispielkonfiguration gibt's hier: https://github.com/andyboeh/esphome-hmlgw

Kosten: WT32-ETH01 gibt's in Deutschland um ca. €17,- und das HM-MOD-RPI-PCB um ca. €20,-. Alternativ würde ein Lilygo T-ETH-POE funktionieren, das hat neben LAN auch noch PoE. Theoretisch müssten auch günstigere Boards ohne LAN funktionieren, aber WiFi habe ich nicht getestet.

[homtic]

Hi,

interessantes Projekt! Kostentechnisch kann eine ausrangierte CCU2 zwar günstiger sein, aber die verwendete Hardware, also ESP32 mit LAN-Port kannte ich noch nicht. Mir ging dann sofort die Frage durch den Kopf, ob man das Board auch als Basis für die HB-RF-ETH nutzen kann, aber vermutlich ist der Flash-Speicher dafür zu knapp?!

Wird beim HMLANG WLAN beim Betrieb über LAN ausgestellt? Gibt es irgendeine (G)UI?

Welches Tool nutzt du zum kompilieren / flashen?

Ich kenne bis jetzt nur die Arduino-IDE, aber danach sieht es hier nicht aus, oder?

[homtic]

Wobei der Flash-Speicher laut der Spec 4 MB beträgt, auf irgendeiner anderen Website habe ich einen anderen, deutlich kleineren Wert gesehen.

[deimos]

Hi,

Mir ging dann sofort die Frage durch den Kopf, ob man das Board auch als Basis für die HB-RF-ETH nutzen kann, aber vermutlich ist der Flash-Speicher dafür zu knapp?!

Der Flash ist nicht das Problem, der ist bei beiden bei 4MB. Allerdings ist sowohl der Pinout, als auch die Anbindung an den LAN PHY nicht kompatibel und es fehlen auch ein paar zusätzliche Bauteile zum Anschluss des Funkmoduls.

Viele Grüße
Alex

[andyboeh]

Genau, der hat 4MB Flash, derzeit ist etwa 1MB belegt.

Am HB-RF-ETH ist auch ein ESP32 mit LAN-Modul, rein prinzipiell müsste es also gehen. Die Firmware ist auch Open Source, mit ein paar Anpassungen in der Firmware (hauptsächlich PIN-Änderungen) und ein paar zusätzlichen Hardware-Komponenten (Taster!) sollte das also gehen.

Mein Ziel war eine Emulation, damit in Homegear keine Änderungen notwendig sind. HB-RF-ETH benötigt auf der CCU Zusatzsoftware und wird vermutlich von Homegear nicht unterstützt (ich kann mich da aber täuschen).

Wird beim HMLANG WLAN beim Betrieb über LAN ausgestellt? Gibt es irgendeine (G)UI?

Soweit ich weiß unterstützt ESPHome keinen Mischbetrieb LAN <-> WLAN. Das ist aber ein Limit von ESPHome, der ESP32 kann es.

Das ganze ist eben in ESPHome integriert. Da ich HomeAssistant in Docker verwende, habe ich die GUI des ESPHome Containers direkt integriert. Von dort aus kann geflasht werden. Eingestellt wird alles per YAML Config-File - am besten mal nach ESPHome suchen.

Welches Tool nutzt du zum kompilieren / flashen?

ESPHome. Für den ersten Flash per Kabel lokal am PC, danach nur online.

[Mike_i386]

Zunächst einmal muss ich dir zutiefst meinen Dank aussprechen. Genau so etwas suche ich seit über einem Jahr.

Da auch ich HomeAssistant und ESP-Home einsetzte ist das perfekt.

Bei mir ist der Gedanke der, Raspberrymatic anstelle wie momentan in einer VM auf meiner Synology-NAS, in einem Docker-Container auf der NAS laufen zu lassen.
Dieses Projekt würde mir dies eventuell ermöglichen.

Aktuell habe ich nur einen Wemos D1 Mini und einen NodeMCU ESP32 da.
Vielleicht läuft es auch mit einem der beiden Boards.

[Mike_i386]

Ich habe das ganze gestern mal zusammengebaut und kann etwas berichten...

Das ganze ließ sich erstmal problemlos Flaschen... in der RaspberryMatic CCU habe ich dann den ESP als LanGateway eingetragen.
Nach einem Neustart der CCU konnte ich auf der Konsole Zugriffe sehen:

Code: Alles auswählen

[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 12 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 12 result 17
[D][hmlgw:312]: New client connected from 192.168.1.2
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 13 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 13 result 18
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 4 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 4 result 9
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 16 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 16 result 21
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 2 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 2 result 7
[D][hmlgw:085]: Client 192.168.1.2 disconnected
[D][hmlgw:095]: Keepalive Client 192.168.1.2 disconnected
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 19 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 19 result 24
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 22 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 22 result 27
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 20 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 20 result 25
[D][hmlgw:193]: read from UART
[D][hmlgw:170]: readBidcosFrame msgLen set 20 result 3
[D][hmlgw:175]: readBidcosFrame done, msgLen 20 result 25

Wie man allerdings erkennen kann gibt es nach kurzer Zeit ein disconnect:

Code: Alles auswählen

[D][hmlgw:085]: Client 192.168.1.2 disconnected
[D][hmlgw:095]: Keepalive Client 192.168.1.2 disconnected

Beim starten von Raspberrymatic ergeben sich auch ein paar Meldungen:

Code: Alles auswählen

Starting hs485dLoader: disabled
Starting xinetd: OK
Starting eq3configd: OK
Starting lighttpd: OK
Starting ser2net: disabled
Starting ssdpd: OK
Starting NUT services: disabled
Initializing Third-Party Addons: OK
Starting LGWFirmwareUpdate: ...OK
Setting LAN Gateway keys: OK
Starting hs485d: disabled
Starting multimacd: not required
Starting rfd: ....................ERROR
Starting HMIPServer: ..........OK
Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: OK
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK
Finished Boot: 3.61.7.20220208 (raspmatic_oci_amd64)

Wie man sich denken kann, kann die CCU so damit nichts anfangen.

Ich weis das ganze ist für Homegear gedacht aber irgendwie wäre es cool wenn auch eine CCU wie RaspberryMatic damit umgehen könnte...

Übersehe ich in meinem Nachbau etwas?

[jmaus]

In der Tat interessant das sich mal wieder jemand an dem alten "hmlangw" Quellcode vergangen hat. Insgesamt natürlich super, da "hmlangw" gewissen Bugs/Einschränkungen hat die noch keiner Zeit hatte komplett auszumerzen. So z.B. das Reconnection-Problem das hin+wieder auftritt.

Statt hier also ein komplett unabhängiges Projekt zu machen, wäre es ganz schön gewesen eben nicht nur den ESP32 nutzungsfall im Blick zu haben, sondern das ganze so zu entwickeln, das man eventl. Änderungen dann auch zu RaspberryMatic&Co zurückgemerged bekommt. Aktuell liegen dort die hmlangw quellen ja hier:

https://github.com/jens-maus/RaspberryM ... ge/hmlangw

Auch möchte ich folgendes bei der Entwicklung dieses Projektes noch zu bedenken geben:

1. Ganz offensichtlich basiert die Entwicklung des Quellcodes dieser ESP32 Variante von hmlangw stark auf den Quellen+Knowhow des hmlangw.cpp von Oliver Kastl von 2015. Es findet sich jedoch keinerlei Credit diesbzgl. auf der GitHub Projektseite wieder. Auch fehlt das Copyright-Notice von Oliver Kastl komplett in den Quellen dieser ESP32 Variante. Das verstößt meines Erachtens jedoch gegen die Lizenzbedingungen die Oliver Kastl explizit in seinen hmlangw.cpp Quellen vorgenommen hat (siehe https://github.com/jens-maus/RaspberryM ... mframe.cpp).
2. Gerne würde ich natürlich diese neuere hmlangw Variante mit in das RaspberryMatic Projekt aufnehmen wollen (also quasi upstream). Jedoch wurde als Lizenz dieser ESP32 Variante GPL3 ausgewählt. Das beisst sich leider mit der Apache 2.0 Lizenz unter der RaspberryMatic bzw. OCCU steht. Insofern wäre es schön wenn dieses Projekt unter Apache 2.0 re-lizenziert werden könnte. Denn ich erhoffe mir in der tat eventl. noch nicht ganz korrekt umgesetzte Dinge in der ursprünglichen hmlangw Entwicklung mit dieser neueren ggf. ausbüglen zu können.

Insgesamt aber wie gesagt ein dickes Lob an diese Weiterentwicklung, denn die Hoffnung ist wirklich groß das damit ggf. alle restlichen Problemchen ausgebügeln werden die in der ursprünglichen "hmlangw" einfach noch nicht umgesetzt wurden.

[Mike_i386]

Leider bin ich kein Programmierer sondern in diesem Fall nur Nutzer, sonst würde ich gerne behilflich sein.

Ich fände es jedoch auch super klasse wenn sich hier etwas weiter- oder neuentwickeln ließe, um RaspberryMatic mit der Kombination ESP + HM-MOD-RPI-PCB zu verheiraten.

Selbstverständlich würde ich mich für Tests gerne anbieten.

[andyboeh]

Ich freue mich, dass endlich jemand den Thread gefunden hat! Warum bekomme ich standardmäßig keine Benachrichtigung, wenn jemand antwortet, obwohl lich es abonniert habe!?

Anyway, ein langer Post:

• Mittlerweile hat es ein anderer User mit FHEM zum Laufen bekommen - ein paar Bugs mussten wir dafür auch ausbügeln, wo FHEM einfach genauer als Homegear ist.

• Für alle Implementierungen, die das HM-MOD-RPI-PCB per ser2net ansprechen können, ist das mMn unnötiger Overhead. Selbst für ESPHome gibt es eine Komponente (ist aber nicht offiziell), die das ermöglicht - nennt sich StreamServer und darauf basiert meine Implementierung auch. Ich brauche diese Emulation nur, weil Homegear mit ser2net nicht so ohne gröbere Tricks umgehen kann.

• Lizenz: Normalerweise bemühe ich mich, den Lizenzteil (annähernd) korrekt umzusetzen. In den Source Files fehlt der Verweis, Credits sind aber sehr wohl vorhanden, und zwar im README, das im Githb-Projekt auch gleich beim Start angezeigt wird. Das verweist zwar auf den Forum-Post, aber dort ist hmlangw-0.0.2.zip zu finden, das ich verwendet habe. Auch ist eine Referenz auf den StreamServer (ser2net für ESP32) zu finden. Gerne ergänze ich die fehlenden Namen / Verweise in den Quellen.

• Ich bin kein Lizenz-Profi. Was hätte Apache für eine Auswirkungen bzw. geht das überhaupt, wenn die Original-Version GPL war?

Und bezüglich upstream und Bugs: Ich habe hmlangw auch auf OpenWrt "portiert" (=ein Paket daraus gemacht und eine Compiler-Warnung gefixt) und verwende es täglich und problemlos. Reconnect-Probleme sehe ich nur dann, wenn die Verbindung verloren geht. Ich hatte hier eher an ein Limit in Homegear gedacht!? Siehe https://github.com/andyboeh/hmlangw und https://github.com/andyboeh/openwrt-packages (da fehlt das README, dafür sind die Copyrights in den Sourcen intakt).

EDIT: Wenn ich mit nicht irre, kann man RaspberryMatic in Docker aufsetzen, oder? Das werde ich in ein paar Wochen für eine Wohnung ohnehin machen, dann kann ich mir die Kombination ja mal ansehen.