On te propose des pistes, après, tu en fais ce que tu veux.
J’ai eu un problème identique il y a quelques temps et j’ai fait plein de manip pour corriger le problème (relance de dépendances, fixation du port z-wave, changement de port USB, …).
Une chose est sûre, le problème ne venait pas du plugin. Il a des défauts mais pas celui de changer les ports sur lequel la clé est installée.
Un classique.
Déconnexion à cause du jeu dans le prise USB (le plus souvent avec une prise USB3)
Le problème : le plugin se base sur un lien USB qui malheureusement change de nom en s’incrémentant à chaque nouvelle connexion d’un périphérique USB ttyUSB0 ttyUSB1 ttyUSB2… C’est ainsi que ta clé Z-Wave change de nom en passant de ttyUSB1 à ttyUSB2. En pointant sur un mauvais nom, le plugin ne fonctionne plus, tu dois rechanger le port dans la page config du plugin.
Le plugin n’est pas assez robuste. Le test du singe est un échec : débrancher le dongle USB et puis le rebrancher, bah ça passe inaperçu comme tu l’as constaté sauf que le Z-Wavec ne repart pas et reste en rade !!!
Oui, c’est par ici.
Pas besoin d’acheter un nouveau hub USB !
Ma question : Combien de gens vont encore tomber dans ce nid de poule ?
Auquel il faut ajouter les frais de port.
Ceci étant et pour être honnête, je ne l’avais effectivement pas vu mais je suis content du mien même s’il est beaucoup plus cher.
Il le fait. Quel élément avez-vous pour penser le contraire ?
J’avais la même hypothèse d’où ma question précédente mais
Je ne peux que valider ta réponse et les conseils du post que tu as cité plus haut
plus aucun soucis depuis ta réponse de février 2020 grâce à toi 
fallait y penser, créer un lien symbolique pour du périphérique 
2 « J'aime »
Oui, celui de la page config, le plugin ne change pas le nom du port !
Si on pouvait directement écrire le chemin unique /dev/serial/by-id/usb-0658_0200-if00 comme nom de port pour la clé Z-Wave Aeotec Gen 5 dans le plugin, ce serait bien plus simple. Mais il faudrait encore que tous les plugins fassent pareil, sinon il y aurait toujours le risque qu’un plugin utilise par malchance LE lien /dev/ttyUSBx qui pointe aussi sur la clé Z-Wave : 2 plugins utilisant finalement la même clé USB = crash assuré !
Merci
Oui merci, je suis au courant 
Je l’écris d’ailleurs juste au-dessus, j’ai l’impression que tu n’as pas lu l’ensemble du sujet.
ma compréhension de la réponse de @monsieurpoutounours est que la clé reste sur le même tty, 01 par exemple.
Si c’est bien le cas alors ce n’est pas le cas que tu décris
C’était précisément ma question du 3ème post :
Et je répète sa réponse parce que apparemment ce n’est pas clair :
D’où mon intervention sur ton message.
Sinon pourquoi serais-je intervenu ?
Bref, il faut que @monsieurpoutounours éclaircisse la situation.
1 « J'aime »
Donc, je le répète de la façon la plus explicite possible :
La clé Z-Wave est toujours attachée au même pseudo-périphérique : /dev/ttyACM0
Les débranchements / rebranchements ne changent pas le périphérique vu par Jeedom autant que dans l’OS (confirmé avec un syslog / dmesg).
Je maintiens donc que, si le hub USB déclenche la panne, il ne l’explique pas, car le vrai soucis c’est que ce plugin ne se reconnecte pas à la clé Z-Wave, alors même qu’elle porte toujours la même adresse.
Pire, le plugin perds sa configuration du port.
Je constate aussi que certaines personnes ne lisent pas l’intégralité des messages
Je répète ma question: quel élément vous fait penser cela ?
Car ceci est impossible, à moins de sauver manuellement la configuration avec le port vide: si le port n’apparaît pas dans la liste déroulante c’est qu’il n’est plus disponible mais il est toujours sauvé dans la config du plug-in, la configuration n’est pas perdue.
Si vous sauvez la config à ce moment avec un port vide, alors il disparaît de la config mais cela ne se fait pas tout seul.
Si le port revient alors il sera de nouveau visible dans la liste déroulante et le démon redémarrera.
Mais la base du problème est que la clé n’est plus disponible au niveau de l’os et le plug-in n’y peut rien.
@Mips C’est l’expression « port qui saute » qui n’est pas clair 
Si /dev/ttyACM0 correspond toujours à la clé Z-Wave, alors c’est déjà un bon point.
Là, c’est une faiblesse du plugin.
Pour moi, s’il y a la moindre déconnexion USB, c’est juste mort pour le Z-Wave ! Et il faut redémarrer le daemon.
Si vous sauvez la config à ce moment avec un port vide, alors il disparaît de la config mais cela ne se fait pas tout seul.
Ben si, justement ! Le port disparaît tout seul.
Port qui saute = le champ est vide dans la configuration du plugin. Pour autant, le port existe dans la liste au même moment, contredisant ceci :
Si le port revient alors il sera de nouveau visible dans la liste déroulante et le démon redémarrera.
dmesg montre que le port, au pire, ne disparaît que moins d’une seconde côté OS.
Je maintiens que ça ressemble à un bug du plugin.
Pour moi, s’il y a la moindre déconnexion USB, c’est juste mort pour le Z-Wave ! Et il faut redémarrer le daemon.
C’est faux. Si je fait l’essai à la main de déconnexion / reconnexion, la plupart du temps l’OS comme le plugin le supportent.
L’OS oui, mais le réseau Z-Wave, il redémarre correctement tout seul chez toi ?
Oui, je n’ai jamais besoin de redémarrer quoi que ce soit.
J’ai testé pour rire avec zwavejs2mqtt en débranchant la clef pendant 1mn et en la rebranchant. Vu du logiciel tout va bien mais les ordres ne passent plus et il y a des erreurs de communication dans les logs.
J’ai du restart la VM. Sûrement qu’un restart du service zwavejs2mqtt auraient suffit.
1 « J'aime »
Très bien, du coup, en quoi le champ vide dans la configuration du plugin te pose problème si ta clé ne change pas de nom de port et si ton réseau Z-Wave redémarre tout seul si besoin et ne reste pas en rade ?
Parce que quand le champ est vide, le service est KO. Reconfigurer le port fait repartir le service, sans nécessiter de le redémarrer.
Si je fait l’essai manuellement de débrancher / rebrancher, tout repart tout seul.
Si je farfouille dans l’armoire et qu’il y a (je le suppose) une micro déconnexion / reconnexion, service KO + champ port vide, pourtant le port existe toujours. J’en déduis que ces symptômes n’apparaissent que si la déco/reco est très rapide.
Je vais quand même tenter la méthode du lien symbolique, peut être que ça suffira à feinter le plugin.
Ok, pas besoin de le redémarrer, mais il faut une intervention humaine pour corriger le port sinon le réseau Z-Wave reste KO.
Dans ce que tu dis, c’est la micro déconnexion qui pose souci. Est-ce qu’elle se voit avec la commande dmesg ? Lorsque le champ est vide, la clé est-elle toujours bien vu par le système linux ?
En parallèle, je te conseille de vérifier tes câbles/ports USB pour limiter les risques de déconnexion.
Euh, quand tu remets le bon port dans la liste déroulante, tu cliques bien sur “sauvegarder” ensuite ?
De mémoire, ce click sur “sauvegarder” relance le demon et donc redémarre bien le service si je ne me trompe pas…
J’ai moi aussi eu quelques soucis de changements de port, lors de coupure de courant (c’était bien avant que j’ajoute un onduleur, etc).
J’ai terminé d’autres configs plus urgentes, du coup je vais pouvoir enfin m’attaquer à ce tuto de @Domatizer 
1 « J'aime »
Ce n’était pas explicite mais oui, évidemment, je clique pour sauvegarder.
Sans aucune intervention ni changement, plus aucun problème depuis des mois, donc ça reste un mystère …