Bonjour à tous et désolé pour le silence mais j’avance…
Je comptais vous faire un point hier soir mais je n’ai pas pu.
Je vous ferai un debrief ce soir avec une nouvelle image de test qui contiendra les dernières modifs de Gladys (master) dont les scènes et une mise à jour du service.
3 « J'aime »
Idem , j’ai tout ça qui attend 
Au passage @Reno , tu prévois l’affichage du network ? ( un peu comme pour le zwave )
Désolé, je ne pourrai pas vous fournir une image avec le service, ce soir.
J’ai passé la soirée à essayer de la construire mais j’ai des erreurs de tests, de linter sur des fichiers qui n’ont pas bougé depuis plusieurs mois…?? Je mets en cause des évolutions du Linter et autres sur la branche master de Gladys, que j’ai rapatriées via un rebase.
Les experts de Git peuvent confirmer ?
Du coup la livraison sera un peu repoussée.
Par contre, je vous fais un petit topo des évolutions de cette version et du reste à faire.
Evolutions réalisées :
- Un onglet Settings qui permet de définir sur quel port USB est attaché le dongle Zigbee2mqtt
- Un onglet Setup avec Bouton Enable du service qui permet de lancer et stopper les containers Docker externes nécessaires au service. Un tableau permet d’afficher l’état des containers.
- Le service utilise sa propre configuration MQTT indépendante du service MQTT principal de Gladys.
Aujourd’hui le service ne sait faire que start et stop sur les containers, cela veut dire qu’il faut encore les créer à la main, au départ, en suivant le Tuto Zigbee2Mqtt. (Il y a juste une petite modification à apporter sur le nom du container mqtt qui doit obligatoirement s’appeler ‹ mqtt4z2m ›)
La prochaine étape du développement concerne la création automatique des containers depuis Gladys de façon à cacher les étapes de création à l’utilisateur.
Ensuite, je prévois d’ajouter un onglet ‹ Pairing › pour gérer l’appairage des devices que je trouve assez laborieux avec le Zigbee et qui nécessite aujourd’hui de regarder les logs du container Zigbee2Mqtt. On pourrait ainsi avoir une vision de l’état de l’appairage directement sous Gladys.
Je pense qu’il est envisageable de réaliser l’affichage réseau si on peut facilement récupérer l’existant du Zwave. Par contre, je ne vois pas bien quel est l’intérêt d’avoir une telle vue.
1 « J'aime »
Pourquoi utiliser sa propre configuration MQTT ?
Je pense que c’est complique pour l’utilisateur.
De plus, je travaille actuellement sur un moyen d’installer dynamiquement un broker sur le docker où est installé Gladys.
J’ai du mal m’exprimer, il était tard. 
Le service lance 2 containers : 1 broker mqtt et zigbee2mqtt.
Les 2 containers ont toujours été associés au service mais devaient être gérés à la main (voir mon tuto).
Du coup, c’est maintenant transparent pour l’utilisateur et tout est géré depuis Gladys. L’utilisateur n’a pas à rentrer dans la configuration du broker. Elle est définie dans le code et spécifique à Zigbee2mqtt.
Pour le Mqtt, jusqu’à présent, on définissait le broker mqtt dans le service mqtt de Gladys. J’avais donc proposé à @pierre-gilles de rajouter un moyen d’ajouter plusieurs broker dans le service mqtt. Il a préféré qu’on rende le broker spécifique à Zigbee2mqtt et indépendant.
C’est ce que j’ai fait.
Si tu veux gérer un broker indépendant via docker en dynamique depuis Gladys, tu pourras alors récupérer mon code et l’améliorer (je ne suis pas un développeur node 
).
J’espère avoir été plus clair.
1 « J'aime »
@Reno alors là je dis chapeau !! SUper boulot, il me tarde de pouvoir utiliser tous mes périphériques, car à l’instar de @julienL, une grande partie de mon patériel est du Xiaomi fonctionnant en Zigbee
Merci encore pour tout ce temps passé à permettre à des gens comme moi de profiter d’une expérience simple et efficace !! 
j’ai pas vraiment compris non plus l’histoire du mqtt indépendant, les topics étant de toute façon différents , je vois pas trop pourquoi ( pour ma part ) je lancerai un conteneur supplémentaire pour ça.
Du coup j’ai l’impression en voyant les captures , que je suis contraint de laisser le service gérer les conteneurs en question ( je me trompe peut être j’ai pas tester encore )
Sur un réseau complexe c’est plus simple de voir qui cause avec qui ( Device / Router / Coordinator )
Celle fourni de base est pas terrible, trop d’infos à mon sens. Le besoin c’est d’avoir les routes, le type de noeud et la qualité du signal.
C’est au format graphviz:
digraph G {
node[shape=record];
"0x00124b0018e1e975" [style="bold, filled", fillcolor="#e04e5d", fontcolor="#ffffff", label="{Coordinator|0x00124b0018e1e975 (0)|2020-05-01T19:17:26+02:00}"];
"0x00124b0018e1e975" -> "0x00124b001b7d88dc" [penwidth=0.5, weight=0, color="#994444", label="17"]
"0x00158d0002c14c65" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Salon|0x00158d0002c14c65 (40357)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-05-01T19:15:12+02:00}"];
"0x00158d0002c14c65" -> "0x00124b0018e1e975" [penwidth=1, weight=0, color="#994444", label="170"]
"0x00158d0002c14c65" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="96"]
"0x00158d0002c8ec72" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Cuisine|0x00158d0002c8ec72 (63279)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-05-01T19:03:17+02:00}"];
"0x00158d0002c8ec72" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="103"]
"0x00158d00040aaf16" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Porte Entrée|0x00158d00040aaf16 (62116)|Xiaomi Aqara door & window contact sensor (MCCGQ11LM)|2020-05-01T18:50:19+02:00}"];
"0x00158d00040aaf16" -> "0x00124b0018e1e975" [penwidth=1, weight=0, color="#994444", label="170"]
"0x00158d00040aaf16" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="56"]
"0x00124b001b7d88dc" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{Zigbee Router|0x00124b001b7d88dc (54718)|Custom devices (DiY) [CC2530 router](http://ptvo.info/cc2530-based-zigbee-coordinator-and-router-112/) (CC2530.ROUTER)|2020-05-01T19:16:36+02:00}"];
"0x00124b001b7d88dc" -> "0x00124b0018e1e975" [penwidth=2, weight=1, color="#009900", label="68 (routes: 54718)"]
"0x00158d0002c8d9ab" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Salle de bain|0x00158d0002c8d9ab (17528)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-05-01T19:01:29+02:00}"];
"0x00158d0002c8d9ab" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="57"]
"0x00158d0002c14900" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Chambre parentale|0x00158d0002c14900 (34881)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-05-01T18:57:19+02:00}"];
"0x00158d0002c14900" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="1"]
"0x00158d0002c8ccf0" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Chambre Sasha|0x00158d0002c8ccf0 (25360)|Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)|2020-05-01T19:14:33+02:00}"];
"0x00158d0002c8ccf0" -> "0x00124b0018e1e975" [penwidth=1, weight=0, color="#994444", label="170"]
"0x00158d0002c8ccf0" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="34"]
"0x00158d00042345ac" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Baie vitrée|0x00158d00042345ac (24351)|Xiaomi Aqara door & window contact sensor (MCCGQ11LM)|2020-05-01T19:02:18+02:00}"];
"0x00158d00042345ac" -> "0x00124b001b7d88dc" [penwidth=1, weight=0, color="#994444", label="86"]
}
Dans tout les cas la topology map n’est pas prioritaire 
MQTT peut être utilisé par différents services et le service MQTT dans Gladys ne permet de configurer qu’un seul broker. Il me semble que sa première utilisation fut pour connecter Gladys à un broker Owntracks.
J’avais proposé de faire un bouton pour ajouter plusieurs brokers dans le service MQTT mais @pierre-gilles préfère plutôt des instances indépendantes voire même cachées comme c’est maintenant le cas dans le service Zigbeee2mqtt.
L’intérêt que je vois également c’est qu’on devrait pouvoir faire du multi-instances Zigbeee2mqtt, en déployant le container zigbee2mqtt sur une autre machine et en le faisant pointer sur le broker du service. Ça permettrait de gérer plusieurs dongles assez facilement.
Nous avions eu une discussion sur ces sujets, un peu plus haut dans le fil :
Effectivement, lorsqu’on en sera là, ça sera top ! 
Surtout que j’ai plein d’autres idées de services : prises Meross (WiFi non compatible Tasmota), aspirateur Roborock, gestion SMS routeur 4G pour envoi d’alertes et pilotage à distance, …
Pour le multi broker MQTT embarqué, un dédié par service, je ne suis pas convaincu. Qu’on puisse configurer une url pour zigbee, une autre pour un autre service, je peux comprendre, mais de la à créer un broker embarqué par service j’ai plus de mal a cerner le truc. De mon point de vue, c’est un peu comme si on avait un BD par service. Après on va avoir des conflits de port, sachant que par défaut le port mqtt est 1883 et mqqts 8883… enfin ce n’est que mon avis.
1 « J'aime »
Je suis preneur de ça 
1 « J'aime »
C’est la tendance actuelle avec la conteneurisation. On sépare les services, comme ça si on n’en a plus besoin on supprime tous les containers associés et il n’y a plus de traces.
J’avais eu une discussion avec @pierre-gilles qui voulait aller dans ce sens car en plus un broker mqtt mosquitto prend très peu de place.
Il serait bien de définir rapidement le choix pour Gladys avant d’aller plus loin dans le développement.
Attendons le retour de @pierre-gilles.
Ça serait cool le Roborock…
Mais quand je vois le temps que je mets pour développer Zigbee2mqtt, ce n’est pas pour tout de suite. 
1 « J'aime »
A l’époque, le service MQTT ne lançait pas son propre broker, hors de ce que j’ai vu @AlexTrovato a l’air de mettre en place le lancement automatique du broker MQTT dans Gladys.
La priorité n°1, dans Gladys 4, c’est l’expérience utilisateur.
J’ai proposé originalement de mettre 2 brokers pour qu’il n’y ait pas « d’états bizarres » du style:
- Je connecte un broker MQTT local à l’intégration MQTT
- Je configure Zigbee2mqtt
- Je change quelque chose dans la configuration du broker MQTT du l’intégration MQTT pour un autre service
- Est-ce que le container Zigbee2mqtt a bien été relancé avec les informations du nouveau broker MQTT? Est-ce que l’utilisateur a été prévenu?
Si tu arrives à faire une intégration qui fonctionne bien sans bug bizarre avec le même broker, alors parfait tu peux utiliser le même broker 
Je veux juste éviter les bugs mystiques car là on couple 2 services qui ont tous les deux des états distants qu’il faut synchroniser.
Certes,@AlexTrovato tu peux me dire que le service Tasmota fait la même chose. Pour moi c’est différent, le service Zigbee2mqtt c’est un container séparé de Gladys, et il faut arriver à synchroniser tout ce beau monde !
Avec l’arrivée de la configuration automatique du broker MQTT, je suis ok pour utiliser le même broker, si tout les cas sont bien gérés.
Bonsoir à tous,
Ça y est, vous pouvez tester la dernière image Gladys-Zigbee2Mqtt !
Celle-ci permet de tester les scènes mais ne permet pas de choisir le français comme langue. De toute façon, les textes associés au service n’ont pas encore été traduits.
Pour lancer l’image sur votre RPi, j’ai mis à jour le Tuto Zigbee2mqtt sur Github :
En condensé,
- Récupérez les scripts (se terminant par .sh) sur votre RPi.
wget https://raw.githubusercontent.com/R6n0/Tuto_Zigbee2mqtt_avec_Gladys/master/*.sh
Remplacez * par les noms des 4 fichiers, un à un, la wildcard ne fonctionne pas sur http.
- Les rendre exécutables :
chmod +x *.sh
- Lancer le script principal qui appelle les autres :
./gladys-zigbee2mqtt_run.sh
Si vous utilisiez déjà l’ancienne image, vous risquez obtenir une erreur au départ car docker essaie de créer le réseau pour les containers et celui-ci existe déjà.
Cette erreur n’est pas un problème. C’est juste un avertissement et tout doit fonctionner quand même
J’ai été assez étonné, en allant sur mon compte Docker Hub, de voir que l’image avait été téléchargée plus de 50k fois… J’ai du mal à y croire. Ils doivent avoir un bug dans leur comptabilisation, non ?
Ou alors, c’est le succès de Gladys…
Bons tests et j’attends avec impatience vos retours…
1 « J'aime »
Merci pour ton implication @Reno! Beau travail 
J’ai vraiment hâte de voir ça arriver dans Gladys Beta.
Qu’est-ce qu’il manque à l’intégration pour qu’elle puisse atterir dans la beta?
C’est pas vraiment la préco pour le zigbee2mqtt , pour ça il y’a les routers
Hello,
Je voulais tester la dernière image mais je rencontre un soucis lors de la sélection du port USB du dongle, aucun port ne remonte dans la liste (même après plusieurs refresh) !
Il remontait bien par contre dans les logs de l’exécution du script zigbee2mqtt_run.sh.
Logs
$ ./zigbee2mqtt_run.sh
Recherche de linterface du dongle CC2531
/dev/ttyACM0 - CC2531
Configuration de Zigbee2mqtt
Lancement du container Zigbee2mqtt
73d2e9b6ebb2b4fb7ef534a7ffcb5dbb91262cfa3a7c02a243a0bb8c5a3ea081
zigbee2mqtt
Une idée d’où ça pourrait venir ?
Sinon j’ai remarqué une petite coquille dans le tuto, la description de la méthode manuelle ne reflète pas les dernières modifications. En particulier, le container docker mqtt est lancé avec le nom mqtt-broker au lieu de mqtt4z2m, ça peut poser quelques soucis 
Pour moi, il manquerai juste la création des containers via Gladys si ils n’existent pas.
Je suis dessus et ça ne devrait pas être un gros travail.
En plus, je viens de découvrir ce matin, la PR de @AlexTrovato sur le mqtt local via un container où il fait la même chose que moi.
Je regarde en détail pour rendre le tout cohérent.
Il faut que je rajoute également quelques tests auto que je n’ai pas fait (pas l’habitude…).
Ensuite, on pourra merger et on ouvrira des PRs pour chaque amélioration. Il me tarde…
Oui, on fait cela lorsqu’on veut tout mailler en Zigbee donc en sans fil.
Avec Gladys, je vois l’avantage de profiter du réseau local (filaire) pour distribuer les données entre les services zigbee2mqtt, ça sera plus fiable. En mode réseau maillé sans fil Zigbee, si un dongle Zigbee tombe en carafe et qu’il sert de routeur, on perd tout une partie du réseau qui passe par ce routeur pour accéder au serveur. Dans notre cas, seuls les devices associés au dongle sont coupés, tout le reste remonte encore vers Gladys.
Et en plus, ça permet de relier entre eux des réseaux Zigbee qui sont éloignés (cabane de jardin, local piscine, par exemple).
Oui, je galère sur ce sujet depuis ce WE…
Pour le dév, je fais tourner Gladys directement sur RPi, sans Docker.
Lorsque j’ai ajouté la gestion de l’usb, j’ai réutilisé ce qui était fait dans le service Z-wave mais ayant également un dongle zwave, je me suis rendu compte que l’affichage utilisé ne permettait pas de distinguer facilement qui était le dongle Z2M et qui était le Zwave.
Dans l’affichage, j’ai donc rajouté l’info fabricant qui remonte du device USB sous linux.
Lorsqu’on passe sous Docker, le container récupère le ‹ path › du dongle (/dev/ttyACM0 par ex) mais perd toutes les autres infos, ce qui génère le problème d’affichage que tu rencontres.
Pour éviter cela, j’ai ajouté l’option -v /run/udev:/run/udev au lancement du container Gladys.
Il faut donc vérifier que tu as bien cette option dans Gladys_run.sh.
Peux-tu également m’indiquer sous quelle distrib tu tournes ? J’ai testé uniquement Raspbian Buster.