Deconz-rest-plugin: 改进 Linux 上的 Headless 支持（GUI 依赖项）

@manup

我绝对同意 GUI 和无头部分需要分成两个包。 这实际上已经在内部进行了相当长的一段时间。 deCONZ 早期并没有以无头思想开发，现在有许多无法轻易分离的混合类。 这种重构正在发生，但速度很慢，没有 ETA。

Qt 本身将作为依赖项保留，但无头设置不需要 X11/Wayland 相关部分。

一个长期目标是通过 REST-API 公开 GUI 节点部分，以便即使对于无头安装，远程客户端也可以显示具有 deCONZ GUI 的所有功能的交互式节点，例如在浏览器中。

建议的替代方案实际上是在超薄无头版本到来之前保持主机系统 X11 空闲的唯一解决方法。

我知道这有点离题，但我想快速报告一下我使用容器化解决此 GUI 依赖项的尝试。

我知道有一个官方的 Docker 镜像可用，但老实说，我更喜欢 LXC 或普通的 systemd-nspawn 容器而不是 Docker，并且我的 NAS 上已经有其他 LXC 容器，所以我尝试使用它。 毕竟，这些技术依赖于相同的内核隔离机制，因此它们应该给出可比较的结果——或者至少我是这么认为的。

我设置了一个 Ubuntu 18.04 容器，并严格按照ConnBee 安装指南安装 deCONZ。 然后我不得不跳几圈才能让应用程序运行：

• 将 USB 设备转发到 LXC 容器（ lxc.cgroup.devices.allow和lxc.mount.entry用于设备节点）
• 同步 GID，以便主机的 udev 规则使容器内的plugdev组可以访问设备
• 从 systemd 单元中删除功能，因为我不希望二进制文件拥有它们（在我的配置中无论如何都不需要它们）并且 LXC 阻止了它们（可使用lxc.cap.keep修复）

（OT：我认为那里的打包还有改进的空间。与其依赖硬编码的 UID 1000，不如在包安装期间创建一个专门的用户，最好是 UID<1000 并且它的主目录低于/var/lib以匹配许多其他守护进程的设置方式。很乐意为此发送拉取请求。）

然后该应用程序似乎工作了，即它没有吐出任何错误，我可以在 Phoscon 应用程序中设置基本网关配置。 但是，与实际 ConnBee 硬件相关的一切都不起作用。 Phoscon 显示设备版本，但不显示固件版本，所有 ZigBee 属性（通道等）都归零。 我无法绑定任何传感器。

所以我最终用官方的_stable_镜像刷了一个剩余的Raspberry Pi 3。 有了它，现在一切正常，我将所有传感器都集成到了一个漂亮的 Grafana 仪表板中。

（OT：Pi 映像有其自身的故障，例如，在其默认配置中，它试图在一个无限循环中启动hostapd ，该循环在一周内产生了大约 700 MiB 的日志（可怜的 SD 卡！）和一吨不必要的负载。我很乐意发送拉取请求以改进设置（我碰巧为嵌入式设备制作图像作为我的日常工作），但还没有找到合适的存储库。）

一个长期目标是通过 REST-API 公开 GUI 节点部分，以便即使对于无头安装，远程客户端也可以显示具有 deCONZ GUI 的所有功能的交互式节点，例如在浏览器中。

那将是梦想成真