Soucis sur mon réseau z-wave

Je ne comprends pas trop cette partie ?
J’avais cru qu’à chaque redémarrage du daemon l’ensemble était perdu est il fallait qu’il reconstruise les routes … non ?

Je ne sais pas exactement ce qu’il fait. Je dirais que l’ensemble n’est pas perdu, les infos sont stockées dans le fichier de configuration zwcfg_0x********.xml. Il remet à jour des routes, la listes des voisins des modules. Les colonnes de la table de routage sont mises à jour après un redémarrage. Après une inclusion, je dois redémarrer le réseau pour compléter les colonnes. Je trouve qu’il y a plus de bénéfices que de risques avec un redémarrage… Si tu le supprimes le fichier de conf XML, là oui, il va devoir tout recréer, c’est ce que j’avais fait pour pouvoir utiliser l’analyseur de log sur le site openzwave (voir plus haut) Soucis sur mon réseau z-wave - #43 par Domatizer

@Bison
Sur l’ancien forum, les conseils de @Mav3656 peuvent répondre à tes questions
https://forum.jeedom.com/viewtopic.php?p=758527

1 « J'aime »

Bravo et un gros merci pour cette analyse.

Ce qui est étonnant avec ce niveau de précision c’est le silence des helpers et des développeurs. Je pensais qu’avec tout cela un patch serait plus facilement réalisable.

Je m’étonne aussi du fait que certains répondent qu’ils ont pas de problème chez eux. Jeedom pour ses box ont une solution zwave en carte maison ( merci pour la vidéo domotech ) Si ça se trouve il y a une grosse différence de fonctionnement par rapport a l’USB.

C’est peut être pour cela que le problème n’a pas été vu avant alors que pour beaucoup d’entre nous il est général.

1 « J'aime »

Hello,

2 points:

  • Attention de ne pas confondre : les développeurs tiers non pas de lien avec les plugins officiels.
    On peut aider mais ce n’est pas notre rôle de faire le support la dessus, perso j’ai aussi un boulot…
    Si vous voulez une réponse il faut faire un ticket.
  • je fais partie des gens qui disent qu’ils n’ont « plus » de problèmes car c’est le cas ou très peu. Tout est automatisé et ça fait ce que ça doit quand il faut (et donc je n’analyse pas les logs en détails). BTW je pense qu’il faut mettre le code en parallèle des logs sinon peu de conclusions possible.
    Et sur mon install principal j’avais plus de soucis avec ma smart qu’avec mon nuc + clé usb mais la smart est à présent dans une deuxième maison avec très peux de modules et tout fonctionnent aussi.

Il n’y a pas de différence, un contrôleur Z-Wave qu’il soit GPIO ou USB, expose une interface série.
Plus de détails :
ici : [Présentation] akenad - #4 par akenad
et ici : [RTEX] Odroid-C2 - eMMC - Armbian Buster Kernel 5.3 - Jeedom V4

akenad :slight_smile:

Merci @Mips pour ta precision ! tu as raison de me reprendre Jeedom est OpenSource je n’ai pas a faire un ticket a une entreprise. Je fais plus confiance « sur la communauté » pour des pistes collectifs.

Zut je pensais que USB pouvait être une piste (surtout avec la porté et l’antenne pour un signal plus puissant dommage d’avoir ruiné mon idée @akenad

Je pense que tant que l’on aura pas la solution en version 1.6 de la lib ca restera un problème (meme s’il est apparu pour moi en 2018)

Bonjour a tous,

Ca discute bien ici :slight_smile: j’ai lu plusieurs messages en diagonale et certaines choses avec lesquelles je suis d’accord (beaucoup en fait !)

En complément :

  • je continue de penser que le zwave est super fiable et à l’heure actuelle sur le podium des protocoles domotiques (oui faut que Jeedom fasse quelque chose pour arrêter d’utiliser ASAP la librairie openzwave au risque de perdre une énorme partie de sa clientèle dès 2020)

Maintenant, pour essayer d’arranger les choses chez vous :

  • le zwave a vraiment une très mauvaise portée. C’est impressionnant a quel point c’est mauvais et fragile. Heureusement c’est maillé… on est sauvé, il faut bien le régler ! Et bien réglé ca fonctionne :slight_smile:
  • CONSEIL : mettre votre contrôleur Z-Wave (la Smart ou le dongle USB, peu importe ce que vous utilisez) loin de toute perturbation électromagnétique (télé, téléphone fixe, répéteur wifi, câbles électriques…) L’impact est énorme sur la stabilité du réseau. C’est aussi vrai pour les modules.
  • Il faut inclure les équipements en portée directe du contrôleur, ça beaucoup d’entre vous le savez déjà. Vous éviterez les inclusions non abouties.
  • CONSEIL : soigner vos noeuds lorsqu’ils sont a leur endroit définitif (pour un module secteur, remettez les caches, couvercles, et ou interrupteurs en place avant de soigner !)
  • procédez module par module et observez le résultat. Normalement c’est assez rapide de soigner un module. Quelques secondes.
  • ATTENTION : beaucoup d’entre vous se rassurent d’avoir beaucoup de noeud voisin. Il n’en est rien au contraire. Croire qu’on a un voisin et ne pas réussir a le joindre génère du DROP COMMAND et de la latence. Si des voisins disparaissent lorsque vous soignez le réseau, c’est peut-être bon signe. Avoir moins de voisins mais des voisins proches est gage d’un meilleur réseau, plus stable.
  • concernant le contrôleur principal : si les voisins du contrôleur principal ne sont pas mis à jour lorsque vous soignez un module (la table de routage devient asymétrique) → vous pouvez « rafraîchir les infos » dans la configuration du noeud représentant le contrôleur (souvent c’est le noeud 1) → ou vous pouvez redémarrer le démon zwave mais ça prend plus de temps !
  • si vous déplacez des meubles ou faites des travaux, il se peut que vous deviez soignez le réseau. Encore une fois c’est sensible à l’environnement.
  • RAPPEL : soigner le réseau est un processus qui prend du temps. Les noeuds secteurs se mettent à jour immédiatement. Pensez a réveiller vos noeuds sur pile pour aboutir plus rapidement, et retrouver la stabilité dans votre réseau.
  • il est indispensable d’avoir aucun NOK dans la vie santé du zwave. Si vous en avez, vous pouvez rafraîchir les infos du noeud concerné. Si ça ne fonctionne pas exclure puis réinclure le noeud
  • supprimez vos noeuds ou équipements dont l’inclusion a échouée. Pensez a cliquer sur « synchroniser » dans la page du plugin zwave pour les faire apparaître, et supprimez ces noeuds en échec et/ou fantômes.

Très bonne journée a tous :slight_smile:
Pierre (Mav3656)
Helper Officiel Jeedom.

Bonjour @Mav3656 et merci pour tout ces conseils

Pour ma part ça démarre mal car mon dongle zwave est branché sur mon NAS (Jeedom sur une VM du NAS) qui se trouve dans le meuble TV juste à côté de la box, etc…
Niveau ondes il doit être servi :crazy_face:.

Hier j’ai redémarré le daemon pour passer les logs en info et essayer d’analyser un peu. Suite au redémarrage j’ai un nœud qui a été signalé mort dans les alertes (celles visibles en haut en Orange dans Jeedom). J’ai alors voulu le soigner car dans la santé zwave il était bien UP. Ensuite j’ai actionné le module pour fermer le volet. Et bien c’était mort, la queue zwave restait à 1 et n’a fait qu’augmenter quand je faisais des actions. Bref nouveau reboot du daemon.

Qu’entends-tu par ne plus s’appuyer sur OpenZwave ? Que Jeedom devrait intégrer nativement un code maison pour gérer le Zwave ?

EDIT : Par rapport au noeud voisins qui devrait finalement être assez limité, l’idée c’est donc finalement d’avoir plus de bleu que de vert dans la table de routage ?

Bonjour Bison,

Je te conseille fortement d’utiliser une rallonge USB et d’éloigner ton dongle Z-Wave comme indiqué dans mon message précédent. Cela améliorera sans aucun doute la stabilité de ton réseau.

Si la queue Z-Wave ne fait qu’augmenter, tu fais face à un autre problème qu’un réseau instable. Un réseau instable échoue dans l’envoi des messages mais la queue doit diminuer. Malheureusement j’ai peu de pistes à te proposer pour ce problème et je ne connais pas tes compétences linux. Si ce problème est systématique, tu peux ouvrir un ticket au support. Il n’est pas impossible que ton infrastructure et/ou sa configuration soit remise en cause. Dans ce cas, tu ne dois pas pouvoir piloter un seul de tes modules depuis Jeedom ?

:ligTu peux aussi poster tes logs suite au redémarrage du démon « openzwave » et « openzwaved » en debug (niveau de log à configurer dans la configuration Jeedom, onglet « log » puis redémarrer le démon).

A ma connaissance l’équipe Jeedom est consciente des limitations de la librairie. Peu de communications officielles à ce sujet, mais il n’est pas exclu qu’ils modifient un jour le plugin par du code maison, ou bien une autre librairie se basant sur le SDK Silicon Labs. C’est un autre débat… :fire:

Dis comme ça, non… Accordons nous sur la définition « vert=le module(dont l’id figure en début de ligne) pense que ce voisin (dont l’id figure en haut de la colonne) est directement joignable et est susceptible d’essayer de communiquer directement avec lui ». Bien entendu, si le vert n’est pas justifié, (a été acquis dans des conditions différentes lorsque le module n’était pas encastré dans le mur par exemple), la communication échouera et de la latence sera généré par cet échec (attente du timout de la communication). Reformulé autrement : il faut le + de verts possibles. Mais des vrai « verts », lorsque les modules sont à leur emplacement définitif et dans leur conditions réelles d’utilisation.

Attention à la matrice de routage qui donne beaucoup d’informations : à l’exception des associations directes si tu en utilises, les informations importantes sont :

  • entre le contrôleur et les autres nœuds (première ligne / première colonne - la matrice étant symétrique lorsque tout est en ordre)
  • entre les nœuds secteurs entre-eux
  • depuis un nœud à pile vers le contrôleur (et/ou vers les nœuds secteurs). L’important est d’avoir au moins 2 ou 3 voisins directs (minimum), sinon risque de fiabilité du réseau sur le nœud concerné (car en cas d’échec de la communication, il n’y aura pas d’autre route pour retenter la communication).

Communément, les informations de routage entre 2 noeuds à piles ne sont pas forcément intéressantes à analyser (sauf exceptions).

Bonne journée,
Cdt.,
Pierre (Mav3656)
Helper Officiel Jeedom.

Bonjour,
Il faut aussi attendre, et plus que 30s, quand ça démarre ou qu’un soin global à été lancé, suivant la taille du réseau la queue peut monter très haut et cela pendant 5 min au moins.
Et c’est normal que toutes actions (allumé, éteindre…) ne fasse qu’augmenter celle ci.
Donc éviter de faire plein d’action, ne pas cliquer frénétiquement partout etc : Attendre.

1 « J'aime »

@Mav3656, ok je vais voir pour acheter ou retrouver une rallonge USB histoire d’éloigner un peu le dongle zwave.

J’observe effectivement 2 phénomènes :

  • Soit l’ordre n’arrive pas au module (reste à savoir s’il est vraiment envoyé comme le montrait @Domatizer) et il ne se passe donc rien mais en essayant à nouveau 2/3 secondes après, ça fonctionne
  • Soit l’ordre n’arrive pas au module et je rentre dans le cas ou la queue zwave ne cesse d’augmenter et là, en effet, le réseau zwave devient inutilisable je ne peux plus envoyer ou recevoir aucun ordre.
    @Mips, bien sûr j’attends après le reboot que la queue soit à 0 pendant 2/3 minutes avant d’essayer d’envoyer un ordre. Ici je parle d’un problème qui survient aléatoirement au bout de quelques heures à quelques jours. L’état zwave est en network ready avec une queue à 0 et l’ensemble a fonctionné pendant un bon moment avant que ça dérape.

Quand j’observe qu’un ou 2 ordres ne passent pas je vais regarder la queue. Dans le cas ou elle est à plus de 0 c’est cuit. J’ai déjà essayé de faire un « Annule toutes les commandes en cours sur le contrôleur. » mais ça ne donne rien et j’ai beau attendre des heures, le compteur dans la queue ne fait qu’augmenter au fur et à mesure des messages qui ne peuvent pas être traités.

  • Concernant les logs, je suis passé il y a peu en « info » pour observer un peu ce qu’il se passe quand on envois des ordres.

Même dans le cas ou un ordre est reçu immédiatement, le module continu de discuter un petit moment … c’est normal ?
Exemple :

2020-04-03 22:15:08.923 Info, Node024, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2020-04-03 22:15:08.964 Info, Node024, SwitchMultilevel::Set - Setting to level 0
2020-04-03 22:15:08.964 Info, Node024, Processing (Send) Nonce Request message (Callback ID=0x53, Expected Reply=0x13)
2020-04-03 22:15:08.964 Info, Node024, Sending (Send) message (Callback ID=0x02, Expected Reply=0x13) - Nonce_Get(SwitchMultilevelCmd_Set) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:09.030 Info, Node024, Request RTT 67 Average Request RTT 269
2020-04-03 22:15:09.111 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:09.112 Info, Node024, Sending (Send) message (Callback ID=0x55, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=24): 0x01, 0x0a, 0x00, 0x13, 0x18, 0x03, 0x26, 0x01, 0x00, 0x25, 0x55, 0xaa
2020-04-03 22:15:09.257 Info, Node024, Request RTT 293 Average Request RTT 281
2020-04-03 22:15:09.257 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x54, Expected Reply=0x04)
2020-04-03 22:15:09.257 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:09.350 Info, Node024, Request RTT 92 Average Request RTT 186
2020-04-03 22:15:09.432 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:09.432 Info, Node024, Sending (Refresh) message (Callback ID=0x56, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x56, 0xa8
2020-04-03 22:15:09.585 Info, Node024, Request RTT 328 Average Request RTT 257
2020-04-03 22:15:09.873 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:09.874 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x11, 0x43, 0xb9, 0x3a, 0xb8, 0x31, 0x3c, 0x59, 0x05, 0x01, 0xce:
2020-04-03 22:15:10.014 Info, Node024, Request RTT 758 Average Request RTT 507
2020-04-03 22:15:10.111 Info, Node024, Response RTT 854 Average Response RTT 573
2020-04-03 22:15:10.111 Info, Node024, Received SwitchMultiLevel report: level=58
2020-04-03 22:15:13.338 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:13.339 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x50, 0xb4, 0xf3, 0x61, 0x6f, 0x84, 0x93, 0xe7, 0x05, 0x01, 0x1a:
2020-04-03 22:15:13.571 Info, Node024, Received Meter report from node 24: Power=99.3W
2020-04-03 22:15:17.988 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x57, Expected Reply=0x04)
2020-04-03 22:15:17.988 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:18.055 Info, Node024, Request RTT 67 Average Request RTT 287
2020-04-03 22:15:18.142 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:18.142 Info, Node024, Sending (Refresh) message (Callback ID=0x58, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x58, 0xa6
2020-04-03 22:15:18.324 Info, Node024, Request RTT 336 Average Request RTT 311
2020-04-03 22:15:19.782 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x7c, 0x7f, 0xca, 0xb8, 0x5d, 0x82, 0x2a, 0x8f, 0x05, 0x01, 0xf8:
2020-04-03 22:15:19.786 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x02, 0x8b, 0xc9, 0xc7, 0xa1, 0x05, 0x0f, 0x6f, 0x05, 0x01, 0xb0:
2020-04-03 22:15:19.792 Info, Node024, Response RTT 5 Average Response RTT 289
2020-04-03 22:15:19.792 Info, Node024, Received SwitchMultiLevel report: level=2
2020-04-03 22:15:22.884 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:22.885 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xf2, 0x44, 0x32, 0x9c, 0x22, 0xdc, 0x02, 0xc5, 0x05, 0x01, 0xd2:
2020-04-03 22:15:23.121 Info, Node024, Received Meter report from node 24: Power=0.0W
2020-04-03 22:15:26.996 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x59, Expected Reply=0x04)
2020-04-03 22:15:26.996 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:27.063 Info, Node024, Request RTT 67 Average Request RTT 287
2020-04-03 22:15:27.142 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:27.142 Info, Node024, Sending (Refresh) message (Callback ID=0x5a, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x5a, 0xa4
2020-04-03 22:15:27.287 Info, Node024, Request RTT 291 Average Request RTT 289
2020-04-03 22:15:27.517 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:27.518 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xca, 0xe0, 0x72, 0x27, 0x63, 0x9d, 0xb6, 0x64, 0x05, 0x01, 0xa0:
2020-04-03 22:15:27.654 Info, Node024, Request RTT 658 Average Request RTT 473
2020-04-03 22:15:27.751 Info, Node024, Response RTT 755 Average Response RTT 522
2020-04-03 22:15:27.751 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:15:36.001 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x5b, Expected Reply=0x04)
2020-04-03 22:15:36.001 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:36.067 Info, Node024, Request RTT 66 Average Request RTT 269
2020-04-03 22:15:36.151 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:36.151 Info, Node024, Sending (Refresh) message (Callback ID=0x5c, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x5c, 0xa2
2020-04-03 22:15:36.296 Info, Node024, Request RTT 295 Average Request RTT 282
2020-04-03 22:15:36.528 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:36.528 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x80, 0x6b, 0x15, 0xa2, 0x48, 0x17, 0x67, 0x19, 0x05, 0x01, 0x8e:
2020-04-03 22:15:37.751 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xbc, 0x45, 0x72, 0xfa, 0x90, 0x88, 0xb5, 0x5b, 0x05, 0x01, 0x74:
2020-04-03 22:15:37.756 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x69, 0x28, 0x83, 0xcc, 0xc5, 0x3a, 0x30, 0xee, 0x05, 0x01, 0xdc:
2020-04-03 22:15:37.758 Info, Node024, Response RTT 1 Average Response RTT 261
2020-04-03 22:15:37.758 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:15:45.006 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x5d, Expected Reply=0x04)
2020-04-03 22:15:45.006 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:45.073 Info, Node024, Request RTT 66 Average Request RTT 269
2020-04-03 22:15:45.151 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:45.151 Info, Node024, Sending (Refresh) message (Callback ID=0x5e, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x5e, 0xa0
2020-04-03 22:15:45.297 Info, Node024, Request RTT 290 Average Request RTT 279
2020-04-03 22:15:45.529 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:45.530 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xd7, 0xf1, 0x3e, 0x11, 0x21, 0x2d, 0xcc, 0x7e, 0x05, 0x01, 0x44:
2020-04-03 22:15:45.746 Info, Node024, Request RTT 739 Average Request RTT 509
2020-04-03 22:15:45.767 Info, Node024, Request RTT 760 Average Request RTT 634
2020-04-03 22:15:45.840 Info, Node024, Response RTT 833 Average Response RTT 547
2020-04-03 22:15:45.840 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:15:52.948 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:15:52.949 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x00) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0xa8, 0xbb, 0xa9, 0xc9, 0xe8, 0x76, 0x48, 0xcf, 0x05, 0x01, 0x99:
2020-04-03 22:15:54.012 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x5f, Expected Reply=0x04)
2020-04-03 22:15:54.012 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:15:54.079 Info, Node024, Request RTT 66 Average Request RTT 350
2020-04-03 22:15:54.162 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:15:54.162 Info, Node024, Sending (Refresh) message (Callback ID=0x60, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x60, 0x9e
2020-04-03 22:15:54.306 Info, Node024, Request RTT 293 Average Request RTT 321
2020-04-03 22:15:54.674 Info, Node024, Request RTT 662 Average Request RTT 491
2020-04-03 22:15:55.764 Info, Node024, Response RTT 1751 Average Response RTT 1149
2020-04-03 22:15:55.764 Info, Node024, Received SwitchMultiLevel report: level=0
2020-04-03 22:16:03.020 Info, Node024, Processing (Refresh) Nonce Request message (Callback ID=0x61, Expected Reply=0x04)
2020-04-03 22:16:03.020 Info, Node024, Sending (Refresh) message (Callback ID=0x02, Expected Reply=0x04) - Nonce_Get(SwitchMultilevelCmd_Get) - 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x98, 0x40, 0x05, 0x02:
2020-04-03 22:16:03.087 Info, Node024, Request RTT 66 Average Request RTT 278
2020-04-03 22:16:03.171 Info, Node024, Received SecurityCmd_NonceReport from node 24
2020-04-03 22:16:03.172 Info, Node024, Sending (Refresh) message (Callback ID=0x62, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=24): 0x01, 0x09, 0x00, 0x13, 0x18, 0x02, 0x26, 0x02, 0x25, 0x62, 0x9c
2020-04-03 22:16:03.316 Info, Node024, Request RTT 295 Average Request RTT 286
2020-04-03 22:16:03.540 Info, Node024, Received SecurityCmd_NonceGet from node 24
2020-04-03 22:16:03.541 Info, Node024, Sending (Refresh) message (Callback ID=0x01, Expected Reply=0x04) - Nonce_Report - 0x01, 0x11, 0x00, 0x13, 0x18, 0x0a, 0x98, 0x80, 0x5a, 0x61, 0xf2, 0x42, 0xd7, 0x3a, 0x11, 0x5a, 0x05, 0x01, 0xde:
2020-04-03 22:16:03.674 Info, Node024, Request RTT 653 Average Request RTT 469
2020-04-03 22:16:03.770 Info, Node024, Response RTT 749 Average Response RTT 949
2020-04-03 22:16:03.770 Info, Node024, Received SwitchMultiLevel report: level=0

2020-04-03 22:15:27.751 Info, Node024, Received SwitchMultiLevel report: level=0 le volet a fini de descendre et pourtant ça papote encore jusqu’à 2020-04-03 22:16:03.770 Info, Node024, Received SwitchMultiLevel report: level=0, normal ?

Ensuite je vois régulièrement des lignes comme ça je présume que ce n’est pas trop normal :

2020-04-05 10:52:45.173 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:52:46.114 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:52:46.116 Warning, WARNING: Out of frame flow! (0x07). Sending NAK.
2020-04-05 10:53:15.074 Warning, m_currentMsg was NULL when trying to set MaxSendAttempts
2020-04-05 10:53:45.575 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:53:46.524 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:53:46.526 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.
2020-04-05 10:53:47.273 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:53:48.224 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:53:48.226 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.
2020-04-05 10:53:48.227 Warning, WARNING: Out of frame flow! (0x2a). Sending NAK.
2020-04-05 10:53:48.228 Warning, WARNING: Out of frame flow! (0x05). Sending NAK.
2020-04-05 10:53:48.229 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.
2020-04-05 10:53:48.231 Warning, WARNING: Out of frame flow! (0x57). Sending NAK.
2020-04-05 10:54:16.701 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:54:17.644 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:54:17.646 Warning, WARNING: Out of frame flow! (0x07). Sending NAK.
2020-04-05 10:54:51.430 Warning, WARNING: 50ms passed without finding the length byte…aborting frame read
2020-04-05 10:54:52.374 Warning, WARNING: Out of frame flow! (0x1f). Sending NAK.
2020-04-05 10:54:52.376 Warning, WARNING: Out of frame flow! (0x00). Sending NAK.

De ce que j’ai compris cela se produit quand un périphérique utilise le port USB en même temps.

Je suis tombé sur un forum de HomeAssistant qui parle qu’après avoir désactivé le ModemManager.service tout est rentré dans l’ordre. Sauf que sur ma Debian Stretch ce service n’est pas démarré ou n’existe pas. J’ai regardé sur Debian Buster (passage en V4 en cours d’analyse) et il existe bien.

Coté Linux je me débrouille alors si tu as des pistes @Mav3656, je peux regarder sans trop de problème

Merci @Mav3656 pour tous ces bons conseils.

Aucun dongle Z-Wave n’a de véritable antenne comme on peut le voir sur des clés Bluetooth ou Wi-Fi. On remarque bien la différence de portée entre les modules secteurs avec un fil d’antenne et les petits modules sur pile avec des antennes enroulées. Il faudrait une antenne de 8.6 cm pour du 868 MHz.

C’est pour cela qu’on galère ici et ailleurs.

Exactement d’accord, la concurrence du Z-Wave arrive.

@Mav3656 J’aimerais bien connaître ton point de vue concernant la gestion d’openwave avec les noeuds inclus en mode sécurisés ?

J’ai remarqué que lorsque que j’ai un souci, il y a souvent un module sécurisé dans le mauvais coup. C’est soit un module sécurisé qui foire tout seul ou soit un module non sécurisé qui foire lors d’une collision avec un module sécurisé.

1 « J'aime »

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).:fire:

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) :wink:

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.

Merci @Mav3656 pour tes réponses.

Dans la doc du plugin, il est écrit la même chose.

Depuis l’apparition du Z-Wave+, il est possible de sécuriser les échanges entre le contrôleur et les noeuds. Il est donc recommandé de faire les inclusions en mode Sécurisé

C’est ce que j’ai fait au début pour tous les modules et j’ai choisi le Z-Wave pour ça aussi.

J’avais vu cette info bien après. Dommage que la clé ne soit pas modifiable dans Jeedom facilement en début d’installation. Je n’ai pas le courage de tout recommencer. Je ne le ferai pas avant 1 an ou 2 lorsque les ennuis du Z-Wave auront disparus. Car il faut être bien motivé pour exclure puis ré inclure tous les modules…

Ok pour de la latence. Mais certains ordres ne sont bien pas exécutés comme démontrés précédemment.

D’après mes nombreuses lectures sur les forums, mon ressenti est que jusqu’en 2018, openzwave fonctionnait bien. Je ne sais pas qui c’est passé en 2019, mais des gens qui n’avaient pas de soucis avant ont commencé a galérer. D’où ce post [avis] fiabilité z-wave et plugin openzwave
Depuis, peu de mises à jour…

En attendant d’avoir la nouvelle version d’openzwave 1.6 ou autre plugin basé sur le SDK, je cherche à obtenir un réseau stable, même si je n’ai pas accès à toutes les fonctions, mais il faut que que ça marche.

Ma conclusion actuelle est que le mode sécurisé fonctionne, oui mais aléatoirement avec les modules Fibaro Motion Sensor 2. Peut-être que c’est la faute d’autres modules ? Je n’en sais rien mais depuis que ces détecteurs sont non sécurisés, je peux enfin faire confiance en ma gestion de la présence. J’ai laissé tous les capteurs de portes/fenêtre en sécurisé, il y a tout de même des problèmes de collisions, mais cela reste gérable.

Voici les conséquences sur le comptage du nombre de présences confirmées dans la maison.


Passage en mode non sécurisé le 25 mars, pas de changement de scenarii, même matériel, nous sommes toujours 3 personnes présentes, pas de visites depuis début mars et bien confinées depuis mi-mars. Ce nombre ne doit donc pas dépasser 3. En mode sécurisé avant le 25 mars, ça déconnait plusieurs fois par jour. Depuis 2 semaines, c’est clean.

Actuellement, j’en suis entre 0 et 10 lignes d’erreur sur 10000 lignes de log openzwaved (avec un pic d’une trentaine au démarrage). J’ai bien avancé ce moi-ci. Prochaines étapes : passer en non sécurisé les Fibaro Dimmer 2 qui ne le sont pas, puis tous les capteurs de portes et enfin tous les autres modules.

Voilà, malheureusement, je ne suis pas prêt d’aller faire du sécurisé avant un moment…

Salut et merci pour les explications.

J’ai donc fais quelques modifications.

Je suis passé en V4 from scratch (en installant tout de même des plugins …).
J’ai re-syncrhronisé ma clef zwave et donc réimporté les modules. J’ai dû tous les renommer.
J’ai utilisé une rallonge USB pour éloigner la clefs de la box et du NAS QNAP sur lequel tourne la VM Debian Buster (USB2 indiqué dans la conf de la VM).

Le réseau zwave démarre en 286 secondes (variant suivant les fois).

Déjà dès le départ dans la santé zwave il manque plein de noms. Il suffit d’aller sur l’équipement, de sauver sans rien toucher et le nom apparait dans la santé zwave … ça sent un peu le bug.

Je soigne un noeud, 2 noeuds, j’attends bien que la queue retombe à 0 à chaque fois et pouf au 3eme noeud ça par en vrille.

A ce moment là @Mav3656 voila l’état du htop. Le processus python qui gère le zwave prends tout le CPU et reste comme ça jusqu’à reboot du daemon ou kill du processus en question.

Au départ je me suis dit, bon ben c’est ce module qui pose problème. Je reboot je recommence et ça le fait avec un autre module. Je reboot une 5eme fois et cette fois c’est caremment le module zwave qui ne vois plus les voisins. On tente de soigner le noeud mais ça fait rien et au bout d’un moment le CPU repart à 100%…

Qu’est-ce que c’est énervant :angry: :angry:

Je pars remettre la clef zwave en directe sur le port USB parce que là visiblement je m’en sort pas !

Bon évidemment ça marche pas mieux et ça plante également.

Possible que ce soit la clef Zwave qui déconne ? Vous avez déjà eu ce genre de cas ?
Au dernier reboot elle ne voyait même plus de voisins alors que les modules si … c’est totalement incompréhensible.

Je veux bien tenter d’acheter une machine physique avec un SSD pour mettre proxmox dessus à la place du NAS mais je vois moyennement pourquoi ça marcherait mieux …
Qu’est-ce qui se fait de bien pour pas trop cher ? Je trouve les NUC un peu cher quand même.

Bonsoir,
Quel serait ton budget?
Ceci étant, je serais surpris que les problèmes viennent de la plateforme.
J’ai d’abord eu un RPI3 maintenant un miniPC à base de I5.
Mes clés sont toutes branchées côte à côte sur les ports USB du pc et à part le Zigbee pour lequel je perds régulièrement des noeuds, je sais que le problème vient du maillage et je suis en train de l’améliorer, ça tourne comme une horloge.
Auparavant sur RPI3 les clés étaient toutes branchées sur un hub autoalimenté placé juste à côté du RPI. Là encore, pas de problème.
Peut-être la chance, alors j’en profite.

Salut,

Disons 150-200€, ça me parait pas trop mal. Sauf si c’est moins bien que mon QNAP 253A encore que lui n’a pas que ça a faire tourner … il a tout ses propres services.

Après peut-être que QNAP a une mauvaise gestion des ports USB et de la virtualisation !?
Ou alors comme je disais, que la clef que j’ai (Vision ZU1401-5) est à la ramasse.

C’est pas facile à dire mais j’ai l’impression qu’au départ j’avais moins de soucis, que c’était plutôt invisible à part quelques ordres qui ne passaient pas.
Maintenant depuis que la queue zwave ne dépile plus parce que le processus monte à 100% assez souvent ça devient vraiment galère de faire avec.

Alors ce qui est impossible à dire c’est si c’est à cause d’un problème matériel, d’un update du QNAP ou autre qui a foutu le bronx ou bien à force de rajouter des fonctionnalités et donc d’un confit entre le core et des plugins.

Entre parenthèse, sais-tu si le plugin fullyKiosk fonctionne bien en V4 car ce n’est pas annoncé comme tel et je l’ai tout de même installé sur ma récente V4.

Merki

Bonsoir @Bison

J’ai eu la même réflexion que toi en ce début d’année quand rien ne marchait correctement. J’avais hésité entre idéalement la Jeedom Pro, la JeedUp, un NUC, un vieux PC portable. Mais mettre 200€ ou 400€ dans du matos pour ne pas être sûr du résultat. Je n’ai pas franchi le pas et depuis, en persévérant, cela fonctionne bien mieux. A terme je passerai sur quelque chose de plus puissant car je suis toujours entre 1 et 2 de CPU.

Je suppose que tu as repris ta sauvegarde. Donc Jeedom n’a pas perdu les équipements. Dans un premier temps, ne te lance pas dans des exclusions/inclusions. Il faut d’abord que tu retrouves tous tes modules avec les noms.

Ouais, je trouve aussi que la syncho entre Jeedom/openzwave et la clé est limite. Souvent, dans la configuration, les paramètres du module de l’onglet Paramètre ne correspondent pas avec les paramètres réel du module. Donc, je fais « Actualiser les paramètres » plusieurs fois et je vais réveiller les modules sur piles. Combien de fois j’ai rentré les mêmes valeurs des paramètres inutilement, je croyais que le module les avait perdus, mais en fait, non, c’est Jeedom/openzwave qui n’avait pas les bonnes valeurs.

J’avais lu sur le net qu’il fallait prendre la Aeotec Z-stick Gen 5 et rien d’autre, c’est la meilleure à ce jour. Dans le doute, j’avais pris ce modèle. Je ne voulais pas gratter 30€ pour avoir des emmerdes ensuite.

Il faut que tu règles en priorité tes nœuds inconnus au niveau du plugin.