Unterstützung der LED für GPIO verbundenes RPI-RF-MOD unter Docker/OCI

[SuperJojo2001]

Describe the issue you are experiencing

Installierte Version: Raspberry Bullseye kernel version 5.15.32-v7+ als 32-Bit version OCI installation erfolgte gemäß https://github.com/jens-maus/RaspberryMatic/wiki/Installation-Docker-OCI über deploy.sh Skript. Bei Verwendung des RPI-RF-MOD sind noch die unter Punkt 5 gelisteten Arbeitsschritte durchgeführt worden

Describe the behavior you expected

Meine orginale SD-Karte mit der Homematic-IP Original Software in den gleichen Raspberry Pi hineingesteckt und gebootet bedient die Homematic-IP LED korrekt. Die LED an sich ist also nicht defekt. Normales Verhalten der LED wäre, das sie ein Lebenszeichen von sich gibt nachdem der Docker Container gestartet ist.

Steps to reproduce the issue

1. Installation aktuelles Raspberry Pi OS über Rpi-Imager (32Bit Desktop)
2. apt update & apt upgrade
3. Docker Installation
4. ./deploy.sh Skript-Durchführung
5. Anpassung/installation Verwendung RPI-RF-MOD gemäß Wiki
6. sudo reboot now zum Neustarten ...

What is the version this bug report is based on?

3.65.6.20220723

Which base platform are you running?

rpi3 (RaspberryPi3)

Which HomeMatic/homematicIP radio module are you using?

RPI-RF-MOD

Anything in the logs that might be useful for us?

Starting watchdog...
Identifying host system: oci, OK
Initializing RTC Clock: onboard, OK
Running sysctl: OK
Checking for Factory Reset: not required
Checking for Backup Restore: not required
Initializing System: OK
Starting logging: OK
Populating /dev using udev: done
Init onboard LEDs: init, OK
Starting irqbalance: OK
Starting iptables: OK
Starting network: eth0: link up, fixed, firewall, inet up, 172.17.0.2, OK
Identifying Homematic RF-Hardware: ....HmRF: RPI-RF-MOD/[email protected], HmIP: RPI-RF-MOD/[email protected], OK
Updating Homematic RF-Hardware: RPI-RF-MOD: 4.4.22, not necessary, OK
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: .OK
Starting rfd: ..OK
Starting HMIPServer: ...................OK
Starting ReGaHss: .OK
Starting CloudMatic: OK
Starting NeoServer: disabled
Starting Third-Party Addons: OK
Starting crond: OK
Setup onboard LEDs: booted, OK
Finished Boot: 3.65.6.20220723 (raspmatic_oci_arm)

Additional information

Ist denn die Homematic IP LED des RPI-RF-MOD Moduls gemäß dem Schaltplan direkt an einen GPIO des Raspberry Pi Moduls angeschlossen. Welcher denn? Ich konnte ja mal eine console im container starten und versuchen auf den GPIO zu schreiben, um zu sehen ob eine Reaktion an der LED herbeizuführen ist. Oder anders gefragt wie könnte ich einen Test durchführen?

[jens-maus]

Nun, das "Problem" bzw. die Limitation hier ist, das du RaspberryMatic eben selbst via Docker auf einem generischen Betriebsystem betreibst und damit quasi in einem vom restlichen Betriebssystem abgeschotteten Modus. Und dieser Umstand gilt prinzipiell nicht nur für die Zugriffe auf das serielle Interface über das die eigentliche Kommunikation mit dem Funkmodul stattfindet, sondern eben auch für die Steuerung bzw. das Ansprechen der LEDs die ja via GPIO separat angesteuert werden. Und damit RaspberryMatic innerhalb des docker containers auf die LEDs zugreifen kann muss ihm quasi erlaubt werden die entsprechenden /sys/class/leds/rpi_rf_mod:XXXX device nodes zuzugreifen.

Und bisher hat ehrlich gesagt einfach noch niemand danach gerufen das er gerne die LED-Funktion des RPI-RF-MOD auch innerhalb eines solchen Docker-OCI betriebenen RaspberryMatic nutzen möchte, sondern man war/ist bereits froh das man überhaupt RaspberryMatic bzw. ein RPI-RF-MOD so nutzen kann. Und im Falle vom HomeAssistant Add-on - wo ja auch alles docker-basiert funktioniert - funktioniert dies jedoch weil entsprechende docker freigaben auf diese /sys/class/leds/XXXX nodes dort existieren.

Wenn man also dies umsetzen möchte, so müsste man dies einmal entsprechend genauer anschauen und im deploy.sh bzw. in der Dokumentation anpassen um zu beschreiben wie man es erreicht das ein RaspberryMatic docker container auf die LED nodes des Host Systems zugreifen kann. Ingesamt ist dies hier also vielmehr ein enhancement request als ein bug report.

[SuperJojo2001]

Hallo Jens, danke für die Rückmeldung.

Ich habe soeben einen Tipp von @alexreinert bekommen und nun funktioniert die LED.

Zunächst analysierte ich in seinem piVCC Projekt den Quellcode rpi_rf_mod_led.c und erkannte das eigentlich alle Voraussetzungen gegeben waren, dass genau so wie Du es beschreibst die LEDs unter /sys/class/leds/xxxx mit dem Laden seiner Kernel-Module und dem Overlay hätten erscheinen müssen. Dann öffnete ich ein Issue unter piVCC und als Tipp referenzierte er auf sein startskript unter piVCCU/pivccu/host3/start_container.sh Dort sieht man, dass das Skript zusätzlich noch das LED-Kernelmodul 'rpi_rf_mod_led' ins System einbindet unter Angabe der richtigen GPIO-Nummern die in den Zeilen 28-41 zuvor ermittelt wurden. (die Pin Nummern-Dateien auf meinem Raspberry Pi liegen unter /sys/class/raw-uart/raw-uart/). Da der Container ja im privileged Modus arbeitet, hat er kein Problem danach auf die neu angelegten LEDs unter /sys/class/leds/ zuzugreifen. Und ja ich gebe Dir recht, wenn man das ./deploy.sh script um diese Abschnitt noch erweitert, dann klappt es auch mit der LED in Zukunft

Hier der Grund warum ich die LED überhaupt benutze: Die Homematic IP sitzt zentral bei uns im Hausflur. Mit ihr ermittle ich den Ladezustand unseres Akkus unsere Photovoltaikanlage. Ich zeige 6 Zustände an von grün bis rot. Grün ist Akku voll, rot ist Akku ller Anhand dieses Zustandes erkennen wir alle (gerade gegen abends im Winter), inwiefern noch die Spülmaschine oder Waschmaschine noch angemacht werden kann. Wenn nicht dann halt morgens früh wenn wieder Sonne da ist.

Gruß Armin

[jens-maus]

Und ja ich gebe Dir recht, wenn man das ./deploy.sh script um diese Abschnitt noch erweitert, dann klappt es auch mit der LED in Zukunft

Na wenn du das schon umgesetzt hast könntest du dazu natürlich einen PullRequest gleich einsenden oder zumindest die Änderungen hier zeigen damit das dann ggf so umgesetzt werden kann.

[jens-maus]

Nun hab ich mir das ganze nochmal etwas genauer angeschaut und denke, das man wohl statt in der deploy.sh besser in der eigentlichen S47InitRFHardware innerhalb des docker containers das unterbringen sollte. Schon jetzt ist es ja bereits so, das für den Fall des Einsatzes eines HB-RF-USB/ETH devices er dynamisch dort (siehe https://github.com/jens-maus/RaspberryMatic/blob/master/buildroot-external/overlay/base/etc/init.d/S47InitRFHardware#L308) das rpi_rf_mod_led kernel modul beim hochfahren des containers nachlädt. D.h. es sollte prinzipiell möglich sein dieses Kernel modul an dieser (oder einen ähnlichen Stelle) bei einem Einsatzfall wie deinem (Docker Container auf einem Standard OS mit GPIO verbundenem RPI-RF-MOD) dynamisch zu laden.

Insofern wäre das also in der Tat mal eine kleine Fleissaufgabe für eine zukünftige Version.

[SuperJojo2001]

Sehr gut Jens das Du anführst, dass das mit dem ./deploy.sh script eine unglückliche Lösung ist. Das man allerdings Kernel-Module auch in einem Container nachladen kann, wusste ich bis jetzt nicht. Das liegt sicherlich an dem priviledge mode. Ich habe jetzt tatsächlich mal probiert den fehlenden modprobe Befehl in meinem OCI ontainer aufzurufen und das hat er akzeptiert. Wenn der Container erkennen könnte, welche Hardware vorläge, dann könnte man so den Nachladeprozeß tatsächlich automatisieren. Und ja "Fleissaufgabe" mag ich als Terminus. Bin leider kein eingefleischter Entwicker wie man vielleicht vermuten könnte, viel Hilfe ist durch mich nicht zu erwarten Aber der Docker-Einsatz ist sehr lukrativ. Warum überhaupt bei mir? Nun, ich habe eine 32GB Industrial SANDISK SD-Karte im Einsatz vom Typ SLC, sprich die ist faktisch nicht kaputt zu schreiben. Ich möchte mit einem InfluxDB-Container und Grafana-Container eine freie Datenbank und Visualisierung für Langezeitaufzeichnungen aufs System bekommen. Dazu eben RaspberryMatic und offizielles Node-RED für andere Tatigkeiten. Alles in Containern eben.

P.S.: Eine Feststellung habe ich allerdings nach weiteren "LED"-Untersuchungen gemacht: Ein Prozeß im OCI Container beeinflusst die LED(s) wiederkehrend. Ein simples echo 1 >/sys/class/leds/rpi_rf_mod:red/brightness bring die LED rot zum leuchten, aber kurz Zeit später geht sie wieder aus. In der UI habe ich bewusst alle Häkchen in den Einstellungen zur "Info-LED" aus gemacht. Hier habe natürlich keine Ahnung woher dieses Verhalten kommt.

Gruß Armin