[V4] Intégration Zigbee2mqtt

VonOx · Mai 7, 2020, 12:02

Dans la documentation la commande de création du conteneur la commande prend déjà en compte le mappage de volume A privacy-first, open-source home assistant | Gladys Assistant

docker run -d \
--restart=always \
--privileged \
--network=host \
--name gladys \
-e NODE_ENV=production \
-e SERVER_PORT=80 \
-e TZ=Europe/Paris \
-e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/gladysassistant:/var/lib/gladysassistant \
-v /dev:/dev \
gladysassistant/gladys:4.0.0-beta-arm

-v /dev:/dev ou -v /run/udev:/run/udev et surtout –privileged

Dans ton script il manque --privileged

Sous entendu que la portée du WiFi ou que l’ethernet soit dispo. Je vois l’idée , je penses que les pods vont répondre à ce besoin.

La criticité est la même entre router et coordinator, on peut exprimer la même chose avec le dongle , s’il tombe tu n’as plus rien. Faut juste pas qu’on conseil autre chose que ce que défini le projet zigbee2mqtt pour augmenter la portée. ( Un router n’est ni plus ni moins qu’un coordinateur avec un firmware différent ).

Je compte tester ce soir ton image , je te ferai un retour

VonOx · Mai 7, 2020, 12:11

On essaye de trouver une solution qui gère tout les type de network ( bridge / host ) , c’est pas gagné

duvalale · Mai 7, 2020, 12:35

Je suis également sur Raspbian buster.

Effectivement, je n’avais pas vu que tu avais rajouté ce paramètre comme j’ai utilisé le lancement manuel
Merci beaucoup, je vais enfin pouvoir tester tout ça

Reno · Mai 7, 2020, 12:49

Chez moi, ça fonctionne sans cette option que j’essaye d’éviter au maximum car elle donne l’accès root à toute la machine hôte depuis le container.
Déjà que partager /deven entier c’est limite…

Pour avoir votre avis, je me disais qu’il faudrait peut-être créer des règles udev qui définiraient les dongles en /dev/zigbee ou /dev/zwave en fonction du dongle connecté et comme ça on pourrait partager uniquement ceux-ci avec le container Gladys.
Qu’en pensez-vous ?

Cool !
Ça permettra d’avancer.

Tu as vu que pour zigbee2mqtt, j’avais créé un network pour une communication isolée entre les containers. Ensuite, je connecte Gladys au container MQTT en utilisant le nom du container dans l’URL.

Du coup, @duvalale, pourrais-tu tester avec et sans l’option --privileged, pour confirmer mes dires ?

VonOx · Mai 7, 2020, 1:15

Oui j’ai vu mais faut que ça marche peut importe le network. ( tout le monde n’utilise pas l’image raspbian ni de rpi )

Reno · Mai 7, 2020, 1:23

Pourquoi ça ?
Le network correspond à un lien privilégié (comme un câble ethernet virtuel) pour la communication entre les 2 containers (Gladys et MQTT). Il ne dépend pas de l’OS ni du matériel, c’est une couche Docker.
Les autres services qui devront communiquer avec le broker MQTT pourront utiliser l’adresse locale de la machine sur laquelle il (le broker) tourne.

VonOx · Mai 7, 2020, 1:34

J’ai jamais dit le contraire, je ne dit pas non plus que ta réflexion n’est pas la bonne, mais on ne contrôle cet environnement que sur l’image raspbian.

Je vais encore me prendre en exemple ( vous allez me dire que je suis casse bonbon ) , chez moi gladys ne tourne pas sur un rpi , ni sur un network bridge / host.
Chez toi tu créé un network pour gladys, mais un autre utilisateur peut faire différemment.
Donc le dev tel quel ne fonctionne pas sur mon environnement sauf si je fais des modifs côté docker ou côté gladys.
On doit doit gérer tout les cas. Peut être qu’on fera pas 100% mais faut s’en approcher et documenter le reste.

VonOx · Mai 7, 2020, 1:45

D’ailleurs tu m’a donné une idée, on peut récupérer le network du conteneur “maitre” et créé les conteneur “enfant” sur le même network.
Comme ça on exploite la résolution via le hostname.

Reno · Mai 7, 2020, 2:37

Je suis tout à fait d’accord pour s’adapter au maximum de cas. Moi même, je fais tourner Gladys sur un NAS OMV.

Ce que je propose reste au niveau Docker donc devrait fonctionner pour tout le monde.
Par contre, ôte moi d’un doute, Gladys tourne bien toujours sous Docker, non ?

C’est ce que je fais mais comme Gladys n’était pas aujourd’hui démarré avec un réseau associé au container, j’ai du en créer un que j’utilise ensuite pour communiquer avec les containers externes et utiliser la résolution de nom de Docker.

En fait, je crois qu’on dit à peu près la même chose mais par message texte, c’est pas toujours facile de se comprendre.

duvalale · Mai 7, 2020, 2:38

Effectivement, pas besoin du --privileged chez moi non plus, mais on a la même distribution donc ça ne veut pas forcément dire que c’est le cas pour tous …

Je teste quelques jours et je ferais un petit retour, j’ai déjà noté quelques soucis mais à voir si ça vient du service Zigbee2Mqtt ou pas

VonOx · Mai 7, 2020, 3:58

Non pas forcément, regarde la PR d’Alex , il teste d’abord que l’environnement est bien sous docker.

github.com

GladysAssistant/Gladys/blob/a4c9a8dd22f25052597f3ededc4d84637d72ae04/server/lib/system/system.createContainer.js#L11


      
          const { PlatformNotCompatible } = require('../../utils/coreErrors');
          
          /**
           * @description Pull an new container image.
           * @param {string} options - Otpions.
           * @returns {Promise} THe created container.
           * @example
           * await createContainer(options);
           */
          async function createContainer(options) {
            if (!this.dockerode) {
              throw new PlatformNotCompatible('SYSTEM_NOT_RUNNING_DOCKER');
            }
            const createdContainer = await this.dockerode.createContainer(options);
            const containers = await this.getContainers({ all: true, filters: { id: [createdContainer.id] } });
            return containers[0];
          }
          
          module.exports = {
            createContainer,
          };

VonOx · Mai 7, 2020, 9:54

En fait je peux pas , y’a pas d’image amd64 ( Je ferai un build demain )

Reno · Mai 7, 2020, 11:52

Ah oui, c’est vrai, je n’ai généré que pour arm.
J’ai relancé le build et toutes les images existent maintenant.

VonOx · Mai 8, 2020, 8:26

Merci @Reno, je test dans la journée

VonOx · Mai 8, 2020, 10:35

@Reno je viens de lancer le container, on est d’accord qu’on est obligé de passer par tes conteneurs ? Pas moyen pour le moment d’utiliser un serveur mqtt existant ?

Le log: ( je ne sais pas à quoi il a souscris )

  vonox  ~  docker logs gladys-zigbee2mqtt

> gladys-server@ start:prod /src/server
> cross-env NODE_ENV=production node index.js

Initialising OpenZWave 1.6.974 binary addon for Node.JS.
        OpenZWave Security API is ENABLED
        ZWave device db    : /etc/openzwave
        User settings path : /src/server/services/zwave/node_modules/openzwave-shared/build/Release/../../
        Option Overrides : --Logging false --ConsoleOutput false --SaveConfiguration true
2020-05-08T12:25:23+0200 <info> index.js:20 (Object.start) Starting Dark Sky service
2020-05-08T12:25:23+0200 <info> index.js:16 (Object.start) Starting zwave service
2020-05-08T12:25:23+0200 <info> index.js:19 (Object.start) Starting telegram service
2020-05-08T12:25:23+0200 <info> index.js:13 (Object.start) Starting usb service
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service darksky is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service telegram is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service zwave is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service zigbee2mqtt is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> service.start.js:16 (Service.start) Service mqtt is not configured, so it was not started.
2020-05-08T12:25:23+0200 <info> index.js:63 (Server.<anonymous>) Server listening on port 4080
2020-05-08T12:27:06+0200 <info> docker.stopContainer.js:18 (Docker.stopContainer) container zigbee2mqtt stopped
2020-05-08T12:27:07+0200 <info> docker.startContainer.js:18 (Docker.startContainer) container zigbee2mqtt started
2020-05-08T12:31:55+0200 <info> connect.js:23 (Zigbee2mqttManager.connect) Zigbee2mqtt USB dongle attached to /dev/ttyACM0
2020-05-08T12:31:55+0200 <info> subscribe.js:12 (Zigbee2mqttManager.subscribe) Subscribing to MQTT topic zigbee2mqtt/#

VonOx · Mai 8, 2020, 10:44

Je plussois !

@pierre-gilles où pourrai t on mettre à disposition les fichiers , repo spécifique ou dans le repo de la doc ?

pierre-gilles · Mai 8, 2020, 11:52

Je ne pense pas qu’on veuille limiter l’accès du container Gladys à la machine.

Je rappelle que l’image Raspbian Gladys doit fonctionner pendant tout le cycle de vie du Raspberry Pi de l’utilisateur.

Imaginons que l’utilisateur installe Gladys en 2020, et qu’il change de Pi en 2030. Pendant 10 ans, si on ajoute des fonctionnalités, que des nouvelles intégrations sont développés dans Gladys, il faut que l’image Raspbian soit évolutive et que tous les dongles que l’on branche soit gérés par Gladys.

Si on doit demander à l’utilisateur de réinstaller Gladys tous les 4 matins, alors nous avons raté notre mission.

Je cite un post que j’avais écris sur un autre sujet:

Pourquoi utilise on Docker?

Dans Gladys 3, je rappelle qu’on exécutait Gladys directement sur la machine, sans Docker, donc Gladys avait accès à toute la machine.

Dans Gladys 4, on utilise Docker pour faciliter le packaging, le déploiement et la mise à jour des instances Gladys. Etant donné qu’on est dans de l’embarqué, qu’on a besoin d’accéder à des périphériques (USB, GPIO, Camera Pi par le Bus caméra par exemple) cela fait tout à fait sens de donner full accès à la machine à Gladys, comme ce serait le cas si jamais on faisait juste tourner le programme en direct sur le Raspberry Pi.

On est pas du tout dans l’usage Docker d’un provider cloud qui souhaiterait isoler l’exécution de code non-trusté, limiter l’accès à la machine physique, et limiter les ressources d’utilisation d’un utilisateur tiers.

Ici, l’utilisateur fait tourner sur sa machine à lui, tout seul, un programme embarqué qui fait l’usage intensif de périphériques externes et du hardware. Au contraire: on veut profiter des supers capacités du Raspberry Pi, et avoir les mêmes fonctionnalités que si on faisait tourner Gladys directement sur l’host comme la plupart des programmes font.

Essayer de limiter l’accès du container au Pi n’a pas de sens sens, et n’ajoute pas de sécurité…

Il faut penser le plus long terme possible, et à l’expérience de l’utilisateur en premier.

Qu’est-ce qui pose problème avec exposer le /dev? Gladys est là pour faire de la domotique, pas pour rester enfermer dans un container ^^

VonOx · Mai 8, 2020, 12:26

A chaque reboot tu peux avoir un mount different.

On peut juste proposer dans la doc ( avec des rules) et on reste sur dev en standard. Ou on peux l’intégrer dans le build de l’image.

D’un point de vue utilisateur c’est plus simple

L’un n’empêche pas l’autre.

Par contre je reste sur le partage complet de tout les périphériques ( oui y’a 2 sujets)

pierre-gilles · Mai 8, 2020, 2:54

Je pense que je n’ai rien compris ce que vous voulez faire alors

Ah oui ? je ne savais pas. Si tu as une parade à ça, je suis preneur ! La seule contrainte, c’est qu’il faut que ce soit fait de manière générique dans l’image, que ça fonctionne pour tout le monde, et que ça soit pérenne dans le temps.

VonOx · Mai 8, 2020, 2:59

J’ai éditer , c’est une grosse ânerie que j’ai sortie ( pour le nom du stick )

Le mount différent ça m’arrive quasi à chaque fois avec mon stick zwave

Une udev rule te permet de créer par exemple un alias de toute les clé zwave sur /dev/zwave