Salut
Pourquoi déconseilles tu le Auto.
J’ai pas mal d’instabilités aussi et j’ai essayé de fixer le port mais il change parfois créant encore plus d’instabilité. J’ai donc remis à Auto.
Content d’avoir pu aider, comme quoi ce n’est pas toujours la faute d’un module😅. Avoir une clé/dongle en secours est un impératif sinon le risque c’est du jour au lendemain plus rien!
Si c’est stable il faudra du coup en racheter une autre en route de secours.
Cela est dit dans bcp de posts sur le forum. c’est surtout dans le cas où il n’y a pas qu’un seul périphérique usb sur le jeedom. Certains periph perturbe la config usb et lors de redémarrage de jeedom le dongle zwave peut ne plus être détecté en auto et donc le réseau ne démarre pas. Fixer le port est alors plus fiable.
1 « J'aime »
si ton port change c’est donc la raison de ton instabilité.
Ce post est a lire dans ce cas
Nouveau retour suite aux manipulations d’hier
J’ai tjs le même problème
Par rapport aux logs transmis en début de post, j’ai tjs des modules en timeout
Du coup, il va falloir que j’exclue mes modules un à un pour les remettre les uns après les autres, c’est ça ?
Si c’est le cas, je vais devoir m’amuser à faire des virtuels de partout, et mettre à jour tous mes scénarios, avant de procéder aux exclusions
Ou est-ce que de part les logs fournis (je peux en poster un nouveau si besoin), il y a un autre souci ?
Au démarrage du réseau, par défaut, il y en a sur certains modules à cause de certaines classes mal supportées. Mais ça ne doit pas poser problème par la suite. Voir ici mes recherches sur le temps de démarrage du réseau Z-Wave. Optimisation du temps de démarrage du réseau Z-Wave
Est-ce que tu as des toujours des problèmes de timout lors d’exécution de commandes ?
Dans un premier temps, je déconseille d’exclure puis ré inclure des modules. C’est bien souvent le fichier de conf du réseau Z-Wave qui n’est pas à jour et pas bien aligné avec le contenu de la clé Z-Wave. Il faut bien prendre son temps pour soigner les nœuds un par un et le réseau. Ça ne se fait pas en 1 seconde après 1 clic. C’est plutôt plusieurs heures lorsque tous les modules se sont réveillés. C’est un peu comme pour les « bobos », c’est rapide de mettre un pansement, mais le « bobo » met du temps à guérir. Typiquement, le message « controller si busy », c’est souvent qu’on va trop vite pour le réseau. 
Non, avec le plugin openzwave, il n’y a pas besoin. Un simple changement de l’ID suffit. Juste noter l’ID du nouvel équipement qui vient de se créer automatiquement, supprimer cet équipement et changer l’ID de l’ancien équipement pour le nouvel ID.
1 « J'aime »
Merci d’avoir pris le temps de regarder le pb
En fait, le timeout n’est pas lors du démarrage.
Une fois que le réseau est démarré, tout est ok
Mais au bout de quelques temps (une journée, voire plus ou moins, je ne sais pas exactement, j’ai un module qui passe avec des timeout)
Le module en question est un FGBS 222, qui me remonte des données de sondes de température
Et quand le module passe en timeout, lorsque je clique sur plugin / zwave, ça tourne en rond.
Je n’ai pas d’autre solution que relancer jeedom 
Edit : j’avais encore un plantage ce soir, et en relançant le demon ZWAVE, je me retrouve à nouveau avec un msg comme quoi le port n’est pas configuré :frowning :frowning
Pourtant, clé neuve, siwtch usb compatible (à priori) et alimenté, donc visiblement pas de souci d’alim depuis la box
Je ne sais pas ce qui a pu rendre malade mon réseau ZWAVE
Hello,
Si tu n’as pas essayé de fixer le nom de ton device USB avec les UDEV rules, tu devrais peut être regarder vers cette solution.
J’avais des instabilités il y a quelques années entre tous les stick USB, et depuis la mise en place des udev rules, plus aucun soucis de « port non configuré ».
Cdrik
1 « J'aime »
Salut
J’ai un peu le même soucis que toi. Le plugin fonctionne nickel et d’un coup plus rien ne répond.
J’ai également des timeout dans les Logs.
Je suis en train de creuser pour comprendre et pour le moment, j’ai un petit scénario avec lequel j’enregistre le nombre de messages rejetés afin d’être informé si d’un coup il y a beaucoup de messages rejetés.
Mais cela ne semble pas suffisant. Par exemple depuis 20h, mon système ne répond plus. J’ai lancé la commande top et j’ai vu que le daemon prenait 100% de cpu. En relançant le daemon, je suis aux alentours des 1%
Le port est configuré en auto et j’ai l’impression qu’il y a eu une perte du port car ce dernier semble avoir changé.
Je vais donc essayé de le fixer pour voir ce que cela change.
Essaye de voir la charge du processus quand ton plugin est planté.
Ce matin, c’est planté à nouveau (timeout sur des éléments, et du coup, rien ne répond)
Je viens de regarder le CPU, 1.16%, rien de dingue à priori 
Je vais voir pour essayer de fixer le port USB (je n’ai jamais fait, je vais tester). Par retour d’expérience, en l’état, si je relance juste le demon, je vais avoir un msg de port USB non configuré.
J’espère avoir un changement suite à la manip sur les ports
OK donc peut être pas même souci que moi.
J’enregistre la charge du processus de mon coté pour voir si ca augmente. Mais je vais comme toi essayer de fixer le port car à chaque fois, j’ai l’impression que ca vient de là.
Bon courage
Je suis en train de regarder pour les UDEV rules
Je me suis connecté en SSH à mon serveur, et quand je vais dans le répertoire /etc/udev/rules.d/, je n’ai pas de fichier correspondant à l’USB, seulement un fichier
Du coup, je ne vois pas trop comment procéder.
Dois-je créer moi-même un fichier de conf ?
En regardant un peu sur le forum et sur le net en général, j’ai vu qu’il fallait saisir une commande
lsusb
afin de trouver les ID de la clé, mais quand je fais cela, j’ai un message « command not found »
Je ne suis pas expert en système linux, et du coup, je ne veux pas m’aventurer à faire des manip pour pourraient faire pire que mieux
edit : pour command not found, j’ai trouvé, je n’avais pas les utilitaires installé
j’ai installé le paquet, et commande ok, par contre, autre problème
C’est comme si mon dongle n’était plus vu par mon système (c’est bien cela ?)
edit#2 :
un reboot de mon jeedom (pas la VM jeedom, mais bien seulement le jeedom par l’interface de jeedom) me donne maintenant visiblité sur mon dongle
Le fait de fixer les ports règlerait vraiment le souci ? ou bien est-ce plus « grave », car le dongle n’est plus visible de façon aléatoire
Merci d’avance pour votre retour
je viens de fixer le port
Je vais attendre de voir si les logs me remontent des timeout encore ou non
1 « J'aime »
Ta clé est connectée en direct sur un port usb. Sur la Delta il n’y a que cette VM?. Je ne connais pas particulièrement comment la Delta gère les ports USB. Fixer les ports c’est la bonne piste je pense mais il faut aussi être certain que la Delta ne soit pas à l’origine du pb. Est-ce qu’il y a des paramètre dans l’OS de la freebox à regarder pour s’assurer qu’elle n’utilise pas le port pour autre chose que la VM Jeedom.
Je ne connais pas non plsu la qualité/stabilité de l’alimentation sur les port USB de la Freebox. J’imagine qu’elle ne devrait pas avoir trop de pb mais sinon le coup du HUB avec alimentation peut être une piste. Je pense que tu touches du doigt l’origine de tes soucis. Le port USB instable.
1 « J'aime »
J’ai bien 2 VM sur la Detla, et j’ai regardé en effet pour voir si sur l’autre VM, je n’avais pas mappé les USB, mais ce n’est pas le cas. Du coup, qu’une seule VM utilise l’USB
Ensuite, j’ai eu la même réflexion que toi, à savoir que le pb USB pourrait venir de la Delta.
Mais pour le coup, en redémarrant jeedom (pas le demon, ni la VM, mais juste jeedom)
le dongle était remonté, ce qui me laisse à penser que la mapping USB depuis la Delta n’est pas forcément en cause (mais je n’y mettrai tout de même pas ma main à couper)
Sur tes conseils, j’avais changé le dongle, et par la même occasion, j’y ai intercalé un HUB USB 7 ports alimenté, justement pour exclure les soucis éventuels d’alimentation USB
Le dernier test si ça déconne, pour voir la gestion USB, ce serait peut-être de connecté mon HUB Usb sur le port USB C plutôt que l’USB A 
il n’aura pas fallu attendre longtemps, j’ai de nouveau la même chose.
Je vais tenter un reboot de la Delta complète, on va voir ce que ça donne.
Mais au final, je pense que je peux bel et bien exclure un souci interne à Jeedom (cela me surprenait, mais pourquoi pas), mais plutôt incriminer un souci de l’USB de la Detla
est ce qu’il y a un mode économie d’énergie sur les ports usb de la delta?
Quelques pistes/posts qui confirment des soucis de stabilité du port usb sur delta
tu n’es pas le seul😅
pas à ma connaissance
je rencontre le pb que depuis quelques semaines, alors qu’avant, RAS.
Après, peut-être qu’une MAJ de la partie serveur de la box a apporté une modif de la gestion de l’usb, je ne sais pas
j’ai commandé un câble usb C pour tenter de connecter le HUB sur ce port, plutôt que le port Usb classique
J’ai mis en place en début d’après-midi le câble USB C pour relier le HUB USB sur le port USB C de la box.
J’attends de voir ce que ça donne, en espérant qu’il y ai plus de stabilité sur ce port USB que sur le A de la box.