Conbee/deCONZ im Proxmox LXC-Container (Tutorial)
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.
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.