search

alexreinert / piVCCU

piVCCU is a project to install the original Homematic CCU3 firmware inside a virtualized container (lxc) on ARM based single board computers.
Apache License 2.0
306 stars 65 forks source link

piVCCU3 auf Ubuntu 20.04 #333

Closed kd7038 closed 3 years ago

kd7038 commented 3 years ago

Hallo Alex,

ich versuche piVCCU3 auf einem Raspberry Pi 4 8GB zum Laufen zubekommen. Ich bin nach der OtherOS Doku vorgegangen und bekomme bei der Installation der piVCCU3 folgende Ausgabe:

ubuntu@ubuntu:~$ sudo apt install pivccu3 Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: pivccu3 0 upgraded, 1 newly installed, 0 to remove and 77 not upgraded. Need to get 0 B/119 MB of archives. After this operation, 0 B of additional disk space will be used. Preconfiguring packages ... Selecting previously unselected package pivccu3. (Reading database ... 105421 files and directories currently installed.) Preparing to unpack .../pivccu3_3.53.34-50_arm64.deb ... Unpacking pivccu3 (3.53.34-50) ... Setting up pivccu3 (3.53.34-50) ... /var/lib/piVCCU3/detect_hardware.inc: line 215: route: command not found cat: /sys/class/net//address: No such file or directory dpkg: error processing package pivccu3 (--configure): installed pivccu3 package post-installation script subprocess returned error ex it status 1 Errors were encountered while processing: pivccu3 E: Sub-process /usr/bin/dpkg returned an error code (1)

Woran könnte das liegen.

Danke und Gruß Kai

kd7038 commented 3 years ago

ubuntu@ubuntu:~$ sudo pivccu-info piVCCU version: 3.53.34-50 Kernel modules: Available Raw UART dev: Not available Rasp.Pi UART: Not assigned to GPIO pins HMRF Hardware: unknown Board serial: unknown Radio MAC: unknown HMIP Hardware: unknown SGTIN: unknown Radio MAC: unknown lxc doesn't exist

alexreinert commented 3 years ago

Ich dachte bisher, dass route im Standardumfang von alle Debian basierten System drin ist, das muss vor der Installation vorhanden sein. Ich werde das zukünftig in die Abhängigkeiten ausnehmen.

Möchtest du mit dem zweiten Kommentar sagen, dass ein auf den GPIO aufgestecktes Funkmodul nicht läuft? Wenn ja, dann liegt das schlich daran, dass Ubuntu hierfür noch nicht unterstützt wird, sie auch Readme:

Prequisites for HM-MOD-RPI-PCB and RPI-RF-MOD on GPIO header [...] Raspberry Pi 2B/3B/3B+/4B running Raspbian Stretch or Buster

Eine Unterstützung ist in Arbeit, aber ich kann hier noch kein finales Datum nennen.

StefanRied commented 3 years ago

ich möchte auch ein piVCCU auf einem Raspberry 4 mit 8GB mit Ubuntu 20.10 Server zum laufen bringen. Habe die Testing Version probiert, aber leider ohne Erfolg an dem HM-MOD-RPI-PCB. Scheinbar gehen die GPIOs nicht.

piVCCU version: 3.55.5-53 Kernel modules: Available Raw UART dev: Not available Rasp.Pi UART: Not assigned to GPIO pins HMRF Hardware: unknown Board serial: unknown Radio MAC: unknown HMIP Hardware: unknown SGTIN: unknown Radio MAC: unknown State: STOPPED

Alles entsprechend. https://alexreinert.github.io/piVCCU/docs/setup/otheros.html

@alexreinert Es wäre auch mal eine Idee das ganze geniale piVCCU nicht als lxc image und als Systemservice laufen zu lassen, wie es jetzt ist, sondern komplett als neues LXD image bzw. vom LXD Daemon zu managen. Dann könnte man ein leeres ubuntu 20.xx auf dem Raspberry laden und alles einfach mit "lxc launch image:..." installieren. Hier ist ja lxd schon drauf. Mein Ziel ist es eigentlich auf dem "container host" nur images laufen zu lassen die mit LXD gemanaged sind. lxc list könnte dann CCU iobroker und sonst noch andere container nebeneinander anzeigen.

PS: Auf Ubuntu 20.x ist das network ja auch unter netplan. Den /etc/network/interfaces file gibt es nicht mehr. Die Anleitung unter https://alexreinert.github.io/piVCCU/docs/setup/otheros.html geht dann nicht mehr. Mit LXD könnte man ein "lxc edit profile CCU-image" machen. ...

alexreinert commented 3 years ago

Wie im Kommentar obendrüber erwähnt, die GPIO werden aktuell nur mit Raspbian unterstützt. Eine Nutzung von LXD wird momentan nicht funktionieren: Beim Startup laufen einige Dinge im Host und diese müssen auch im Host laufen, weil ein Container nicht genug Rechte dafür hätte und da LXD aktuell keine Start Hooks unterstützt, geht das halt nicht. (u.A. Kernel Module laden und Parameter von Kernel Modulen setzen).

StefanRied commented 3 years ago

Danke für die Antwort. Würde dann der ELV Homematic IP ARR-Bausatz RF-USB-Stick auf dem Ubuntu 20.10 laufen?

alexreinert commented 3 years ago

Ja, aber ich kann von dem Teil nur abraten (kein HM classic, undokumentierteBegrenzung bei der Anzahl an Geräten, ...), wenn dann die HB-RF-USB-2 und das richtige Funkmodul per USB anschließen.

An sich sollte das deb Paket pivccu-modules-raspberrypi bereits unter Ubuntu laufen und auch den Support für den GPIO Header mitbringen. Mir fehlt sber noch die komplette Doku für die Einrichtung der Bridge und aktuell habe ich das nur überschaubar getestet.

Zusätzlich aber gleich die Warnung: Der Pi 4 erzeugt massiv Störstrahlung, welche insb. HmIP stört. Hier hilft nur mind. 0,5m zwischen Pi und Funkmodul (z.B. eben mittels der HB-RF-USB-2).

StefanRied commented 3 years ago

Hat schon jemand Erfahrung mit dem Raspberry PI OS 64 bit? https://www.raspberrypi.org/forums/viewtopic.php?t=275370 Da könnten die GPIOs ja gehen? Und gleichzeitig hatte man einen lxd 64 bit host für andere images.

StefanRied commented 3 years ago

@alexreinert Danke für den Hinweis auf dein HB-RF-USB-2 board. Habe mir gleich eins bestellt.

StefanRied commented 3 years ago

Hallo,

das issue ist leider noch nicht geschlossen.

ich habe grade mal das aktuelle Ubuntu 20.04 mit dem Build von gestern (4-02-21) genommen um komme immer noch auf diesen Fehler wie auch @kd7038

`dpkg: error processing package pivccu3 (--configure): installed pivccu3 package post-installation script subprocess returned error ex it status 1 Errors were encountered while processing: pivccu3 E: Sub-process /usr/bin/dpkg returned an error code (1)

` Den gleichen Fehler bekomme ich auch mit dem Ubuntu 20.10 server image.

Ich habe jetzt leider keine Ubuntu 20.xx version mit pivccu3 und dem HB-RF-USB-2 zum laufen bekommen.

Hat das noch jemand probiert?

Lieben Dank für Hilfe oder Ideen.

StefanRied commented 3 years ago

Ein Schritt weiter.

/var/lib/piVCCU3/detect_hardware.inc: line 215: route: command not found Dieses script ist ausgestiegen, weil in dem Ubuntu Server 20.x Image die Nettools nicht installiert sind.

Also vorher

apt install net-tools

Dann rennt der apt install pivccu3 korrekt durch...

root@ubuntu:~# pivccu-info piVCCU version: 3.55.10-54 Kernel modules: Available Raw UART dev: Available Rasp.Pi UART: Not assigned to GPIO pins HMRF Hardware: HM-MOD-RPI-PCB Connected via: HB-RF-USB-2@usb-0000:01:00.0-1.3 (/dev/raw-uart) Board serial: OEQ0304675 Radio MAC: 0x583B3A HMIP Hardware: HM-MOD-RPI-PCB SGTIN: 3014F711A061A7D7098E0E23 Radio MAC: 0xB3E037 State: RUNNING PID: 149316 CPU use: 0.69 seconds BlkIO use: 20.00 KiB Link: vethpivccu TX bytes: 31.26 KiB RX bytes: 936 bytes Total bytes: 32.17 KiB

Die HM-MOD-RPI-PCB ist auch korrekt erkannt.

Jetzt ist noch das Problem dass der LXC Container keine IP Nummer gezogen hat.

StefanRied commented 3 years ago

Nach etwas rumprobieren ist das Problem gelöst und ich schreibe gerne die Lösung auf: In meinem Beispiel hat der Container host (Raspi4 mit Ubuntu 20.10) die statische IP 10.0.0.10 Der container mit der pivccu soll die statische IP 10.0.0.4 bekommen.

  1. Netplan Host auf dem Ubuntu 20.x gibt es ja keinen /etc/network/interfaces file mehr, weil das Netzwerk mit Netplan organisiert wird. Standardmäßig ordnet der entsprechende file /etc/netplan/50-cloud-init.yaml dem eth0 eine ip zu. Der File wird wie folgt angepasst:
/etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    renderer: networkd
    ethernets:
        eth0:
            dhcp4: no
            dhcp6: no
            match:
                driver: bcmgenet smsc95xx lan78xx
    bridges:
        br0:
            interfaces: [eth0]
            dhcp4: no
            dhcp6: no
            addresses:
                - 10.0.0.10/24
            gateway4: 10.0.0.1
            nameservers:
                addresses: [10.0.0.1, 8.8.8.8]

Mit "netplan apply" wird das eingelesen. (Achtung die Einrückungen mit Leerzeichen beachten. YAML). Ihr müsst natürlich die IPs so ändern dass Eure Topologie passt. Meine Fritzbox hat 10.0.0.1.

  1. dem LXC Container der pivccu beibringen mit einer statischen IP zu starten. Dazu habe ich einfach in den /var/lib/piVCCU3/rootfs/etc/network/interfaces des Containers die Nummer geschrieben:
auto lo
iface lo inet loopback

auto eth0
#iface eth0 inet manual
iface eth0 inet static
        address 10.0.0.4
        netmask 255.255.255.0
        gateway 10.0.1.1
        dns-nameservers 10.0.0.1

auto wlan0
iface wlan0 inet manual

Die 10.0.1.1 ist kein Tippfehler. Das Routing geht auf die lxcbr0 die Ubuntu so automatisch konfiguriert hat. Mein ifconfig zeigt in summe:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.10  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::acaa:11ff:fe8b:b4de  prefixlen 64  scopeid 0x20<link>
        ether dc:a6:32:e2:45:16  txqueuelen 1000  (Ethernet)
        RX packets 1436  bytes 149641 (149.6 KB)
        RX errors 0  dropped 597  overruns 0  frame 0
        TX packets 143  bytes 17814 (17.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether dc:a6:32:e2:45:16  txqueuelen 1000  (Ethernet)
        RX packets 4278  bytes 757920 (757.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3268  bytes 2612350 (2.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 90  bytes 6826 (6.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 90  bytes 6826 (6.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lxcbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        ether 00:16:3e:00:00:00  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethpivccu: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc66:9cff:fe3c:8a5c  prefixlen 64  scopeid 0x20<link>
        ether fe:66:9c:3c:8a:5c  txqueuelen 1000  (Ethernet)
        RX packets 1853  bytes 2525848 (2.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3912  bytes 716462 (716.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:e2:45:17  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Bestimmt gibt es noch andere Konfigurationen. Seht es also als laufenden Beispiel. Damit kann das issue geschlossen werden.