Salut
Je viens de perdre 2h suite à la mise à jour de zwave-js-ui vers la version 8.2.0. Je suis redescendu vers la 8.1.0 et c’était à nouveau fonctionnel. Puis j’ai trouvé la solution:
En espérant que cela évitera à d’autres de galérer. L’avantage, je comprends mieux comment changer de version maintenant.
Tcho
Antoine
Salut,
Merci pour l’info. Tu confirmes être sur Rpi ? Car apparemment le souci est identifié sur cette plateforme uniquement.
Oui un pi 3+
Antoine
Hello,
Même soucis sous un docker sur un pi4…
Plus de gestion du chauffage 
Heureusement j’ai pas tout les œufs dans le même panier !
J’ai remonté un container sur un docker sur une machine x86, et ça refonctionne…
J’avais pas trouvé l’erreur que @Tonio16 cite.
Hello,
Tu veux dire que le container Docker dont le host est avec une version debian buster est aussi impacté? Sans doute qu’il faut appliquer la solution sur l’host alors (installer la libseccomp2 sur l’host) Je croyais que grâce à Docker on était justement à l’abris de ce genre de déconvenue…
Je n’ai pas eu le problème car mon host est Debian 11 bullseye, et à priori le pb n’est que sur debian 10 buster.
Hello,
c’est ce que je pensais aussi
par contre ce que je ne comprends pas, et tu viens de mettre la puce à l’oreille …
mon pi4 qui était ma chaîne complète mqtt, zigbee, zwave
→ HypriotOS 5.10.63-v7l+ (2021-10-06)
mon docker où j’ai redéployer mon container en mode « secours - rapide » avant que le waf ne s’en aperçoive… 
et que je me prenne un taquet !
→ Debian 5.10.106-1 (2022-03-17) (heu je viens faire un apt update et je suis en 11)
EDIT: pour bien faire, il faudrait que je repasse ma clé sur mon pi et reteste mais bof bof
Sous docker j’ai eu aucun soucis depuis la mise à jour !
Je suis sur VM debian 11 sous proxmox avec mon docker dessus
Le seul truc c’est que j’ai zwavejsUI et zigbee2mqtt et j’ai au redémarrage de la VM par exemple des conflits de port ttyACM0 et ttyACM1
Ces deux port changes parfois un coup pour le zigbee un coup pour le zwave c’est chiant ça d’autant plus que je ne sais pas fixer les ports directement sur debian
Au lieu d’utiliser /dev/ttyACM*, utilise les liens symboliques présents dans /dev/serial/by-id/ :
/dev/serial/by-id/usb-0658_0200-if00 -> ../../ttyACM0
/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0018E20DB0-if00 -> ../../ttyACM1
Ou alors crée des udev rules, par exemple chez moi dans /etc/udev/rules.d/99-usb-devs.rules :
SUBSYSTEM=="tty",ATTRS{idVendor}=="0451",ATTRS{idProduct}=="16a8",GROUP="dialout",SYMLINK+="ttyZigbee"
SUBSYSTEM=="tty",ATTRS{idVendor}=="0658",ATTRS{idProduct}=="0200",GROUP="dialout",SYMLINK+="ttyZwave"
Et du coup j’ai ces 2 devices en plus dans /dev :
/dev/ttyZigbee -> ttyACM1
/dev/ttyZwave -> ttyACM0
Pour récupérer les idVendor et idProduct, tu peux faire un lsusb sur ton host docker :
bad@docker:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 006: ID 0451:16a8 Texas Instruments, Inc.
Bus 001 Device 004: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 003: ID 0658:0200 Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090) - UZB
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bad
Alors au niveau de mon docker compose je suis bien avec ce type de déclaration
/dev/serial/by-id/usb-0658_0200-if00 -> ../../ttyACM0
/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0018E20DB0-if00 -> ../../ttyACM1
mais je vais tester ceci au niveau de debian sur ma VM
J’ai oublié de faire un retour à @Bad
Cela semble bien fonctionner avec ces règles en tout cas j’ai pas relevé de soucis de démarrage mais d’un autre côté je ne redémarre pas tout les jours non plus 
Merci du coup de pouce
Je pense que ceci est faire de manière systématique quand on a les deux protocoles sur la même machine
Bonjour à tous
J’ai un doute du coup. Parle t-on bien du plugin Jeedom ZwaveJS dispo en beta ? ou d’un autre plugin ?
Je m’aprettais à essayer de connecter ma clé dessus mais je ne retrouve aucune info dans les paramètres du plugin pour avoir accès à l’interface web Zwave-JS-UI…
Je suis du coup confu
Voici à quoi resemble l’interface ZWAVE-JS-UI dans HA qui est dispo sur une page web en fait. De la même façon que zigbee2mqtt.
Merci à vous
Regarde la date des premiers posts et comprendras que ce n’est pas le plugin beta de jeedom.
Antoine
Oui en creusant je me rends compte que le projet global ZWAVE-JS-UI utilise plusieurs librairies dont ZWAVE-JS pour la partir pure zwave. Le plugin jeedom ne doit intégrer que celle ci. L’intégration de l’envoi vers MQTT est du pur jeedom à partir du plugin MQTT manager.
Du coup la plus simple pour migrer sur Jeedom de openzwave vers Zwave-js-ui ?
Je remonte ma clé dans zwave-js-ui ? Je synchroinise. Ensuite Avec quel plugin mqtt jeedom on peut récupérer tous les équipements ? est ce automatique ?
Tu peux reformuler, j’ai pas suivi ce que tu voulais.
Antoine
La solution la plus simple pour récupérer ses devices sous jeedom est du coup de suivre ce tuto je suppose ?
Si tu les as sous HA, cela passe pas déjà par zsavejs2mqtt, non? Il suffit alors de t’abonner à lui.
Antoine
pour l’instant j’ai rien dans HA, tout tourne sous jeedom avec le plugin officiel open-zwave.
j’aurais souhaité éviter de repasser par la case recrééer les équipements zwave à la main sur jMQTT (un peu comme le plugin zwavejs de jeedom le propose avec mqtt manager) mais ça ne semble pas possible.
Du coup on va tout faire à la main 
EDIT : Autre question, si on décide de faire un retour arrière après avoir synchro la clé avec ZJSUI, est ce que la clé peut redémarer sans problème sous le plugin openzwave jeedom ?
Ou obliger de restaurer une conf sur la clé ?
Salut @loic69,
Pour répondre à ta dernière question il n’y a rien à synchroniser.
Quand tu auras stoppé le plugin Zwave, démarré Zwave-JS (et donc Zwave-UI) tu pourras configurer l’emplacement de la clefs et il ira lire les modules que la clefs à puis interrogera les modules, etc … Le premier coup ça peut prendre un petit moment quand-même.
Quand ça commence à être bon depuis Zwave-UI tu peux jouer avec jMQTT (maintenant il y a plein de template tu iras bien plus vite que quand on a commencé l’aventure).
Et si tu ne fini pas ce soir, ce qui est bien possible suivant le nombre de module que tu as, tu stoppe Zwave-JS puis démarre le Daemon Zwave et … C’est reparti.
Tu peux faire cette bascule autant que tu souhaites le temps que tout soit fini dans Zwave-JS (Zwave-UI).
Good ? 
Top merci pour ta réponse très complète.
Oui c’est une bonne idée du coup.
Au delta près que je serais sur une VM différente donc à chaque fois faut que j’aille changer la clé de VM dans proxmox. Mais c’est un détail
Allez je part à l’aventure de jMQTT. Pas sur que je me lance ce soir car j’ai pas envie d’y passer la nuit. J’ai précisément 29 devices dont 27 fibaro (classique quoi) et 2 modules exotiques comment la clé zwave NICE bidi qui permet de piloter mon portail ainsi qu’un thermostat zwave Secure
Une fois que j’aurais tout récupérer dans jMQTT, il faut que je fasse mes correspondances avec le nouvel outil jeedom de la 4.3 pour ne pas perdre mes configs diverses, scénarios,…
Je suis dans la même configuration que toi puisque dans le tuto je disais de faire une autre VM afin d’isoler tout ça de Jeedom.
Donc oui en effet il faudra jouer avec stop des VM / attribuer la clef à la bonne VM / start VM
En effet tes modules exotiques ne doivent pas avoir de template, comme ça tu pourras les transmettre aux développeurs
avec plaisir bien sur.
je vous tiens au courant de mes avancées
