Bonjour,
@Mips a raison, il faut attendre de visualiser le temps qu’a mis le réseau à démarrer dans l’écran « réseau Zwave → résumé » avant toute chose. Un réseau correctement configuré doit démarrer rapidement, quelques minutes max.
En théorie, cela devrait démarrer en quelques secondes, mais à cause des nombreux messages non gérés par la librairie openzwave, on a énormément de timeout. En fait, chaque fois que vous avez le temps de visualiser la queue du contrôleur figée sur un nombre donné (>0) l’espace de quelques secondes, c’est un message non géré (pour un réseau bien configuré et en dehors des pannes matérielles bien sur).
Il faut savoir que les échanges lorsqu’ils fonctionnent sont de l’ordre de la millisecondes, ce qui est déjà extrêmement lent pour un protocole de communication mais n’oublions pas que le protocole répond à des contrainte de basse consommation, d’où le bas débit. On est bien loin des débits gigabytes éthernet, mais à l’échelle humaine on ne devrait absolument pas avoir le temps de se rendre compte de quoi que ce soit.
Yes, c’est la priorité dans ton cas. Cela ne réglera pas tes problèmes de queue qui ne se dépile plus. Mais cela stabilisera tes communications. Lorsque tu auras placé le dongle, il faudra que tu soignes l’ensemble de ton réseau.
Tu n’utiliserais pas l’API REST du plugin Zwave par hasard ? Via un script ou n’importe quoi d’autre ?
Je ne sais pas si c’est le module qui envoie des ordres spontanément. Je crois plus que c’est le plugin Jeedom qui scrute et interroge plusieurs fois en se disant « j’espère bien avoir la bonne réponse à la fin de tout ça ». C’est pareil chez moi. Je te propose de te concentrer sur ce qui te pose vraiment problème (latences et blocage de la queue) 
Pour le coup ça je n’ai jamais eu. De ce que je comprend ta machine perd les pédales en parsant les messages (j’ai l’impression que ce sont les messages reçus, mais je ne suis pas sûr sur ce coup là). Si c’est les messages reçus, il se peut que ça vienne des perturbations (introduisant du non sens dans tes trames d’où des erreurs de parsing), et le fait d’éloigner le dongle zwave de toutes perturbations électromagnétiques peut améliorer les choses. Si c’est un problème au niveau des accès à ton port USB sur ta machine, je n’ai pas d’idée dans l’immédiat à part essayer un autre port USB.
Si tu héberges sur autre chose qu’une machine dédiée (un simple raspberry pi suffit), ton problème peut venir d’interactions avec le monde extérieur (tout le reste qui tourne sur cette même machine). C’est l’une des raisons pour lesquelles j’ai exclu l’hébergement de Jeedom sur le Synology. Une autre raison est que lors des mises à jour du DSM, tu ne peux jamais être sûr que tout va continuer de bien fonctionner. D’ailleurs le service est interrompu pendant la mise à jour du Synology. Toutes ces raisons font que je ne trouve pas cette solution viable pour un Jeedom de production, où une qualité de service est attendue. En revanche c’est très bien pour faire du test ou prendre en main l’interface avant d’acheter quoi que ce soit.
Lorsque la queue zwave est bloquée, tu peux essayer de regarder du côté de la commande « htop ». Ca ne va pas te dépanner, mais je suis curieux de savoir si le processus qui héberge ton démon zwave est toujours là et dans quel état. Pour ma part quand j’ai eu ce problème, j’utilisais l’API REST, et je l’ai constaté avec une utilisation du processeur constante. J’ai déjà remonté ce problème, je n’ai pas eu de retour pour l’instant.
source : Queue zwave qui monte après maj zwave ou reboot smart - #5 par Mav3656
@Domatizer Je conseille de faire du sécurisé tant que possible. Il faut bien sur changer la clé Zwave par défaut avant la première inclusion (attention il faut la remettre à chaque mise à jour du plugin !). Je n’ai pas refait les tests effectués par @nechry mais je lui fait confiance, pour dire que seule la payload est chiffrée et que réseau chiffré et non chiffré cohabitent pour le routage. En tant qu’ingénieur et développeur, c’est aussi ce qui me parait le plus logique. Il faudrait vérifier au niveau du protocole pour être 100% sûr.
source : https://nechry-automation.ch/2018/01/22/modifier-cle-de-securite-zwave/
source : https://nechry-automation.ch/2018/01/25/maillage-mixte/
S’il est vrai que l’inclusion sécurisée génère un peu plus de traffic, cela ne devrait pas se sentir à l’échelle humaine. Malheureusement la librairie openzwave n’implémente que très peu de choses, et n’a pas fait des classes de sécurité sa priorité. Nous subissons donc de nombreux timeout sur ce traffic supplémentaire, et donc des ralentissements perceptibles. Cela ne doit en aucun cas se traduire par un ordre qui n’a pas été exécuté. Uniquement des ralentissements.
J’espère avoir répondu à vos questions,
Bonne journée à tous,
Pierre (Mav3656)
Helper Officiel Jeedom.
