Bonsoir,
Jai un soucis suite a une maj de mon nas synology ds920+ en 7.2
Jai l’impression que peut importe que je mette ou retire le dongle sur le port usb, gladys ne me retourne que ça:
Jai tjrs cette liste la =>
Alors que je retrouve bien le dongle avec un lsusb =>
A quoi correspondent les dev* par rapport a mon lsusb?
Un rapport avec ça peut être ?
Y’a plusieurs propositions de résolution là bas, mais je ne peux pas t’en dire plus, je n’ai plus de Synology 
Depuis la version 7 de DSM, les ports usb ont été bridé.
Jai bien entendu remis les drivers pour by pass cette problématique.
Mon zwave est ok et ma sonoff est reconnu, pas certain que le soucis etait sur le syno.
Jai fait un restart du container de gladys et now je vois bien le bon port :
Qui correspond bien a mon dongle :
Le seul soucis maintenant cest que je me tape encore une erreur SRSP - SYS
error 2023-09-19 07:14:34: Error: Failed to connect to the adapter (Error: SRSP - SYS - ping after 6000ms)
Jai eu beau mettre mon dongle sonoff a jour rien ny fait …
@spenceur J’ai vu ce sujet mais j’ai pas plus d’idées que ce qui a déjà été dis 
Tu as posté un message côté forum Zigbee2mqtt ? C’est plus un soucis de leur côté pour le coup…
Leur forum: Koenkk/zigbee2mqtt · Discussions · GitHub
Leur Discord: zigbee2mqtt
En relisant le sujet, il faut fouiller côté Synology aussi, ça a l’air d’être une sacré galère cette version de Synology. A voir sur les forums spécialisé Synology ?
J’ai trouvé cette vidéo aussi:
Aucune idée si ça peut t’aider ^^
Et juste par hasard, tu as sélectionné le bon dongle dans la liste côté Gladys ? Si ton dongle c’est le Sonoff P tu as sélectionné Sonoff P, et si c’est le Sonoff E tu as sélectionné le Sonoff E ?
Cest bien le « p » et jai bien sélectionné le dongle 
Côté syno je pense que je suis tout bon car le dongle est reconnus et mon zwave est ok.
Et le device est reconnus sur le driver cp210x :
Jai posté sur le github de Koenkk :
Mon anglais est pas parfait ^^’
Je ne comprend pas par contre ce qui rst fait dans gladys entre les container.
Dans gladys je sélectionne ttyusb0 et pour autant dans la config z2m jai ttyacm0 de mis.
Jai try de le mettre a la mano pas de cahngement 
De mémoire (attention si je dis une connerie) chez moi aussi il y a une différence entre le dashboard z2m et Gladys. Un jour j’ai voulu mettre tout pareil… Et j’ai tout planté 
Je confirme :
yep je suppose que le volume doit être monté sur l’autre container.
J’ai bien remis tout d’équerre mais tjrs négatif
edit :
@pierre-gilles comment est fait le lien entre le port sélectionné et celui monté ?
Bon j’ai pu fix le soucis mais en bidouillant l’image via portainer
J’ai modifier le host en /dev/ttyUSB0 qui est bind vers /dev/ttyACM0.
Je ne sais pas pourquoi cela ne change pas en sélectionnant via gladys mais ça semble ok now.
Tant mieux si ça marche ! 
Effectivement, je suis allé voir le code, sauf si je n’ai pas compris le fonctionnement de cette partie, le mapping entre le port hôte et le port dans le container n’est fait que lorsque le container est configuré la première fois :
Pour que ce changement fasse effet, il faudrait que l’intégration Zigbee soit coupée/puis relancée je pense…
(je dis ça en lisant le code en 10 secondes, je n’ai pas investigué plus que ça)
Est-ce que tu peux créer une issue Github pour qu’on vérifie ce comportement ?
Dans le container gladys-z2m-zigbee2mqtt, le port du dongle est toujours /dev/ttyACM0 (c’était pour faciliter la configuration).
Vous trouverez toujours dans /var/lib/gladysassistant/zigbee2mqtt/z2m/configuration.yaml
serial:
port: /dev/ttyACM0
Le mapping entre le port hôte (le vrai) et celui du container se fait effectivement à la création du container (ou à la réactivation s’il y a changement).
"Devices": [
{
"PathOnHost": "/dev/ttyUSB0",
"PathInContainer": "/dev/ttyACM0",
"CgroupPermissions": "rwm"
}
],
J’ai créé une issue, je peux jeter un coup d’oeil.
Est-ce que c’est le moment de revoir ce comportement ? Je veux dire mettre dans la configuration le bon port et faire un mapping direct ?
J’ai peur de l’impact sur les installations existantes
Aucune idée menfon si je comprend bien le soucis etait bien côté gladys… je vais mettre un message sur le repo de Koenkk que le soucis est sur gladys qui nest pas 100% fonctionnelle avec z2m (en cours de rodage)
Non je pense qu’il faut rester comme actuellement
Le seul souci actuellement c’est qu’apparement (à vérifier), le container Zigbee2mqtt n’est pas relancé en cas de changement du port USB
J’ai commencé à regarder mais c’est plus compliqué que prévu.
Je pensais ajouter à cette ligne (durant la sauvegarde de la configuration) un check + déploiement si nécessaire.
Mais la fonction checkForContainerUpdates ne vérifie pas la configuration mais uniquement les versions disponibles.
Il faut donc :
Voilà où j’en suis. Je peux continuer mais pas d’engagement possible à court terme
Ok, je me suis renseigné aussi de mon côté, en fait c’est plutôt la fonction installZ2MContainer qui est défaillante
Lorsque que l’utilisateur met à jour sa configuration, l’appel API qui est fait c’est le /setup, qui appelle la fonction setup.
Cette fonction met à jour la configuration USB, puis appel le init qui appelle le installZ2MContainer.
Sauf que installZ2MContainer n’a pas de code pour gérer le cas d’un container Zigbee2mqtt existant.
Je pense que dans cette fonction installZ2MContainer, il faudrait:
if (dockerContainers.length > 0) { pour traiter le cas ou le container existe bienHostConfig.Devices[0].PathOnHost pour vérifier qu’il est bien identique au path USBT’en penses quoi ?
{
« name »: « gladys-z2m-zigbee2mqtt »,
« Image »: « koenkk/zigbee2mqtt:latest »,
Juste une petite interrogation : Est-ce qu’il ne faudrait pas là aussi fixer une image vu qu’il ne sembles pas y avoir de problèmes actuellement avec celle-ci ?
je commence a comprendre comment est géré dans le code de Gladys la partie container je passe du mode quiche tout court à quiche avec des lardons 