Deconz-rest-plugin: Améliorer la prise en charge sans tête sur Linux (dépendances de l'interface graphique)

@manup

Je suis absolument d'accord que l'interface graphique et les parties sans tête doivent être séparées en deux packages. Il s'agit en fait déjà d'un processus en cours en interne depuis un certain temps. deCONZ dans ses premières années n'a pas été développé avec un esprit sans tête et a maintenant de nombreuses classes entremêlées qui ne peuvent pas être séparées facilement. Cette refactorisation se produit mais à un rythme lent sans ETA.

Qt lui-même restera une dépendance, mais les parties liées à X11/Wayland ne seront pas nécessaires pour une configuration sans tête.

Un objectif à long terme est d'exposer les parties du nœud GUI via REST-API afin que même pour les installations sans tête, un client distant puisse afficher des nœuds interactifs, avec toutes les fonctionnalités de deCONZ GUI, par exemple dans un navigateur.

L'alternative suggérée est en fait la seule solution de contournement pour garder le système hôte X11 libre jusqu'à l'arrivée de la version slim sans tête.

Je sais que c'est un peu hors sujet ici, mais j'aimerais faire un bref rapport sur mes tentatives de contourner cette dépendance de l'interface graphique en utilisant la conteneurisation.

Je suis conscient du fait qu'il existe une image Docker officielle disponible, mais pour être honnête, je préfère les conteneurs LXC ou plain systemd-nspawn à Docker et j'avais déjà d'autres conteneurs LXC sur mon NAS, j'ai donc essayé d'y aller. Après tout, ces technologies reposent sur les mêmes mécanismes d'isolation dans le noyau, elles devraient donc donner des résultats comparables - du moins, je le pensais.

J'ai configuré un conteneur Ubuntu 18.04 et suivi strictement le guide d'installation ConnBee concernant l'installation de deCONZ. Ensuite, j'ai dû sauter plusieurs étapes pour que l'application fonctionne :

• transférer le périphérique USB vers le conteneur LXC ( lxc.cgroup.devices.allow et lxc.mount.entry pour le nœud de périphérique)
• synchroniser les GID afin que les règles udev de l'hôte rendent l'appareil accessible au groupe plugdev à l'intérieur du conteneur
• supprimez les capacités de l'unité systemd car je ne voulais pas que le binaire les ait (dans ma configuration, elles ne sont pas nécessaires de toute façon) et LXC les a bloquées (réparable en utilisant lxc.cap.keep )

(OT : Je vois des améliorations à apporter en ce qui concerne l'empaquetage. Au lieu de s'appuyer sur l'UID 1000 codé en dur, il serait bien préférable d'avoir un utilisateur dédié créé lors de l'installation du paquet, de préférence avec l'UID<1000 et son répertoire d'accueil en dessous /var/lib pour correspondre à la façon dont de nombreux autres démons sont configurés. Serait heureux d'envoyer des demandes d'extraction pour cela.)

L'application a alors semblé fonctionner, c'est-à-dire qu'elle n'a pas craché d'erreur et j'ai pu configurer la configuration de base de la passerelle dans l'application Phoscon. Cependant, tout ce qui concernait le matériel ConnBee réel ne fonctionnait pas. Phoscon a montré la version de l'appareil mais pas la version du firmware et toutes les propriétés ZigBee (canal, etc.) ont été mises à zéro. Je n'ai pu lier aucun capteur.

J'ai donc fini par flasher un Raspberry Pi 3 restant avec l'image _stable_ officielle. Avec cela, tout fonctionne maintenant bien et j'ai intégré tous mes capteurs dans un joli tableau de bord Grafana.

(OT : L'image Pi a ses propres problèmes, par exemple, dans sa configuration par défaut, elle a essayé de démarrer hostapd dans une boucle sans fin qui a produit environ 700 Mio de journaux en une seule semaine (mauvaise carte SD !) Et une tonne de charge inutile. Je serais heureux d'envoyer des demandes d'extraction pour améliorer la configuration (il se trouve que je fais des images pour les appareils intégrés dans le cadre de mon travail de jour), mais je n'ai pas trouvé de référentiel approprié.)

Un objectif à long terme est d'exposer les parties du nœud GUI via REST-API afin que même pour les installations sans tête, un client distant puisse afficher des nœuds interactifs, avec toutes les fonctionnalités de deCONZ GUI, par exemple dans un navigateur.

Ce serait un rêve devenu réalité