L’usage courant dans mon entourage pour auto-alimenté est « alimenté par son port hôte ».
Je n’utilise pas ces termes et leur préfère actif et passif qui lèvent toute ambiguïté.
Dans tous les cas, ce n’est pas le problème: j’y avais déjà pensé et j’ai fait l’essai avec une alim, mêmes symptômes strictement.
Ma précision sur le mode Auto non fonctionnel vaut aussi avec le hub en actif.
Au passage, merci à vous trois pour votre temps 
PS : c’est exactement le modèle de ton lien que j’utilise.
As-tu testé les ports USB de ton RPI ?
As-tu essayé avec un autre RPI?
Tester les ports => Oui
Un autre Pi => Non. Et je ne le ferais pas.
On part très loin sur les histoires de responsabilité du hub / pas du hub alors que la question est : pourquoi ce plugin ne garde pas la configuration qu’on lui donne et ne retente pas la connexion ? Je n’ai pas le message habituel qu’on voit sur les plugins qui arrêtent d’essayer avec 3 essais. Ce plugin ne retente même pas puisqu’il perds sa configuration.
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 
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.
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.
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 ?
