hwlangw Dämon revived

[pahenning]

Ich habe in dem Code für den HM-LAN-Gateway Dämon die veralteten Schreibbefehle auf das sysfs durch die bei den neueren Kernel-Versionen erforderlichen Aufrufe der gpiod-Library ersetzt. Funktioniert schon ganz gut, der hmlangw-Dämon lässt sich unter bookworm installieren und empfängt Daten von HM-Geräten ebenso wie von einer RaspberryMatic. Bisher behauptet aber die RaspberryMatic steif und fest, sie sei mit dem Gateway nicht verbunden.

Hat jemand Interesse, das mit mir zu diskutieren?

LG

pah

[jp112sdl]

Anschauen würde ich es mir mal.
Wo ist denn der Code zu finden? Kannst du es ihn in Github bereitstellen?
Dann kann man da gut gemeinsam dran arbeiten

[pahenning]

Hallo Jérôme,

ich hatte darauf gehofft, dass einer der ursprünglichen Autoren sich beteiligt

Code ist hier: https://github.com/pahenning/HMLANGW_revived

Die Änderungen sind eigentlich ziemlich trivial, ich habe den alten Code in hmlangw.cpp deshalb vorerst nur auskommentiert.

Vor der Übersetzung benötigt man mit dem aktuellen Linux-Kernel noch ein
apt install libgpiod-dev gpiod

Das Problem ist derzeit, dass eine RaspberryMatic die Verbindung nach der ersten Kontaktaufnahme abbricht.

LG

pah

[jp112sdl]

dass eine RaspberryMatic die Verbindung nach der ersten Kontaktaufnahme abbricht.

Welche RaspberryMatic Version (Release ? Nightly ?) verwendest du ?

[pahenning]

Ich habe 3.81.5.20250527 auf einem RPI3.

Im Debug-Modus des hmlangw lese ich z.B. bei der Kontaktaufnahme seitens der RaspberryMatic:

2025-06-17 04:39:40.136 received 4 bytes: K0c
2025-06-17 04:39:41.147 received 4 bytes: K0d
2025-06-17 04:39:42.158 received 4 bytes: K0e
2025-06-17 04:39:43.169 received 4 bytes: K0f
2025-06-17 04:39:44.181 received 4 bytes: K10
2025-06-17 04:39:45.181 Keepalive client closed connection.

LG

pah

[jmaus]

Hat jemand Interesse, das mit mir zu diskutieren?

Gerne! Erst einmal natürlich recht herzliches Dankeschön, dass mal wieder jemand über den hmlangw drüberschaut, auch wenn das Ding im Grunde ja gut läuft und eigentlich IMHO schon länger "feature-complete" ist

Was deine Anpassungen angeht, so betreffen die ja lediglich die openResetFile/Line() Funktion und die darin enthaltenen Zugriffe auf das sysfs, um die GPIO (genauer gesagt das reset GPIO) des HM-MOD-RPI-PCB zu triggern. Dazu sei erst einmal gesagt, dass diese Funktion beim Einsatz von hmlangw innerhalb von RaspberryMatic ja gar nicht zum Einsatz kommt, weil der Funkmodul-Reset da völlig unabhängig vom hmlangw abläuft und folglich von dem dann auch nicht genutzt wird. Insofern sind für den Betrieb innerhalb von RaspberryMatic (wenn man das als LAN-Gateway ummünzt) deine Anpassungen nicht wirklich relevant. Trotzdem können die ja natürlich – wenn man hmlangw auf einem anderen System (z.B. Ubuntu/Debian) laufen lässt – relevant sein, wenn man da den Funkmodul reset nicht separat machen möchte bzw. kann. Insofern würde ich vorschlagen, du baust deine Änderungen am besten in einem Fork des RaspberryMatic repos ein, denn da liegen ja die momentan die aktuellsten Quellen von hmlangw (siehe https://github.com/jens-maus/RaspberryM ... ge/hmlangw), damit dann auch in Zukunft andere drüber stolpern können. Und dann kannst du gegen RaspberryMatic einen PullRequest öffnen und so deine Anpassungen bei GitHub direkt zur Diskussion stellen und dort "reinmergen" lassen.

Und was mich natürlich noch etwas verwirrt ist, dein Hinweis, dass angeblich die Quellen nicht auf einem System mit Kernel >5.15 kompilieren. RaspberryMatic nutzt ja schon länger Kernel 6.x und da kompiliert hmlangw problemlos. Nur kann es eben sein, dass diese OpenResetFile() Funktion vielleicht nicht richtig gehen würde, aber die wird ja wie gesagt unter RaspberryMatic ohnehin nicht genutzt. Sieht man auch im Startup-Script (siehe https://github.com/jens-maus/RaspberryM ... mlangw#L19) da dort die Option "-r -1" explizit gesetzt wird.

[pahenning]

Hi Jens,

ich weiß nicht, wie ihr das bei dem in die RaspberryMatic integrierten hmlangw gemacht habt. Für den standalone-code gilt jedenfalls:

Seit Linux Kernel 5.10 (und besonders ab 5.19) wird empfohlen, das alte GPIO-Sysfs-Interface (/sys/class/gpio/...) nicht mehr zu verwenden, da es deprecated ist. Stattdessen soll das neue Character Device GPIO Interface (/dev/gpiochipX) verwendet werden.

Ich muss mich korrigieren: Übersetzen kann man den alten Code trotzdem noch. Aber unter bookworm gibt es beim Start eine Fehlermeldung wegen eines sysfs-Zugriffs auch dann, wenn man mit -r -1 startet. Sonst hätte ich mich mit dem Thema überhaupt nicht befasst, weil ich nach 25 Jahren als Hochschullehrer für Informatik meine Coding-Aktivitäten auf den Bereich FHEM beschränke.

Diese Änderungen sind dann wirklich nur trivial, das habe ich oben ja schon geschrieben. Gerne kann ich sie in einen Fork einbauen, allerdings kämpfe ich im Moment noch damit, dass die aktuelle RaspberryMatic den Kontakt zum hmlangw sofort wieder abbricht, siehe oben.

LG

pah

[jp112sdl]

dass die aktuelle RaspberryMatic den Kontakt zum hmlangw sofort wieder abbricht

Auch dann, wenn du deine Änderungen im Code rückgängig machst?
Also als Ausschluss, ob es generell an deinem eigenen Kompilat in Verbindung mit RM liegt

[pahenning]

Ja. Habe ich alles getestet. Die RaspberryMatic meldet immer nur "nicht verbunden", und der hmlangw immer so wie oben beschrieben " Keepalive client closed connection". Wohlgemerkt: _Nach_ dem Empfang einiger Pakete, die nicht von HM-Geräten stammen, sondern von der RM.

LG

pah

[jp112sdl]

So, ich konnte deinen Code ausm Github nun mal kompilieren es funktioniert alles wie es soll.

Links der "hmlangw", rechts der "rfd" und darunter die WebUI der RM.

Im Debug-Modus des hmlangw lese ich z.B. bei der Kontaktaufnahme seitens der RaspberryMatic:

2025-06-17 04:39:40.136 received 4 bytes: K0c
2025-06-17 04:39:41.147 received 4 bytes: K0d
2025-06-17 04:39:42.158 received 4 bytes: K0e
2025-06-17 04:39:43.169 received 4 bytes: K0f
2025-06-17 04:39:44.181 received 4 bytes: K10
2025-06-17 04:39:45.181 Keepalive client closed connection.

Auf welcher Hardware läuft denn bei dir der "hmlangw" ?
Mir scheint es eher, als gäbe es ein Problem mit der UART Kommunikation zum Funkmodul.
Ich hatte eben beim Testen auf dem Pi5 naiver Weise erst /dev/serial0 genommen, weil das Device schon da war und ich davon ausging, es sei der Serialport am Pin-Header. War es aber nicht... Muss man erst aktivieren... dann ist auch /dev/ttyAMA0 da

Jedenfalls sah es beim ersten Scheitern auch so aus: