Erstmal vielen Dank vorweg für das außerordentliche Engagement und der gute Umgang untereinander in diesem Forum. Vorbildlich!
Seit gut zwei Tagen versuche ich mich durch die Installation von RaspiberryMatic im Docker Container auf einer (zum Testen bereits schon zwei) x86_64 Intel Architektur(en) zu kämpfen. Hintergrund ist der, dass bei mir die komplette Hausautomatisierung so läuft und ich keine (nur für Homematic) zuätzlich weitere Hardware laufen lassen möchte.
Mit Homematic starte ich gerade erst, habe also noch kein einziges Gerät vorher im Betrieb gehabt.
Ich bin nach dieser Anleitung vorgegangen: https://github.com/jens-maus/RaspberryM ... Docker-OCI
Mir ist schon klar, das ich mit einer abweichenden Architektur (x86_64) und dann noch mit Docker von dem "Regelbetrieb"/"Mainstream" abweiche (SD-Image auf einem RaspberryPi) aber ich würde gerne mein folgendes Problem verstehen, ohne direkt den Kopf in den Sand zu stecken
Ich teste momentan auf einer dedizierten Hardware, um meinen "HomeServer" nicht "kaputtzukonfigurieren".
- Die anfänglichen Schwierigkeiten mit der Erkennung der Hardware (Unter lsusb war der Stick sofort sichtbar) und Zuweisung eines device (/dev/ttyUSB0) habe ich lösen können, indem ich die Datei /etc/udev/rules.d/99-Homematic.rules wie folgt modifiziert habe (Punkt 4. der obigen Anleitung):
Danach wurde dem HmIP-RFUSB Stick (von ELV) beim Einstecken ein device link (/dev/ttyUSB0) zugeordnet. Ein Nebeneffekt ist derzeit noch, dass die Datei /sys/bus/usb-serial/drivers/cp210x/new_id bei jedem Einstecken 4 identische Einträge hinzugefügt werden, weil offensichtlich die udev rule 4x ausgeführt wird.Code: Alles auswählen
ACTION=="add", ATTRS{idVendor}=="1b1f", ATTRS{idProduct}=="c020", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 1b1f c020 > /sys/bus/usb-serial/drivers/cp210x/new_id'", ENV{ID_MM_DEVICE_IGNORE}="1"
Vermutlich muss ich noch weitere Regeln einfügen, damit dieses auf eine Ausführung limitiert wird.
- Das Starten des Docker Containers klappt (ich nutze docker compose), allerdings wird sowohl im Startup-Log, als auch hinter dem "Hilfe"-Button keine HmRF Hardware angezeigt:
Code: Alles auswählen
ccu | Identifying host system: PEGATRON CORPORATION BDW-P1 (oci), OK ccu | Initializing RTC Clock: onboard, OK ccu | Running sysctl: OK ccu | Checking for Factory Reset: not required ccu | Checking for Backup Restore: not required ccu | Running seedrng: OK ccu | Initializing System: OK ccu | Setup ca-certificates: OK ccu | Starting logging: OK ccu | Populating /dev using udev: done ccu | Init onboard LEDs: init, OK ccu | Starting iptables: OK ccu | Starting network: eth0: link up, fixed, firewall, inet up, 192.168.179.222, OK ==> ccu | Identifying Homematic RF-Hardware: ....HmRF: n/a, HmIP: HMIP-RFUSB/USB, OK ccu | Updating Homematic RF-Hardware: HMIP-RFUSB: 4.4.18, not necessary, OK ccu | Starting hs485dLoader: disabled ccu | Starting xinetd: OK ccu | Starting eq3configd: OK ccu | Starting lighttpd: creating new SSL cert... OK ccu | Starting ser2net: disabled ccu | Starting ssdpd: OK ccu | Starting NUT services: disabled ccu | Initializing Third-Party Addons: OK ccu | Starting LGWFirmwareUpdate: ...OK ccu | Setting LAN Gateway keys: OK ccu | Starting hs485d: disabled ccu | Starting multimacd: not required ==> ccu | Starting rfd: no BidCos-RF hardware found ccu | Starting HMIPServer: .........OK ccu | Starting ReGaHss: .OK ccu | Starting CloudMatic: OK ccu | Starting NeoServer: OK ccu | Starting Third-Party Addons: OK ccu | Starting crond: OK ccu | Setup onboard LEDs: booted, OK ccu | Finished Boot: 3.77.7.20240826 (raspmatic_oci_amd64)Code: Alles auswählen
# detect_radio_module /dev/ttyUSB0 # im Docker Container ausgeführt, liefert (gekürzt, wie im Screenshot aber identisch): HMIP-RFUSB 226... 301..... 0xF... 0xB... 4.4.18Da der HmIP-RFUSB Stick ja im Dualbetrieb arbeiten kann/sollte (siehe viewtopic.php?t=70936) hätte ich auch in dem HmRF Teil Einträge erwartet. Etwa analog zu dem Screenshot in der Github Discussion: https://github.com/jens-maus/RaspberryM ... sions/1931.Code: Alles auswählen
# cat /var/hm_mode # im Docker Container ausgeführt, liefert (gekürzt, wie im Screenshot aber identisch): HM_HMIP_ADDRESS='0xB...' HM_HMIP_ADDRESS_ACTIVE='0xB...' HM_HMIP_DEV='HMIP-RFUSB' HM_HMIP_DEVNODE='/dev/ttyUSB0' HM_HMIP_DEVTYPE='USB' HM_HMIP_SERIAL='226...' HM_HMIP_SGTIN='301...' HM_HMIP_VERSION='4.4.18' HM_HMRF_ADDRESS='' HM_HMRF_ADDRESS_ACTIVE='' HM_HMRF_DEV='' HM_HMRF_DEVNODE='' HM_HMRF_DEVTYPE='' HM_HMRF_SERIAL='' HM_HMRF_VERSION='' HM_HOST='oci' HM_LED_GREEN='' HM_LED_GREEN_MODE1='none' HM_LED_GREEN_MODE2='heartbeat' HM_LED_RED='' HM_LED_RED_MODE1='timer' HM_LED_RED_MODE2='none' HM_LED_YELLOW='' HM_LED_YELLOW_MODE1='none' HM_LED_YELLOW_MODE2='none' HM_MODE='NORMAL' HM_RTC='onboard'
Was läuft bei mir also schief? Ist der Stick kaputt? Das "Funkmodul" ist richtig herum draufgelötet (sollen ja auch Manche schon falsch gemacht haben...) aber auch ohne aufgelötetem Funkmodul hätten Einträge für HMRF dort stehen müssen. Das sieht man an den Screenshots der Tests durch den Beitrag von @Baxxy (viewtopic.php?t=79828).
- Liegt es vielleicht (ich vermute es derzeit) an der Installation des Kernel Moduls pivccu-modules-dkms (Anleitung Punkt 1.)? Beim ersten Installieren habe ich eine Fehlermeldung erhalten:
Das Kernel Module eq3_char_loop ließ sich zuerst auch nicht aktivieren. Der selbe Fehler wurde schonmal in diesem Thread gemeldet viewtopic.php?t=73186 und tatsächlich sorgten die Befehle für eine IMHO fehlerfreie Neuinstallation.Code: Alles auswählen
Paketlisten werden gelesen… Fertig Abhängigkeitsbaum wird aufgebaut… Fertig Statusinformationen werden eingelesen… Fertig Die folgenden NEUEN Pakete werden installiert: pivccu-modules-dkms 0 aktualisiert, 1 neu installiert, 0 zu entfernen und 4 nicht aktualisiert. Es müssen 43,1 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. Holen:1 https://www.pivccu.de/piVCCU stable/main amd64 pivccu-modules-dkms all 1.0.84 [43,1 kB] Es wurden 43,1 kB in 0 s geholt (214 kB/s). Vorkonfiguration der Pakete ... Vormals nicht ausgewähltes Paket pivccu-modules-dkms wird gewählt. (Lese Datenbank ... 429796 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../pivccu-modules-dkms_1.0.84_all.deb ... Entpacken von pivccu-modules-dkms (1.0.84) ... pivccu-modules-dkms (1.0.84) wird eingerichtet ... ### Create kernel modules ... FAILED Check kernel headers ... Done Prepare kernel headers ... Done Install DKMS package ... Done ### Try to load fresh build modules ... FAILED ### modprobe: ERROR: could not insert 'generic_raw_uart': Exec format error Enable DKMS service ... Done
Code: Alles auswählen
# sudo apt reinstall linux-headers-$(uname -r) Die folgenden Pakete werden ERNEUT INSTALLIERT: linux-headers-5.15.0-122-generic 0 Pakete aktualisiert, 0 zusätzlich installiert, 1 erneut installiert, 0 werden entfernt und 4 nicht aktualisiert. 2.827 kB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 0 B zusätzlich belegt sein. Holen: 1 https://mirror.netcologne.de/ubuntu jammy-updates/main amd64 linux-headers-5.15.0-122-generic amd64 5.15.0-122.132 [2.827 kB] 2.827 kB wurden in 0 s heruntergeladen (7.015 kB/s) (Lese Datenbank ... 429824 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../linux-headers-5.15.0-122-generic_5.15.0-122.132_amd64.deb ... Entpacken von linux-headers-5.15.0-122-generic (5.15.0-122.132) über (5.15.0-122.132) ... linux-headers-5.15.0-122-generic (5.15.0-122.132) wird eingerichtet ... /etc/kernel/header_postinst.d/dkms: * dkms: running auto installation service for kernel 5.15.0-122-generic ...done.Danach ließ sich das Kernel Module eq3_char_loop mittels modprobe aktivieren, jedoch steht in der "used by" Spalte eine 0.Code: Alles auswählen
# sudo apt reinstall pivccu-modules-dkms Die folgenden Pakete werden ERNEUT INSTALLIERT: pivccu-modules-dkms 0 Pakete aktualisiert, 0 zusätzlich installiert, 1 erneut installiert, 0 werden entfernt und 4 nicht aktualisiert. 43,1 kB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 0 B zusätzlich belegt sein. Holen: 1 https://www.pivccu.de/piVCCU stable/main amd64 pivccu-modules-dkms all 1.0.84 [43,1 kB] 43,1 kB wurden in 0 s heruntergeladen (211 kB/s) Vorkonfiguration der Pakete ... (Lese Datenbank ... 429824 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Entpacken von .../pivccu-modules-dkms_1.0.84_all.deb ... Disabled DKMS service ... Done Remove obsolete kernel modules ... Done Entpacken von pivccu-modules-dkms (1.0.84) über (1.0.84) ... pivccu-modules-dkms (1.0.84) wird eingerichtet ... Create kernel modules ... Done Enable DKMS service ... Done
Interessant finde ich die Ausgabe des Status des dkms services. Dieser wird sofort nach dem Start (innerhalb von 8ms) wieder beendet (jedesmal mit neuer PID). Unter Active steht daher "inactive (dead)" aber unter Process findet man auch "(code=exited, status=0/SUCCESS)". Ich finde das merkwürdig und könnte mir das als den eigentlichen Grund vorstellen. Muss der Service nicht dauerhaft laufen (active)?Code: Alles auswählen
# lsmod | grep -E "eq3|cp210x" cp210x 40960 1 usbserial 57344 3 cp210x eq3_char_loop 20480 0
Code: Alles auswählen
# systemctl status pivccu-dkms.service ○ pivccu-dkms.service - piVCCU DKMS Modules Loaded: loaded (/lib/systemd/system/pivccu-dkms.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2024-10-01 01:36:44 CEST; 13h ago Process: 35573 ExecStart=/var/lib/piVCCU/dkms/ensure_modules.sh (code=exited, status=0/SUCCESS) Main PID: 35573 (code=exited, status=0/SUCCESS) CPU: 8ms Okt 01 01:36:44 terra-mint systemd[1]: Starting piVCCU DKMS Modules... Okt 01 01:36:44 terra-mint systemd[1]: pivccu-dkms.service: Deactivated successfully. Okt 01 01:36:44 terra-mint systemd[1]: Finished piVCCU DKMS Modules.
- In einigen Forenbeiträgen lese ich öfters: Führ mal "pivccu-info" aus aber ich finde dieses Tool weder im Docker Container, noch irgendwo auf dem Docker Host. Vermutlich gibt es das nicht für x86_64, sondern nur für arm bzw. Raspberry-Installationen...
- Ich hab mir aus dem Docker Container die Datei hmip-copro-update.jar auf den Docker Host kopiert und nach Stoppen des Containers dort ausgeführt. Am Docker Host ist ja schliesslich der USB Stick konfiguriert. Aus der beiliegenden Bauanleitung war dieser Aufruf aufgeführt:
Der Aufruf mit -t (Print coprocessor test status) läuft auch:Code: Alles auswählen
# java -jar hmip-copro-update.jar -p /dev/ttyUSB0 -v [INFO] Homematic IP coprocessor update tool V1.0.10 RXTX Warning: Removing stale lock file. /var/lock/LCK..ttyUSB0 [INFO] SGTIN = 301... [INFO] Checking coprocessor firmware version ... [DEBUG] Start bootloader ... [DEBUG] Already in Bootloader. [DEBUG] Request bootloader version ... [INFO] Bootloader version = 1.0.25 [DEBUG] Start application ... [DEBUG] Application 'DualCoPro_App' running [DEBUG] Request application version ... [DEBUG] Request application version ... [INFO] Application version = 4.4.18
Code: Alles auswählen
# java -jar hmip-copro-update.jar -p /dev/ttyUSB0 -t [INFO] Homematic IP coprocessor update tool V1.0.10 [DEBUG] Start bootloader ... [DEBUG] Bootloader running [DEBUG] Request bootloader version ... [INFO] SGTIN = 301... [INFO] Requesting test status ... [DEBUG] Start application ... [DEBUG] Application 'DualCoPro_App' running [INFO] Teststatus: 0
- Irgendwelche Ideen, woran es liegt, dass der HmRF Teil nicht aufgelistet bzw. gefunden wird? Ob der HmIP Teil des Sticks funktioniert weiß ich noch nicht, da ich noch kein Gerät angelernt habe bzw. wegen dem "Problem" noch nicht anlernen wollte.
- Gibt es irgendwelche Tools oder Shell Scripte, die man auf dem x86_64 Docker Host oder im Docker Container ausführen kann, um die unterschiedlichen Module (HmIP und HmRF) zu Testen? Vielleicht mit einer Terminalemulation (wie bei einem Modem) und dann per AT Befehle oder ähnlichem?
- Was wäre das Resultat, wenn ich das JAR mit der Option -r ausführe (-r : Perform coprocessor factory reset). Bricke ich dadurch ggf. meinen Stick bzw. lösche sogar vorhandene Keys und SGTIN? Ich will den Stick ja nicht bricken.
Thilo
