Deconz-rest-plugin: Verbesserung der Headless-Unterstützung unter Linux (GUI-Abhängigkeiten)

@manup

Ich stimme absolut zu, dass die GUI- und Headless-Teile in zwei Pakete getrennt werden müssen. Das ist eigentlich schon seit geraumer Zeit ein laufender Prozess intern. deCONZ wurde in den Anfangsjahren nicht mit Headless-Gedanken entwickelt und hat jetzt viele miteinander vermischte Klassen, die nicht einfach getrennt werden können. Dieses Refactoring findet statt, aber in einem langsamen Tempo ohne ETA.

Qt selbst bleibt als Abhängigkeit erhalten, aber die X11/Wayland-bezogenen Teile werden für das Headless-Setup nicht benötigt.

Ein langfristiges Ziel ist es, die Teile des GUI-Knotens über die REST-API verfügbar zu machen, sodass ein Remote-Client auch für Headless-Installationen interaktive Knoten mit allen Funktionen der deCONZ-GUI anzeigen kann, beispielsweise in einem Browser.

Die vorgeschlagene Alternative ist tatsächlich der einzige Workaround, um das Host-System X11 bis zum Eintreffen der schlanken Headless-Version freizuhalten.

Ich weiß, dass dies hier etwas vom Thema abweicht, aber ich möchte einen kurzen Bericht über meine Versuche geben, diese GUI-Abhängigkeit mithilfe der Containerisierung zu umgehen.

Mir ist bewusst, dass ein offizielles Docker-Image verfügbar ist, aber um ehrlich zu sein, bevorzuge ich LXC oder einfache systemd-nspawn-Container gegenüber Docker und hatte bereits andere LXC-Container auf meinem NAS, also habe ich versucht, damit zu arbeiten. Schließlich verlassen sich diese Technologien auf die gleichen Kernel-Isolationsmechanismen, sodass sie vergleichbare Ergebnisse liefern sollten - oder zumindest dachte ich das.

Ich habe einen Ubuntu 18.04-Container eingerichtet und mich strikt an die ConnBee- Installationsanleitung bezüglich der Installation von deCONZ gehalten. Dann musste ich mehrere Reifen springen, um die Anwendung zum Laufen zu bringen:

• das USB-Gerät an den LXC-Container weiterleiten ( lxc.cgroup.devices.allow und lxc.mount.entry für den Geräteknoten)
• GIDs synchronisieren, damit die udev-Regeln des Hosts das Gerät für die plugdev -Gruppe innerhalb des Containers zugänglich machen
• Funktionen aus der systemd-Einheit entfernen, da ich nicht wollte, dass die Binärdatei sie hat (in meiner Konfiguration sind sie sowieso nicht erforderlich) und LXC sie blockiert hat (reparierbar mit lxc.cap.keep )

(OT: Ich sehe dort Verbesserungspotenzial in Bezug auf die Paketierung. Anstatt sich auf die fest codierte UID 1000 zu verlassen, wäre es viel besser, während der Paketinstallation einen dedizierten Benutzer zu erstellen, vorzugsweise mit UID<1000 und seinem Home-Verzeichnis unter /var/lib , um der Art und Weise zu entsprechen, wie viele andere Daemons eingerichtet sind. Würde gerne Pull-Anforderungen dafür senden.)

Die Anwendung schien dann zu funktionieren, dh sie hat keinen Fehler ausgespuckt und ich konnte die Grundkonfiguration des Gateways in der Phoscon App einrichten. Alles, was mit der eigentlichen ConnBee-Hardware zu tun hatte, funktionierte jedoch nicht. Phoscon zeigte die Geräteversion, aber nicht die Firmwareversion und alle ZigBee-Eigenschaften (Kanal usw.) wurden auf Null gesetzt. Ich konnte keine Sensoren binden.

Also habe ich einen übrig gebliebenen Raspberry Pi 3 mit dem offiziellen _stable_ Image geflasht. Damit funktioniert jetzt alles einwandfrei und ich habe alle meine Sensoren in ein schönes Grafana-Dashboard integriert.

(OT: Das Pi-Image hat seine eigenen Glitches, z. B. hat es in seiner Standardkonfiguration versucht, hostapd in einer Endlosschleife zu starten, was innerhalb einer Woche etwa 700 MiB an Protokollen produzierte (schlechte SD-Karte!) und eine Tonne von unnötiger Last. Ich würde gerne Pull-Requests zur Verbesserung des Setups senden (ich erstelle zufällig Images für eingebettete Geräte als meine Tagesbeschäftigung), habe aber kein geeignetes Repo gefunden.)

Ein langfristiges Ziel ist es, die Teile des GUI-Knotens über die REST-API verfügbar zu machen, sodass ein Remote-Client auch für Headless-Installationen interaktive Knoten mit allen Funktionen der deCONZ-GUI anzeigen kann, beispielsweise in einem Browser.

Das wäre ein wahr gewordener Traum