RaspberryMatic in Docker auf RP4, erkennt HM-MOD-RPI-PCB nicht

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Antworten
aphexer
Beiträge: 1
Registriert: 27.03.2024, 00:48
System: Alternative CCU (auf Basis OCCU)

RaspberryMatic in Docker auf RP4, erkennt HM-MOD-RPI-PCB nicht

Beitrag von aphexer » 27.03.2024, 01:26

Hallo liebe Foren-Gemeinde,

Wie in der Überschrift beschrieben, habe ich RaspberryMatic in Docker auf einem RaspberryPi 4 (OS:Debian, Kernel: Linux 6.6.20+rpt-rpi-v8) eingerichtet und die Anleitung nach bestem Wissen und Gewissen befolgt. Ein selbstgelötetes HM-MOD-RPI-PCB steckt auf den entsprechenden GPIO Pins des RP4.

Habe den Docker container sowohl durch das install_script.sh, als auch mit Hilfe der docker-compose.yml gestartet.

Das ist der Output von sudo ./install-docker.sh:

Code: Alles auswählen

Removing old container (not user data)
Pull/Update OCI image ghcr.io/jens-maus/raspberrymatic:latest
latest: Pulling from jens-maus/raspberrymatic
Digest: sha256:983b549cd66aefb4427aa542ca35d5c522f4fa60f176b14ccc6450dd1e32beca
Status: Image is up to date for ghcr.io/jens-maus/raspberrymatic:latest
ghcr.io/jens-maus/raspberrymatic:latest
Removing old macvlan docker network:
ccu
Creating macvlan docker network:
7505f3266611886de291034e092d0fcfee2771565be91d7a349a8b42a0ceaf47
Setup local network bridge persistence...
Setup local ccu-shim network bridge...
Creating container:
docker create --privileged --read-only --volume ccu_data:/usr/local:rw --volume /lib/modules:/lib/modules:ro --volume /run/udev/control:/run/udev/control --hostname ccu --name ccu --stop-timeout 30 --restart always --network ccu --ip 192.168.178.210  ghcr.io/jens-maus/raspberrymatic:latest

Docker container successfully created.
- Start container with "docker start ccu"
- See logs with "docker logs ccu"
- Connect to http://192.168.178.210/
- Stop container with "docker stop --time 120 ccu"
- Uninstall container environment with "./install-docker.sh uninstall"

Danach ist der output von 'docker logs ccu' folgender:

Code: Alles auswählen

Starting watchdog...
Identifying host system: Raspberry Pi 4 Model B Rev 1.4 (oci), OK
Initializing RTC Clock: no hardware found
Running sysctl: OK
Checking for Factory Reset: not required
Checking for Backup Restore: not required
Running seedrng: OK
Initializing System: OK
Setup ca-certificates: OK
Starting logging: OK
Populating /dev using udev: done
Init onboard LEDs: init, OK
Starting iptables: OK
Starting network: eth0: link up, fixed, firewall, inet up, 192.168.178.210, OK
Identifying Homematic RF-Hardware: HmRF: n/a, HmIP: n/a, OK
Updating Homematic RF-Hardware: no GPIO/USB connected RF-hardware found
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: no BidCos-RF hardware found
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.75.6.20240316 (raspmatic_oci_arm64)

Das ist der relevante Teil meiner /boot/firmware/config.txt:

Code: Alles auswählen

enable_uart=1
dtparam=i2c_arm=on
dtoverlay=miniuart-bt
dtoverlay=rpi-rf-mod

# dtoverlay=uart1
dtoverlay=disable-bt
dtoverlay=miniuart-bt
core_freq=250

Die /boot/firmware/cmdline.txt:

Code: Alles auswählen

console=tty1 root=PARTUUID=376f9add-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=DE

Was mir aufgefallen ist, ist der output von systemctl status pivccu-dkms:

Code: Alles auswählen

root@fritzhq:~# systemctl status pivccu-dkms
○ pivccu-dkms.service - piVCCU DKMS Modules
     Loaded: loaded (/lib/systemd/system/pivccu-dkms.service; enabled; preset: enabled)
     Active: inactive (dead) since Wed 2024-03-27 00:40:38 CET; 23min ago
    Process: 6876 ExecStart=/var/lib/piVCCU/dkms/ensure_modules.sh (code=exited, status=0/SUCCESS)
   Main PID: 6876 (code=exited, status=0/SUCCESS)
        CPU: 17ms

Mar 27 00:40:38 fritzhq systemd[1]: Starting pivccu-dkms.service - piVCCU DKMS Modules...
Mar 27 00:40:38 fritzhq systemd[1]: pivccu-dkms.service: Deactivated successfully.
Mar 27 00:40:38 fritzhq systemd[1]: Finished pivccu-dkms.service - piVCCU DKMS Modules.
root@fritzhq:~# systemctl start pivccu-dkms
root@fritzhq:~# systemctl status pivccu-dkms
○ pivccu-dkms.service - piVCCU DKMS Modules
     Loaded: loaded (/lib/systemd/system/pivccu-dkms.service; enabled; preset: enabled)
     Active: inactive (dead) since Wed 2024-03-27 01:04:36 CET; 1s ago
    Process: 10322 ExecStart=/var/lib/piVCCU/dkms/ensure_modules.sh (code=exited, status=0/SUCCESS)
   Main PID: 10322 (code=exited, status=0/SUCCESS)
        CPU: 18ms

Mar 27 01:04:36 fritzhq systemd[1]: Starting pivccu-dkms.service - piVCCU DKMS Modules...
Mar 27 01:04:36 fritzhq systemd[1]: pivccu-dkms.service: Deactivated successfully.
Mar 27 01:04:36 fritzhq systemd[1]: Finished pivccu-dkms.service - piVCCU DKMS Modules.
Daran ändert leider auch 'sudo service pivccu-dkms start' nichts, der service bleibt inactive.
Weiterhin ist 'dmesg | grep pivccu' ohne Ausgabe. Da kann doch etwas nicht stimmen, oder?

Das ist der output von 'journalctl -u pivccu':

Code: Alles auswählen

Mar 26 23:02:24 fritzhq systemd[1]: Starting pivccu.service - piVCCU...
Mar 26 23:02:24 fritzhq piVCCU3[6508]: HMRF hardware was not detected
Mar 26 23:02:24 fritzhq start_container.sh[6508]: <12>Mar 26 23:02:24 piVCCU3: HMRF hardware was not d>Mar 26 23:02:24 fritzhq piVCCU3[6510]: HMIP hardware was not detected
Mar 26 23:02:24 fritzhq start_container.sh[6510]: <12>Mar 26 23:02:24 piVCCU3: HMIP hardware was not d>Mar 26 23:02:25 fritzhq start_container.sh[6816]: kernel.sched_rt_runtime_us = -1
Mar 26 23:02:25 fritzhq systemd[1]: Started pivccu.service - piVCCU.
Mar 27 00:13:31 fritzhq systemd[1]: Stopping pivccu.service - piVCCU...
Mar 27 00:13:41 fritzhq stop_container.sh[39412]: rmmod: ERROR: Module fake_hmrf is not currently load>Mar 27 00:13:41 fritzhq stop_container.sh[39413]: rmmod: ERROR: Module dummy_rx8130 is not currently l>Mar 27 00:13:41 fritzhq stop_container.sh[39414]: rmmod: ERROR: Module rpi_rf_mod_led is not currently>Mar 27 00:13:41 fritzhq stop_container.sh[39415]: rmmod: ERROR: Module hb_rf_eth is not currently load>Mar 27 00:13:41 fritzhq systemd[1]: pivccu.service: Deactivated successfully.
Mar 27 00:13:41 fritzhq systemd[1]: Stopped pivccu.service - piVCCU.
-- Boot 68e88006c7584fed8d9a25cc0bf4994b --
Mar 27 00:13:55 fritzhq systemd[1]: Starting pivccu.service - piVCCU...
Mar 27 00:13:55 fritzhq piVCCU3[1399]: HMIP hardware was not detected
Mar 27 00:13:55 fritzhq start_container.sh[1399]: <12>Mar 27 00:13:55 piVCCU3: HMIP hardware was not d>Mar 27 00:13:57 fritzhq start_container.sh[1765]: kernel.sched_rt_runtime_us = -1
Mar 27 00:13:57 fritzhq systemd[1]: Started pivccu.service - piVCCU.
Mar 27 00:28:18 fritzhq systemd[1]: Stopping pivccu.service - piVCCU...
Mar 27 00:28:28 fritzhq stop_container.sh[9507]: rmmod: ERROR: Module fake_hmrf is not currently loadedMar 27 00:28:28 fritzhq stop_container.sh[9508]: rmmod: ERROR: Module dummy_rx8130 is not currently lo>Mar 27 00:28:28 fritzhq stop_container.sh[9509]: rmmod: ERROR: Module rpi_rf_mod_led is not currently >Mar 27 00:28:28 fritzhq stop_container.sh[9510]: rmmod: ERROR: Module hb_rf_eth is not currently loadedMar 27 00:28:28 fritzhq systemd[1]: pivccu.service: Deactivated successfully.
Mar 27 00:28:28 fritzhq systemd[1]: Stopped pivccu.service - piVCCU.
Mar 27 00:28:28 fritzhq systemd[1]: pivccu.service: Consumed 1.016s CPU time.
-- Boot eb33239aef8e4f0a9889b4ef2a4ab4b6 --
Mar 27 00:28:41 fritzhq systemd[1]: Starting pivccu.service - piVCCU...
Mar 27 00:28:42 fritzhq piVCCU3[1395]: HMRF hardware was not detected
Mar 27 00:28:42 fritzhq start_container.sh[1395]: <12>Mar 27 00:28:42 piVCCU3: HMRF hardware was not d>Mar 27 00:28:42 fritzhq piVCCU3[1396]: HMIP hardware was not detected
Mar 27 00:28:42 fritzhq start_container.sh[1396]: <12>Mar 27 00:28:42 piVCCU3: HMIP hardware was not d>Mar 27 00:28:42 fritzhq piVCCU3[1406]: No network bridge could be detected.
Mar 27 00:28:42 fritzhq start_container.sh[1406]: <12>Mar 27 00:28:42 piVCCU3: No network bridge could>Mar 27 00:28:44 fritzhq start_container.sh[1771]: kernel.sched_rt_runtime_us = -1
Mar 27 00:28:45 fritzhq systemd[1]: Started pivccu.service - piVCCU.


Nunja, ich bin jedenfalls gerade am Ende mit meinem Latein, woran es liegen könnte, dass er mein HM-MOD-RPI-PCB nicht erkennt. Das beste, was mir noch einfällt, ist, dass ich das Ding beim Zusammenlöten irgendwie runiert habe.

Es wäre sehr cool, wenn jemand, der ein ähnliches setup laufen hat, einmal testen könnte, wie deren output von 'systemctl status pivccu-dkms' bzw. 'dmseg |grep pivccu' ist.

Hat jemand von euch sonst noch eine Idee?

VG

Rainer

Auweia
Beiträge: 91
Registriert: 04.08.2012, 16:57
Wohnort: Regensburg
Hat sich bedankt: 3 Mal
Danksagung erhalten: 2 Mal

Re: RaspberryMatic in Docker auf RP4, erkennt HM-MOD-RPI-PCB nicht

Beitrag von Auweia » 29.03.2024, 19:20

hi,
ich habe eine Test-docker Umgebung - allerdings mit einem HM-RPI-RF-MOD auf einem Rpi4b8g:
Kernel ist allerdings V7: 6.1.21-v71+
Installiert habe ich alles mit dem script von Jens

Schon mal einen Neustart gemacht und das script neu gestartet?


Ich starte den Kernel mit V7 durch den Eintrag in der /boot/config.txt :
[pi4]
# Run as fast as firmware / board allows
arm_boost=1

[all]
arm_64bit=0
dtoverlay=pi3-disable-bt
EOT
dtoverlay=pivccu-raspberrypi

Ob die pivccu Module mit V8 schon funktionieren habe ich nicht getestet.

Albert
RaspberryMatic , Rpi4B, SSD, RPI-RF-MOD, 1x LAN-, 1x LAN RF Gateway, 90 HM-Geräte, HPCL (Prod)
Proxmox V8 auf Rpi5 mit 4GB, SSD, mit VM RaspberryMatic (Test)
RPI4B, 4GB, SSD, Influx-DB, Grafana, OWFS, 1-W, KNX, NodeRed, CometVisu (Prod)

Antworten

Zurück zu „RaspberryMatic“