Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

Aus FHEMWiki
Zur Navigation springen Zur Suche springen

Conbee/deCONZ im Proxmox LXC-Container (Tutorial)

In diesem Tutorial wird gezeigt, wie sich ein Conbee ZigBee-Gatewas an einen unprivilegierten LXC-Container in einer Proxmox-VE einrichten und vewenden lässt.

Optional wird im Rahmen des Tutorials die Sicherung und Wiederherstellung der deCONZ-Konfiguration am Beispiel eines Umzugs von einem Raspberry PI auf den LXC-Container gezeigt.

Weiterhin wird in diesem Tutorial der deCONZ-Dienst im LXC-Container im Kontext eines dediziert für diesen Dienst angelegten User ("deconz") ohne besondere Berechtigungen eingerichtet. Auch dieser Teil ist optional.

Verwendete Hard-/Software

(Stand: 18.01.2021)

Conbee (1+2) an unprivilegiertem Proxmox LXC-Container

Proxmox-Version: 7.1.8

deCONZ-Vesion: 2.13.04

Bezeichnungen und Darstellung

Im Tutorial werden zur Kennzeichnung der einzelnen Rechnersysteme, auf denen die jeweiligen Arbeiten durchgeführt werden folgende Rechnerbezeichnungen verwendet:

  • "RasPi" - Der Rechner mit der ursprünglich aktiven deCONZ-Installation (war ein Raspberry Pi)
  • "LXC" - Der LXC-Container auf den die Neuinstallation von deCONZ kommt
  • "Node" - Der Proxmox Node (Hardware) auf dem der LXC-Container betrieben wird und an dem letztendlich der Conbee angesteckt wird.

Im folgenden wird immer angegeben auf welchem Rechner mit welchem User gearbeitet wird unter Angebe von user@host. Wenn also bspw. auf dem neuen Container (LXC) mit dem User "myadmin" gearbeitet werden soll, dann steht zu beginn des entsprechenden Abschitts myadmin@LXC. Das heißt, immer wenn im folgenden Text eine solche Angabe kommt ist der User und/oder der Host entsprechend zu wechseln.

Im wesentlichen werden alle Aktionen ausschließlich auf der Kommmandozeile der jeweiligen Systeme durchgeführt, es sei denn es ist explizit anders angegeben.

In der Regel wird für die Anmeldung an den einzelnen Rechnern ssh verwendet. Bei der Anmeldung als root am Proxmox-Node wird das Shell-Fenster, das über die Proxmox-Verwaltung geöffnet werden kann gearbeitet. Genauso wird für die root-Anmeldung am LXC das Console-Fenster des Containers in der Proxmox-Verwaltung verwendet. In beiden Fällen ist eine Remote-Anmeldung von root per ssh ohne weitere Konfiguration nämlich nicht möglich. Das ist gut und soll auch so bleiben! Generell spricht natürlich nichts dagegen auch bei der Arbeit mit anderen Usern auf dem LXC das Console-Fenster der Proxmox-Verwaltung zu nutzen.

Der RasPi, also das "Altsystem" ist eine Quasi-Standard-Installation mit Raspian, von daher gibt es dort auch den Standard-User "pi" mit dem dort gearbeitet wird.

Alle im Folgenden dargestellten Ausgaben von Befehlen werden weiß auf schwarz dargestellt und sind grundsätzlich beispielhaft zu verstehen. Eventuell darin enthaltene Bezeichnungen und IDs können auf einem anderen System anders lauten. Es ist jeweils erklärt, welche Information in der Ausgabe wichtig ist. Dort dann also bitte die individuellen Informationen der eigenen Systeme für die weitere Verarbeitung notieren.

Anlegen des LXC-Container in der Proxmox PVE

Die Erstellung des Containers selbst in der Proxmox-VE ist nicht Teil dieses Tutorials.

Benötigt wird ein unprivilegierter LXC-Container mit kleiner Ausstattung (1024 RAM / 2GB Disk) und aktiviertem nesting. Als Betriebssystem wird Debian 10 (Buster) aus dem entsprechenden Proxmox-Image vorgeschlagen. Debian 10 deshalb, da die deconz-Unterstützung derzeit offiziell nur bis zu dieser Version angegeben wird. Grundsätzlich sollte das aber auch unter Debian 11 (Bullseye) so funktionieren.

Einrichten des Systems auf dem LXC-Container

root@LXC

Folgende Pakete, die nicht mit dem Proxmox-Debian-Image kommen werden im weiteren Verlauf benötigt und müssen installiert werden:

apt install sudo lsb-release gpg usbutils

Auf dem Container werden 2 User eingerichtet, einen für die Administration (myadmin / uid=1000) und einen für den Betrieb von deconz (deconz / uid=1001).

adduser deconz
adduser myadmin

Der myadmin-User bekommt per sudo allumfassende Berechtiung ohne Passwort auf alles. Dazu muss die sudoers-Datei mit folgendem Befehl zur Bearbeitung geöffnet:

visudo

folgende Zeile muss in die Datei eintragen werden

myadmin ALL=(ALL:ALL) NOPASSWD: ALL

Ab jetzt kann für die weitere Einrichtung auf dem LXC-Container der User myadmin verwendet werden.


Installation von deCONZ im LXC-Container

myadmin@LXC

deCONZ wird nach Anleitung bei dresden-elektronik mittels apt installiert (s.a.: https://phoscon.de/en/conbee/install#ubuntu)

Wichtig! Wenn deCONZ so installiert wird, ist anschließend der deconz-Dienst noch nicht aktiviert und läuft folglich auch noch nicht. Das wird im späteren Verlauf nachgeholt.

Der deconz-User soll laut der deCONZ-Installationsanleitung (s.w.u.) der Gruppe dialout hinzugefügt werden. Für den Betrieb auf dem LXC-Container sollte das aber egal sein. Die Rechte auf das USB-Device werden im späteren Verlauf außerhalb der Containers auf dem Proxmox-Node zugewiesen.

Nichts desto trotz:

sudo gpasswd -a deconz dialout

Sicherung der bestehenden deCONZ-Konfiguration (Optional)

pi@RasPi

Für die Übertragung der deCONZ-Konfiguration wird vom Altsystem die Datei "zll.db" gesichert. In diesem Datenbank-File sind alle relevanten Informationen für deCONZ enthalten, inkl. Geräte, Gruppen, etc.

Die Datei befindet sich in einem Ordner Home-Verzeichnis des Users, unter dem der deCONZ-Dienst auf dem RasPi läuft. Das ist im Normalfall ebenfalls der User "pi"

Prüfen kann man das wie folgt:

sudo ps aux|grep deCONZ

Ausgabe ist dann sowas in der Art

root          87  0.0  0.2   3872  2940 ?        Ss   17:03   0:00 /bin/bash /usr/bin/deCONZ-update2.sh
pi            88  0.0  4.6 402472 48436 ?        Ssl  17:03   0:13 /usr/bin/deCONZ -platform minimal --http-port=80
pi          2860  0.0  0.0   3088   880 pts/3    S+   17:54   0:00 grep deCONZ

Interessant ist hier die mittlere Zeile, das ist der deCONZ-Dienst und wie man ganz vorne in der Zeile sieht, läuft er unter dem User "pi".

Die Datei befindet sich also im Ordner

~/.local/share/dresden-elektronik/deCONZ

Wie gesagt wird von dort eigentlich nur die Datei zll.db benötigt. Es kann aber nichts schaden, sich eine Sicherung des kompletten Ordners "dresden-elektronik" zu machen.

Das alte System wird im weiteren Verlauf nicht mehr benötigt, dort kann also der deconz-Dienst beendet werden:

sudo systemctl stop deconz

Weiterhin kann man auch gleich noch die zugehörigen deCONZ-Update- und -WiFi-Dienste beenden:

sudo systemctl stop deconz-update
sudo systemctl stop deconz-wifi

Am besten deaktiviert man im Anschluss die Dienste generell, damit sie bei einem Neustart RasPi nicht automatisch wieder aktiv werden.

sudo systemctl deacitvate deconz
sudo systemctl deacitvate deconz-update
sudo systemctl deacitvate deconz-wifi

Durchreichen des Conbee-Stick an den LXC-Container

Damit der LXC-Container den Conbee-Stick, der physikalisch am Proxmox-Nodet angeschlossen ist, überhaupt verwenden kann, muss zum einen der Container auf die zugehörigen Device-Dateien des Nodes zugreifen dürfen und zum anderen müssen sie auf dem Container auch erst verfügbar gemacht werden. Das ist derzeit leider nicht mit der Pxoxmox-VE Verwaltung im Web-UI machbar, sondern muss durch manuelle Anpassung der Container-Konfigurationsdatei erfolgen.

Benötigte USB-Informationen ermitteln

Die im folgenden ermittelten Informationen werden benötigt, um das USB-Gerät an den LXC-Container durchreichen zu können und diesem Zugriff darauf zu gewähren.

root@Node

Bevor nun der Conbee am Proxmox-Node angeschlossen wird, lässt man sich am besten einmal die aktuell vorhandenen USB-Geräte anzeigen, das erleichtert im nächsten Schritt die Identifikation der verwendeten USB-Systemgeräte.

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


ls /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1

Jetzt wird der Conbee am Proxmox-Node eingesteckt und die beiden gerad ausgeführten Befehle nochmals wiederholt

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 8087:0a2a Intel Corp. Bluetooth wireless interface
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 007: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)

Die letzte Zeile ist neu hinzugekommen, also muss das der Conbee sein!

Folgende Informationen aus dieser Zeile werden für die weitere Konfiguration benötigt:

  • Die BUS-Geräte-Informationen, Sprich die USB-Bus-Nummer (im Beispiel die 001) und die Device-Nummer auf dem Bus (im Beispiel die 007)
  • Vendor- und die Product-ID des Gerätes. Das steckt im Beispiel in dieser Zahlenkombination 0403:6015. Der Teil vor dem Doppelpunkt ist die Vendor-ID ist (0403) und der Teil nach dem Doppelpunkt ist die Product-ID (6015)


ls /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 1 Jan 17 13:49 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0

ttyUSB0 ist gegenüber dem vorherigen Aufruf hinzugekommen, dann gehört das Device zum Conbee. Auch der Datei-Zeitstempel passt zum Zeitpunkt des Anschließens am Node

Die relevante Information ,die aus dieser Ausgabe benötigt wird ist die 188. Das ist die (Major-)Nummer des Treibers, der für das Gerät zuständig ist.


Nun werden die zuvor notierten Bus- und Device-Nummer benötigt. Damit listet man sich das entsprechende USB-Bus-Device auf:

ls -l /dev/bus/usb/001/007
crw-rw-r-- 1 root root 189, 6 Jan 18 17:11 /dev/bus/usb/001/007

Die relevante Information dieser Ausgabe ist auch hier die Treibernummer (189).

Anpassung der Container-Konfiguration

Für die Anpassung der Container-Konfiguration muss direkt die Container-Konfigurationsatei editiert werden. Dazu wird die Container-ID des LXC benötigt, die man am einfachsten aus der Proxmox-Verwaltung liest.

root@Node

Die Konfigurationsdatei des LXC-Containers befindet sich unter

/etc/pve/local/lxc/

und ist nach folgendem Schema benannt: <CONTAINER-ID>.conf das <CONTAINER-ID> ist natürlich mit der zuvor ermittelten Container-ID zu ersetzen

Die Datei mit der entsprechenden Container-ID wird nun editiert

nano <CONTAINER-ID>.conf

Am Ende der Datei werden entsprechend der zuvor gesammelten Informationen folgende Zeilen am Ende eingefügt:

lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/001/007 dev/bus/usb/001/007 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file

Zur Erinnerung: Die genannten Werte sind nur Beispielhaft und müssen durch die zuvor, individuell ermittelten Werte aus 5. ersetzt werden!

  • In die 1. Zeile kommt die 189 (die aus der Ausgabe von ls -l /dev/bus/usb/001/007 kommt). Damit wird dem Container der Zugriff auf USB-Bus-Devices gestattet.
  • In der 2. Zeile kommt 2 mal der Bus-Device-Pfad, genau so, wie er auch beim ls verwendet wurde. Damit wird das Bus-Device des Node im Container genau unter dem selben Pfad gemountet.
  • In der 3. Zeile wird dem Container der Zugriff auf USB-Serial-Devices eingerichtet. (die 188 kommt aus dem ls -l /dev/ttyUSB*)
  • In der 4. Zeile wird das USB-Serial-Device ttyUSB0 unter demselben Pfad im LXC-Container gemountet.

Bei den beiden Mount-Angaben ist der erste Teil immer die Quelle, also der Pfad auf dem Node und der zweite Teil das Ziel, also der Pfad im LXC-Container. Die Devices können bei Bedarf und Wunsch also auch unter anderen Bezeichnungen im LXC-Container verfügbar gemacht werden.

myadmin@LXC

Nach dem Speichern der Änderungen muss der LXC-Container (!) einmal neu gestartet werden:

sudo reboot now

myadmin@LXC

Überprüfen, ob die Änderunge erfolgreich für im LXC-Container übernommen und angewendet wurden:


ls -l /dev/bus/usb/001/007
crw-rw-r-- 1 nobody nogroup 189, 6 Jan 18 16:11 /dev/bus/usb/001/007

Das ist die erwartete Ausgabe!

ls -l /dev/ttyUSB*
crw-rw---- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0

Auch das ist die erwartete Ausgabe.

Anpassung der Berechtigungen auf dem Node

Die letzte Ausgabe ist von zusätzlichem Interesse, denn Dort kann man sehen, dass nur der Eigentümer und die Gruppe Zugriff auf das Gerät haben, alle anderen (other) aber nicht. Leider sind als Eigentümer der User "nobody" und die Gruppe "nogroup" angegeben. Das liegt daran, Die User/Gruppen und Berechtigungen vom Host-System nicht ohne Weiteres an einen (unprivilegierten) Container weitergegeben werden können. Es gibt zwar die Möglichkeit dies durch ein entsprechendes Mapping der uid und gid in der Konfigurationsdatei des Containers zu erreichen. Einfacher ist es aber, auf dem Node auch "allen anderen" (other) den Zugriff auf das Device zu erlauben. Temporär erreicht man das durch ganz normale Rechteanpassung:

root@node

chmod o+rw /dev/ttyUSB0

Ob die Änderungen wirksam sind, sieht man mittels

ls -l /dev/ttyUSB0
crw-rw-rw- 1 root dialout 188, 0 Jan 18 19:15 /dev/ttyUSB0

Genau so soll es sein! Das Device darf nun von jedem gelesen und beschrieben werden.

Die Rechte müssten auch direkt auf dem Container entsprechend erweitert worden sein. Auch das kann man überprüfen

myadmin@LXC


ls -l /dev/ttyUSB0
crw-rw-rw- 1 nobody nogroup 188, 0 Jan 18 19:49 /dev/ttyUSB0

Man sieht, auch im Container kann nun jeder lesend und schreibend auf das Gerät zugegriffen werden. Genau so wird das auch benötigt.

Wie schon erwähnt ist die gerade durchgeführte Rechteanpassung nur temporär. Sprich wird der Pxoxmox-Node neu gestartet, sind die Schreib-/Leserechte für other auf das Device wieder verloren. Damit diese Rechtezuweisung auf dem Proxmox-Node auch über einen Systemneustart erhalten bleibt, genauer gesagt dann wieder automatisch eingerichtet wird, wird nun eine entsprechende udev-Regel auf dem Proxmox-Node eingerichtet.

root@Node


Es wird die Datei mit dem Editor angelegt

nano /etc/udev/rules.d/50-lxcusb.rules

Folgende Zeile wird dort eingetragen:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6015", GROUP="users", MODE="0666"

Hier sind natürlich wieder die oben ermittelten individuellen Werte für Vendor- und Product-ID einzutragen. Durch diese Regel werden die Rechte für das, durch Product- und Vendor-ID identifizierte Device beim Systemstart auf den in MODE eingestellten wert (0666 -> rw-rw-rw) festgelegt.

Damit ist die USB-Geräteeinrichtung abgeschlossen.


Info blue.png
Wenn der Stick irgendwann umgesteckt wird, teilweise auch nur, wenn er aus und wieder neu eingesteckt wird, ändert sich u.U. die Device-Nummer (007) ggf. auch die Bus-Nummer (001). In diesem Fall muss die LXC-Container-Konfigurationsdatei entsprechend angepasst werden.



Info blue.png
Wenn der LXC-Container auf einen anderen Proxmox-Node migriert wird, muss natürlich der Conbee am neuen angesteckt angesteckt werden und entsprechend durchgereicht werden.


Einrichtung und Konfigurieren des deCONZ-Dienstes

Jetzt erst wird der Dienst im LXC-Container aktiviert

myadmin@LXC

sudo systemctl enable deconz

Bevor der Dienst nun gestartet wird, wird zunächst das Services-File an die gewünschten gegebenheiten angepasst (optional!) Zum einen wird der User angepasst, unter dem der deconz-Service laufen soll und zum anderen wird dem deconz dienst beim Aufruf mitgeteilt, wo er den Conbee findet (/dev/ttyUSB0)

Bei der Aktivierung des Dienstes wurde der Dateipfad, bzw. der erzeugte Symlink auf die Service-Datei ausgegeben.

/etc/systemd/system/multi-user.target.wants/deconz.service -> /lib/systemd/system/deconz.service

Es ist jetzt egal, ob über den symlink oder die Datei direkt editiert wird. Editiert werden muss allerdings mit root-Rechten (sudo)

sudo nano /etc/systemd/system/multi-user.target.wants/deconz.service

Nach der Änderung sollte die Datei so aussehen

Die Service-Datei sieht bei mir nach Änderung so aus:

[Unit]
Description=deCONZ: ZigBee gateway -- REST API
Wants=deconz-init.service deconz-update.service
StartLimitIntervalSec=0

[Service]
User=deconz
ExecStart=/usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
Restart=on-failure
RestartSec=30
AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_KILL CAP_SYS_BOOT CAP_SYS_TIME

[Install]
WantedBy=multi-user.target

Die genannten Änderungen finden sich in den ersten beiden Zeilen im Abschnitt [Service] Beim User stand ursprünglich die uid des Users drin, es funktioniert allerdings auch mit dem Usernamen. Falls nicht, dann gegen die gewünschte uid austauschen.

Nach dem Speichern der Datei muss systemctl dazu aufgefordert werden, die Änderungen zu übernehmen:

sudo systemctl daemon-reload

Dann kann der Dienst endlich gestartet werden

sudo systemctl start deconz


Überprüfen kann man das am einfachsten indem man sich den entsprechenden Prozess aus der Prozessliste filtert:

sudo ps aux|grep deCONZ
root          87  0.0  0.2   3872  2940 ?        Ss   17:03   0:01 /bin/bash /usr/bin/deCONZ-update2.sh
deconz        88  0.0  4.6 402472 48436 ?        Ssl  17:03   0:55 /usr/bin/deCONZ -platform minimal --http-port=80 --dev=/dev/ttyUSB0
myadmin    10727  0.0  0.0   3088   816 pts/3    S+   20:36   0:00 grep deCONZ

Man sieht in der Ausgabe, der Dienst läuft unter dem gewünschten User "deconz" und auch das ttyUSB0 wurde beim Start korrekt übergeben.

Damit ist die grundsätzliche Einrichtung von deCONZ auf dem LXC-Container mit durchgereichtem Conbee abgeschlossen.

Wiederherstellen der vorherigen deCONZ-Konfiguration (Optional)

Wenn die deCONZ-Konfiguration samt Conbee von einem bestehenden System in den Container "umziehen" soll muss nun noch lediglich die in Punkt 5. gesicherte Datei "zll.db" in das deCONZ-Verzeichnis unter dem User deCONZ kopiert werden:

myadmin@LXC


Dazu muss der Dienst zunächst gestoppt werden

sudo systemctl stop deconz

Dann kann die Datei aus der vorherigen Sicherung vom Altsystem übertragen werden Ziel ist in diesem Beispiel dann im Home-Verzeichnis des Users deconz:

/home/deconz/.local/share/dresden-elektronik/deCONZ

Jetzt muss der Dienst nur wieder gestartet werden.

sudo systemctl start deconz

Jetzt kann man sich wie gewohnt, mit dem Browser an der Phoscon-App auf dem LXC-Container anmelden. Dort sollte dann das "alte" Gateway zur Auswahl stehen und nach Anmeldung am Gateway sollten auch alle Gruppen, Lichter, Schalter, .... vorhanden und bedienbar sein.

Anpassungen in FHEM (Optional)

Wenn der Conbee bisher in FHEM als HUE-IO verwendet wurde muss im entsprechenden FHEM-Device (Bspw.: "deCONZ") im DEF die IP-Adresse des LXC-Containers eingetragen werden.

Anmerkungen

  • Die Einrichtung zum Durchreichen von USB-Serial-Devices an unprivilegierte LXC-Container ist grundsätzlich auch für andere USB-Devices anwendbar. Auf gleiche Art und Weise lässt sich bspw. ein Volkszähler USB-Lesekopf am Proxmox-Node anschließen und an einen LXC-Container durchreichen.
  • Die Sicherung und Wiederherstellung der deCONZ-Konfiguration lässt sich so natürlich auch bei einem System-Upgrade oder einer geplanten System-Neuinstallation anwenden.