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.
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 ?
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.
J’ai le même problème !
ca commence par un champ vide et un message le port n’est pas sélectionné:
et dans ma config, une fois sur deux le port change entre ttyACM2 et ttyACM1 que je dois selectionner manuellement avec un restart derrière !
quoi faire ?? …
