Deconz-rest-plugin: Linuxでのヘッドレスサポートの改善（GUIの依存関係）

@manup

GUIとヘッドレスパーツを2つのパッケージに分ける必要があることに完全に同意します。 これは実際にはすでにかなり長い間内部で進行中のプロセスです。 初期のdeCONZはヘッドレスを念頭に置いて開発されたものではなく、今では簡単に分離できない多くの混ざり合ったクラスがあります。 このリファクタリングは行われていますが、ETAがなく遅いペースです。

Qt自体は依存関係として残りますが、ヘッドレスセットアップにはX11 / Wayland関連のパーツは必要ありません。

長期的な目標の1つは、REST-APIを介してGUIノードの部分を公開し、ヘッドレスインストールの場合でも、リモートクライアントがdeCONZ GUIのすべての機能を備えたインタラクティブノードを、たとえばブラウザーで表示できるようにすることです。

提案された代替案は、実際には、スリムなヘッドレスバージョンが到着するまでホストシステムX11を解放しておくための唯一の回避策です。

ここではこれが少し話題から外れていることは知っていますが、コンテナ化を使用してこのGUI依存関係を回避しようとした試みについて簡単に報告したいと思います。

公式のDockerイメージが利用可能であるという事実を知っていますが、正直なところ、DockerよりもLXCまたはプレーンなsystemd-nspawnコンテナーを好み、NASにはすでに他のLXCコンテナーがあったので、それを試してみました。 結局のところ、これらのテクノロジーは同じカーネル内分離メカニズムに依存しているため、同等の結果が得られるはずです。少なくともそう思いました。

Ubuntu 18.04コンテナをセットアップし、deCONZのインストールに関してConnBeeインストールガイドに厳密に従いました。 次に、アプリケーションを実行するためにいくつかのフープをジャンプする必要がありました。

• USBデバイスをLXCコンテナに転送します（デバイスノードの場合はlxc.cgroup.devices.allowとlxc.mount.entry ）
• GIDを同期して、ホストのudevルールにより、コンテナー内のplugdevグループがデバイスにアクセスできるようにします。
• バイナリに機能を持たせたくなかったので（私の構成では機能は必要ありません）、LXCが機能をブロックしたため（ lxc.cap.keepを使用して修正可能）、systemdユニットから機能を削除します

（OT：そこでのパッケージ化に関して改善の余地があると思います。ハードコードされたUID 1000に依存する代わりに、パッケージのインストール中に、できればUID <1000とそのホームディレクトリが/var/lib未満の専用ユーザーを作成する方がはるかに良いでしょう。

その後、アプリケーションは機能しているように見えました。つまり、エラーは発生せず、Phosconアプリで基本的なゲートウェイ構成をセットアップできました。 ただし、実際のConnBeeハードウェアに関連するすべてが機能するわけではありません。 Phosconはデバイスのバージョンを表示しましたが、ファームウェアのバージョンは表示せず、すべてのZigBeeプロパティ（チャネルなど）がゼロになりました。 センサーをバインドできませんでした。

そのため、残りのRaspberry Pi3を公式の_stable_イメージでフラッシュすることになりました。 これで、すべてが正常に機能し、すべてのセンサーが素敵なGrafanaダッシュボードに統合されました。

（OT：Piイメージには独自の不具合があります。たとえば、デフォルトの構成では、1週間以内に約700 MiBのログを生成する無限ループでhostapdを開始しようとしました（SDカードが貧弱です！）。セットアップを改善するためのプルリクエストを送信できれば幸いです（私は日中の仕事として組み込みデバイス用のイメージを作成しています）が、適切なリポジトリが見つかりませんでした。）

長期的な目標の1つは、REST-APIを介してGUIノードの部分を公開し、ヘッドレスインストールの場合でも、リモートクライアントがdeCONZ GUIのすべての機能を備えたインタラクティブノードを、たとえばブラウザーで表示できるようにすることです。

それは夢の実現です