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
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’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.
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
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 :
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 :
pour éviter d’avoir des config différentes de ce container Z2M qui serait complexe à débugger à distance,
Pour éviter de partager tous les devices avec le container Z2M (que l’on ne maîtrise pas), mais seulement le dongle Z2M.
Ç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 ?