Non non t’inquiète pas tes PR sont ok. 
Pour faire simple il faut refaire une PR en reprenant le code de Reno + le tiens.
@pierre-gilles et @cicoub13 , c’était hier soir mais je ne me rappel plus , on a dit qu’on ferai une branche sur le repo principal pour faciliter les contributions ?
J’avoue que ça serait plus simple, compréhensible et moins dépendant d’une tiers-personne.
J’ai pas mal hésité à faire une PR sur le repo de Reno, car je ne savais pas si c’était le bon endroit. En tout cas, je le redis, beau boulot @Reno !!
Avant il faut valider que sur Github lorsque nous sommes contributeur, il n’y a pas moyen de pousser les PR sur la branche master. (il me semble que c’est ce qu’on s’était dis hier).
Je ne pense pas qu’on fasse une branche mais plutot chacun peut aider sur une branche, par contre pas possible de pousser sur master 
Exact, le fameux ‹ repo pourri ›
Je pense que c’est ce que VonOx voulait dire.
De mon côté voilà ce que j’imaginais :
Pour moi ça a clairement du sens et facilitera grandement les contribution sur un service en développement.
Oui c’est ce qu’on s’est dit hier lors du call developer , mais on doit tester ça sur un repo pour être sur que personne puisse merge sur master ( car on ne le souhaite pas )
J’espère bien, sinon j’imagine même pas l’anarchie 
J’ai un peu de temps pour aider sur cette feature et pour finaliser le super travail de @Reno
Je vais commencer par rebase, merge tes 2 PR @lmilcent et pousser une PR sur Gladys + nouvelle image.
Ensuite, il faut que je liste les dernières choses à faire (tests, bugs, …) et que je m’y mette
Pendant ce temps, il faudrait tester le fonctionnement que vous décrivez sur un repo oui.
Si jamais tu as besoin d’aide sur quelque chose hésites pas (test, bugsn …)
Idem, j’ai des périphériques Zigbee et je connais le NodeJS (+ docker), je peux t’aider à valider une partie dans mon environnement par exemple.
Merci et bon courage en tout cas 
A vous 4, l’intégration Zigbee2mqtt sera fini ce soir!!
Les gars je comprends rien a tout ce langage technique… mais ça bouge, c’ est génial !!
Bonjour à tous et bonne année !
Je vois que je me reconnecte enfin, au bon moment…
Désolé à tous mais j’ai dû me déconnecter très brusquement du projet et n’ai eu aucun moment pour m’y remettre depuis bien 2 mois…
Je suis tout à fait partant pour travailler à plusieurs sur le sujet et j’avais d’ailleurs fait la demande plusieurs fois, par le passé, vu mon temps disponible limité.
Par contre, je veux bien continuer à donner mon avis sur les modifications car les choix que j’avais pris, notamment à cause de l’utilisation de Docker, peuvent être difficile à comprendre.
Je m’explique :
Merci @lmilcent pour tes PRs mais je ne suis pas sûr que celles-ci résolvent le pb pour tous.
Dans le container Zigbee2mqtt, il est tout à fait normal que le device soit toujours le même à l’intérieur du container. C’est juste un lien vers le device sur la machine hôte qui est passé au container à son lancement et ça simplifie les choses car la config interne du container est tjs la même pour tous.
En fait, c’est la modification du champ PathOnHost dans le fichier /src/server/services/zigbee2mqtt/docker/zigbee2mqtt-container.json, qui passe le device au container mais il s’appelle tjs /dev/ttyACM0dans le container. (J’ai un dongle sur /dev/ttyUSB0 chez moi et ça fonctionne bien)
C’est fait ici dans le code :
Du coup, il me semble que ton problème est un cas particulier qu’il faudrait étudier à part.
Donnez-moi votre avis sur le sujet.
Aussi, j’avais eu un soucis sur ma PR sur le repo Gladys et je devais la recréer lorsque j’ai « disparu »…
Touts les modifs Zigbee2Mqtt pourraient être regroupées en 1 commit mais il faudrait des commits séparés pour quelques modifs que j’ai apportées sur le core, afin de faciliter la validation par @pierre-gilles.
De mémoire, ça portait sur :
stop pour la gestion des containers Docker (Add Stop Docker container function · R6n0/Gladys@c4cb601 · GitHub)Welcome back @Reno
J’avais pas pigé ça du tout , peut importe le port source, tu bind su /tty/ACM0 dans le conteneur z2m.
Le problème avec ça c’est que pour changer ça , il faut recréé le conteneur.
J’ai bien compris ?
Bon retour parmi nous
J’ai suspecté que tu avais fait ça justement, garder le même chemin de périphérique dans le conteneur mais le binder au chemin réel sur l’OS.
Mais ce cas risque de poser un problème de compatibilité si un utilisateur souhaite finalement cloner le repo Gladys et le lancer sans utiliser Docker.
En tout cas de mon côté, le conteneur était lancé avec ttyACM0 côté OS ce qui évidemment provoquait une erreur au lancement du contenur puisque l’équipement n’existait pas.
Je te pose la question inverse : pourquoi ne pas garder le même chemin d’accès que le « réel » ?
En soit, si toute la configuration est dynamique (comme je le propose avec ma PR), ça devrait pas poser de problème.
Oui, tu as bien compris.
Dans le cas où on modifie le device dans le fichier de conf du container, il faudra également redémarrer le container pour le relire, il me semble.
J’ai fait ce choix :
Ok ça me va , ça fait sens 
Ça, du coup, c’est donc un bug du module car le container Z2M ne devrait pas se lancer si on n’a pas choisi de device ou alors, c’est le nom du device qui ne s’est pas écrit correctement dans la DB.
Ça demandait moins de modif de fichier (uniquement le fichier de configuration du container et pas celui de Z2M). Après ça devrait marcher aussi mais je ne comprends pas quelque chose : si tu as /dev/ttyACM0 dans ta variable dongle côté OS, lorsque tu l’écris dans le container Z2M, elle n’est tjs pas bonne ,non ?
Lors de mon dernier test, j’avais :
ttyUSB0
Et le conteneur z2m refusait de se lancer. Avec le modifs que je proposais, c’était nikel.
Mais je vais refaire le test à nouveau, avec un nouveau conteneur et une nouvelle DB Gladys pour vérifier. Je te dis ça dans quelques minutes.
Cool. Ça permettra d’être sûr car aucun autre utilisateur n’a eu ce soucis.
Quel matériel/OS utilises-tu ?