Deconz-rest-plugin: Improve Headless Support on Linux (GUI Dependencies)

@manup

I absolutely agree that the GUI and headless parts need to be separated into two packages. This is actually already an ongoing process internally for quite some time. deCONZ in it's early years wasn't developed with headless in mind and now has many intermingled classes which can't be separated easily. This refactoring is happening but at a slow pace with no ETA.

Qt itself will stay as a dependency, but the X11/Wayland related parts won't be needed for headless setup.

One long term goal is to expose the GUI node parts via REST-API so that even for headless installations a remote client can display interactive nodes, with all features of deCONZ GUI, for example in a browser.

The suggested alternative is in fact the only workaround to keep the host system X11 free until the slim headless version arrives.

I know this is slightly off-topic here but I'd like to give a quick report back on my attempts of working around this GUI dependency using containerization.

I am aware of the fact that there is an official Docker image available, but to be honest I prefer LXC or plain systemd-nspawn containers over Docker and already had other LXC containers on my NAS so I tried to go with that. After all, these technologies rely on the same in-Kernel isolation mechanisms so they should give comparable results - or at least so I thought.

I set up a Ubuntu 18.04 container and strictly followed the ConnBee Install Guide regarding installation of deCONZ. Then I had to jump several hoops to get the application running:

• forward the USB device to the LXC container (lxc.cgroup.devices.allow and lxc.mount.entry for the device node)
• sync GIDs so the udev rules of the host make the device accessible to the plugdev group inside the container
• remove capabilities from the systemd unit as I did not want the binary to have them (in my configuration they are not required anyway) and LXC blocked them (fixable using lxc.cap.keep)

(OT: I see room for improvement regarding packaging there. Instead of relying on hard-coded UID 1000 it would be much better to have a dedicated user created during package installation, preferably with UID<1000 and its home directory below /var/lib to match the way many other daemons are set up. Would happily send pull requests for that.)

The application then seemed to work, i.e. it did not spit out any error and I could set up the basic gateway configuration in the Phoscon App. However, everything related to the actual ConnBee hardware did not work. Phoscon showed the device version but not the firmware version and all ZigBee properties (channel etc.) were zeroed. I could not bind any sensors.

So I ended up flashing a left-over Raspberry Pi 3 with the official _stable_ image. With that, everything now works fine and I got all my sensors integrated in a nice Grafana dashboard.

(OT: The Pi image has its own glitches, e.g. in its default configuration it tried to start hostapd in an endless loop which produced around 700 MiB of logs within a single week (poor SD card!) and a ton of unnecessary load. I'd be happy to send pull requests for improving the setup (I happen to make images for embedded devices as my day-time job), but haven't found a suitable repo.)

One long term goal is to expose the GUI node parts via REST-API so that even for headless installations a remote client can display interactive nodes, with all features of deCONZ GUI, for example in a browser.

That would be a dream coming true