hwlangw Dämon revived

Nutzung von XML RPC, Remote Script, JSON RPC, XMLAPI

Moderator: Co-Administratoren

jp112sdl
Beiträge: 12493
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 911 Mal
Danksagung erhalten: 2252 Mal
Kontaktdaten:

Re: hwlangw Dämon revived

Beitrag von jp112sdl » 20.06.2025, 12:28

pahenning hat geschrieben:
18.06.2025, 13:57
wenn ich auf der Kiste eine debmatic installiere, funktioniert diese problemlos.
Ok, das hatte ich übersehen.
Nun wird es klarer:

Code: Alles auswählen

2025/06/20 12:04:54.912 CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Unknown command type: 03 (hex).
2025/06/20 12:04:54.912 <Debug> (RPI3GW0001) CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2025/06/20 12:04:59.288 <Debug> CCU2CommController::improvedInit() - Timeout while waiting for coprocessor application
2025/06/20 12:04:59.289 CCU2CommController::SendSystemCommdand()
Das Funkmodul läuft wahrscheinlich mit der DualCoPro Firmware 2.8.6
So ist es für Debmatic auch richtig, wenn der RFD über den Multimacd darauf zugreift.

Der hmlangw kann aber damit nicht.

Entweder du machst das Downgrade auf die CoPro Firmware 1.4.1 (siehe mein Screenshot)
Oder du schaltest den multimacd dazwischen (Funkmodul>multimacd>hmlangw mit /dev/mmd_bidcos)

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

pahenning
Beiträge: 14
Registriert: 17.06.2025, 09:20
System: sonstige
Hat sich bedankt: 5 Mal

Re: hwlangw Dämon revived

Beitrag von pahenning » 20.06.2025, 15:00

Aha, das war es, sehr schön und herzlichen Dank.

Im nächsten Schritt werde ich den von mir geänderten Code bei RaspberryMatic als Request einstellen - das kann man vlt. bei Gelegenheit übernehmen.

Desweiteren aber bin ich bei dieser Angelegenheit wieder einmal darüber gestolpert, dass die Informationen über die diversen Methoden zur Anbindung von HM /HMIP sehr fragmentiert vorliegen. Ich werde versuchen im FHEMWIki eine entsprechende Übersichtsseite anzulegen. Ich denke, das spart Euch einiges an Arbeit.

LG

pah

mittelhessen
Beiträge: 262
Registriert: 24.07.2015, 21:39
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 15 Mal
Danksagung erhalten: 4 Mal

Re: hwlangw Dämon revived

Beitrag von mittelhessen » 11.07.2025, 16:41

pahenning hat geschrieben:
17.06.2025, 09:25
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.
Fachlich einige Ebenen tiefer, möchte ich erfragen:

Könnten die veralteten Schreibbefehle die Ursache dafür sein, dass sich mein HomeMatic RF-LAN Gateway schon seit einer Weile nicht mehr mit meiner Raspberrymatic (3.83.6.20250705) verbindet?

Mein HM-LAN-Gateway hatte schon immer mal hinsichtlich der Verbindung rumgezickt, lief nun aber lange Zeit zufriedenstellend. Seit ein paar Wochen verbindet es sich jedoch nicht mehr. Die Netzwerk-LED am HM-LAN-Gateway selbst blinkt. Mehrere Neustarts des HM-LAN-Gateways, der Raspberrymatic selbst, Reset auf Werkseinstellungen des HM-LAN-Gateway, löschen und neu hinzufügen blieb bis dato erfolglos.

Benutzeravatar
jmaus
Beiträge: 10709
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 608 Mal
Danksagung erhalten: 2645 Mal
Kontaktdaten:

Re: hwlangw Dämon revived

Beitrag von jmaus » 11.07.2025, 17:03

mittelhessen hat geschrieben:
11.07.2025, 16:41
pahenning hat geschrieben:
17.06.2025, 09:25
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.
Fachlich einige Ebenen tiefer, möchte ich erfragen:

Könnten die veralteten Schreibbefehle die Ursache dafür sein, dass sich mein HomeMatic RF-LAN Gateway schon seit einer Weile nicht mehr mit meiner Raspberrymatic (3.83.6.20250705) verbindet?
Nein, das kann damit nicht zu tun haben.
OpenCCU 3.87.6.20260404 @ ProxmoxVE / OpenCCU Hauptentwickler / ~200 Geräte + ioBroker + HomeAssistant / GitHub / Sponsors / PayPal / ☕️

mittelhessen
Beiträge: 262
Registriert: 24.07.2015, 21:39
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 15 Mal
Danksagung erhalten: 4 Mal

Re: hwlangw Dämon revived

Beitrag von mittelhessen » 11.07.2025, 17:30

Danke für Deine schnelle Antwort. Schade, sonst wäre ich der möglichen Ursache ein Stückchen näher gekommen.


mittelhessen
Beiträge: 262
Registriert: 24.07.2015, 21:39
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 15 Mal
Danksagung erhalten: 4 Mal

Re: hwlangw Dämon revived

Beitrag von mittelhessen » 12.07.2025, 12:58

Sorry für die unpräzise Beschreibung. Es handelt sich bei mir nicht um das "Ufo", sondern um das HM-LGW-O-TW-W-EU-2.

rentier-s
Beiträge: 915
Registriert: 19.06.2017, 09:24
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 34 Mal
Danksagung erhalten: 153 Mal

Re: hwlangw Dämon revived

Beitrag von rentier-s » 01.04.2026, 18:07

Kann es sein, dass das hmlangw auf 64bit Bookworm nicht läuft?

make hat grundsätzlich funktioniert, aber bereits mit Warnungen, die ich nicht wirklich verstehe.

Code: Alles auswählen

root@RaspberryPi:/usr/src/hmlangw# make
g++ -c -O2 -pipe -Wall hmlangw.cpp
g++ -c -O2 -pipe -Wall hmframe.cpp
hmframe.cpp: In function ‘int sendEnterBootloader(int)’:
hmframe.cpp:79:26: warning: format ‘%s’ expects argument of type ‘char*’, but argument 3 has type ‘int’ [-Wformat=]
   79 |       fprintf( stderr, "%s sendEnterBootloader(%d)\n", fd, currentTimeStr());
      |                         ~^                             ~~
      |                          |                             |
      |                          char*                         int
      |                         %d
hmframe.cpp:79:49: warning: format ‘%d’ expects argument of type ‘int’, but argument 4 has type ‘char*’ [-Wformat=]
   79 |       fprintf( stderr, "%s sendEnterBootloader(%d)\n", fd, currentTimeStr());
      |                                                ~^          ~~~~~~~~~~~~~~~~
      |                                                 |                        |
      |                                                 int                      char*
      |                                                %s
hmframe.cpp: In function ‘bool isBootloaderReply(const void*, int)’:
hmframe.cpp:125:13: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
  125 |     if( len >= sizeof(bootloaderReply) )
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
hmframe.cpp:131:13: warning: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
  131 |     if( len >= sizeof(bootloaderReply2) )
      |         ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
g++ -o hmlangw hmlangw.o hmframe.o -lgpiod -lpthread
/usr/bin/ld: hmlangw.o: in function `main':
hmlangw.cpp:(.text.startup+0x574): warning: the use of `tempnam' is dangerous, better use `mkstemp'
Egal mit welchen Parametern ich hmlangw ausführe, bekomme ich immer nur "Speicherzugriffsfehler" ohne irgendwelche weiteren Details.

Nur ohne -n funktioniert, aber dann funktioniert halt nichts, außer dass eine Meldung kommt, dass -n fehlt.

Code: Alles auswählen

Linux RaspberryPi 6.12.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1~bookworm (2026-01-19) aarch64 GNU/Linux

Code: Alles auswählen

root@RaspberryPi:/usr/src/hmlangw# ls -al /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 64  1. Apr 17:32 /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 67  1. Apr 17:32 /dev/ttyAMA3

Mit -g kompiliert kommt das raus:

Code: Alles auswählen

(gdb) run -n show
Starting program: /usr/src/hmlangw/hmlangw -n show
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000007ff7f93360 in gpiod_chip_get_line () from /lib/aarch64-linux-gnu/libgpiod.so.2

Mit scheint, als ob sich da ein Fehler eingeschlichen hat, gpiod_chip_get_line will als ersten Parameter ein Objekt, müsste "chip" sein, nicht 0.

Code: Alles auswählen

static int openResetLine(int port) {
    struct gpiod_chip *chip;
    int ret;

    chip = gpiod_chip_open_by_number(0); // z.B. 0 für /dev/gpiochip0
    if (!chip) {
        perror("Open gpiochip failed");
        return -1;
    }

    g_resetLine = gpiod_chip_get_line(chip, port);
    if (!g_resetLine) {
        perror("Get gpio line failed");
        gpiod_chip_close(chip);
        return -1;
    }

    ret = gpiod_line_request_output(g_resetLine, "my-app", 0); // Direction: output, initial value: 0
    if (ret < 0) {
        perror("Request line as output failed");
        gpiod_chip_close(chip);
        return -1;
    }
    return 0;
}

Damit komme ich schon mal ein Stück weiter.

Code: Alles auswählen

./hmlangw -n show
2026-04-03 17:15:23.827 write() could not set reset line to 0
2026-04-03 17:15:23.837 write() could not set reset line to 1
sh: 1: /lib/ld-linux.so.3: not found
2026-04-03 17:15:23.839 can't get serial number!
2026-04-03 17:15:23.839 write() could not set reset line to 0
2026-04-03 17:15:23.849 write() could not set reset line to 1

Mit manueller Angabe der Seriennummer -n NEQ... und ohne Reset -r -1 startet der Daemon. Danach passiert nicht mehr viel.

Ich bin mir nicht sicher, für was ich das Funkmodul zuletzt genutzt habe, könnte sein, dass da eine neuere Firmware drauf ist. Ich richte bei Gelegenheit einen Pi3 mit 32bit OS ein und versuche dort, hmlangw zum laufen zu bekommen.
Zuletzt geändert von rentier-s am 04.04.2026, 10:06, insgesamt 1-mal geändert.

rentier-s
Beiträge: 915
Registriert: 19.06.2017, 09:24
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 34 Mal
Danksagung erhalten: 153 Mal

Re: hwlangw Dämon revived

Beitrag von rentier-s » 07.04.2026, 09:03

Letztlich habe ich hmlangw nicht gebacken bekommen, also habe ich testweise OpenCCU auf eine SD Karte geschrieben und das als HM LAN Gateway gestartet. Das HM-MOD-RPI-PCB wurde erkannt und ich konnte das Gateway in PiVCCU3 einrichten.

Etwas später am Abend fiel mir ein extrem seltsames Verhalten auf. Vier HM-Sec-SCO und zwei HM-Sec-RHS, die ich dem Gateway zugeordnet hatte, gingen nach langem Orange auf Rot, in PiVCCU3 kamen die Zustandsänderungen nicht an. Andere Geräte wie HM-LC-Bl1PBU-FM oder HM-CC-RT-DN haben hingegen problemlos in beide Richtungen funktioniert.

Ist mir nach ich weiß nicht wie vielen Stunden rum probieren alles zu blöd geworden. Sobald sie da ist wird eine gebrauchte CCU2 zum Gateway umgepatched, davon habe ich schon eine laufen und weiß, dass es funktioniert.

Antworten

Zurück zu „Softwareentwicklung von externen Applikationen“