Passage sous ZWave JS et lenteurs au bout de quelques jours

Bonjour à tous,

Cela faisait un moment que je procrastinais pour passer au plugin ZWave JS, et j’ai profité d’une grippe et cloué à la maison pour m’y consacrer enfin. J’ai terminé la migration il y a trois semaines. J’avoue que ce n’était pas facile du tout, quasiment 5 jours plein temps pour tout réadapter. J’ai une soixantaine de modules en ZWave, et plus j’avance, plus je me dit que ce n’était peut-être pas le meilleur choix de protocole. Il y a 5 ans lorsque j’ai commencé à monter mon environnement, la fonction inclusion sécurisée m’avait séduite, et je comptais également utiliser la fonction détection pour gérer une alarme. Après de gros efforts j’ai quitté un système utilisant OpenZWave pas super stable avec de nombreux messages non remis et des rustines pour relancer les commandes au cas où, pour un système sous ZWave JS qui me fait un tas de bizarreries.

Le dernier problème en date, un Fibaro FGMS 001 qui a stoppé de communiquer du jour au lendemain. Les piles sont neuves, j’ai tenté plusieurs réveils, dont plusieurs à proximité du contrôleur (Aeotec GEN5+). ZWave JS le voyait comme endormi. J’ai fini par faire une réinclusion, faut voir si ça tient dans le temps.

J’ai également perdu un module (dead dans l’interface) alimenté sur secteur (Popp Strike Lock Control). Je pensais qu’il était grillé, mais il a fallu un reboot Jeedom l’a remis d’aplomb.

Mais le plus gênant, ce sont des ralentissements considérables qui apparaissent au bout de 2 ou 3 jours de fonctionnement. Certaines commandes n’arrivent qu’après 45 voire 60 secondes. Le redémarrage du démon ZWave ne solutionne rien, seul un reboot de Jeedom permet de rétablir la situation. À noter que lors des 2 ou 3 jours de fonctionnement sans latence, ça dépote vraiment par rapport à ce que j’ai pu connaître avec le précédent plugin ZWave.

Je n’ai pas encore eu le temps d’analyser en détails, au bout d’un moment, ça devient compliqué d’investir autant de temps. Ce projet m’en prend plus que tous les autres réunis, et je me rends compte que je passe mon temps à faire du debug au détriment de la fonction principale, développer des scénarios et des fonctionnalités. Je constate également que le sujet du ralentissement revient très souvent autour de ZWave JS, donc je me pose des questions. Je ne sais pas comment vous faites vous tous pour garder votre calme et votre patience, mais perso j’arrive juste à bout de nerfs avec ce système. Si je n’avais pas investi autant de temps et de pognon dans ces modules, ça fait longtemps que j’aurais banni ce protocole. J’essaie à présent dans la mesure du possible, d’utiliser une alternative, mais il me reste néanmoins de nombreux modules qu’il faut que je continue à gérer.

Si l’un de vous a rencontré des problèmes similaires ou des pistes pour commencer à investiguer la raison de ce ralentissement progressif, je suis preneur… Je lu qu’un module pouvait éventuellement flooder le réseau, mais comment identifier lequel ?

Bonjour,

Je déterre ce topic car malheureusement il n’est pas encore réglé. J’ai eu d’autres choses à gérer depuis, mais j’ai enfin pris le temps d’activer les logs et d’en faire une première analyse.

J’ai toujours constaté des périodes de latences sur mon réseau, mais depuis mon passage sous ZWave JS c’est encore pire. Certains événements mettent parfois jusqu’à 60 secondes pour être traités. Au démarrage du démon, le réseau est hyper réactif, presque instantané, et au fur et à mesure du temps, la réactivité se dégrade, puis revient temporairement à des niveaux acceptables.

J’ai donc analysé les logs. N’étant pas un expert, je me suis aidé de ChatGPT. Il en ressort que la source principale du problème est liée à mes modules Fibaro FGR-223 Roller Shutter 3 (volets roulants) :

  • signal trop faible,
  • forte charge sécurisée (S0),
  • erreurs de décodage dues aux nonces expirés,
  • engorgement des files d’attente côté contrôleur.

J’ai pas mal de volets roulants (9 volets) qui son souvent ouverts simultanément. Il est vrai que les problèmes observés apparaissent souvent après avoir actionner ces volets. Mes modules sont également déclarés en S0, ce qui est visiblement extrêmement générateur de messages.

J’ai lu qu’il serait mieux d’utiliser S2, voire aucun chiffrement. Je pourrais me passer de chiffrement sur certains volets car inaccessibles depuis l’extérieur, mais je préfèrerais en conserver pour ceux qui sont accessibles. C’était un peu la raison pour laquelle j’avais choisi Z-Wave.

Concernant le problème de signal, il est vrai que mes volets sont périmétriques et les plus éloignés du contrôleur. J’ai récemment migré vers une clé Zooz 800, et j’ai rajouté quelques modules sur secteur sur le trajet, mais ce n’est ni pire ni mieux.

Auriez-vous des conseils pour limiter le nombre de messages ? Le passage en S2 est-il une option sérieuse ?

En vous remerciant par avance de vos conseils.

Honnêtement, hors alarme professionnelle, je vois pas l’intérêt du chiffrement zwave pour un utilisateur lambda domotique. Combien de voleurs sont capables de pirater un réseau zwave?
Le reste de ton installation domotique est elle aussi sécurisée contre les intrusions.

Antoine

1 « J'aime »

Bonjour,

Sur la version de zwavejsUI utilisé par le plugin (9.20) il y a des bugs corrigés depuis avec des versions plus récentes de ACK ce qui engorge dans certains cas la file d’attente. Je ne dis pas que c’est la raison dans ton cas mais cela peut l’être.
Sinon dans l’interface Zwavejs-UI tu peux forcer des routes Zwave.

J’ai aussi parfois des problèmes avec les routes automatiques (c’est mise à jour en continu par Zwavejs-UI).

Merci pour vos réponses respectives.

J’ai pour principe d’appliquer les règles de base de sécurité informatique y compris au sein de mon LAN. J’ai installé une PKI et tous mes échanges s’appuient sur SSL. Je ne vois pas pourquoi ne pas le faire sur d’autres protocoles comme le Z-Wave. Et si ce protocole propose du chiffrement, il faut que ça fonctionne correctement, sinon aucun intérêt à le mettre à disposition. Mais comme déjà évoqué ultérieurement, je pense clairement avoir fait le mauvais choix en partant sur du Z-Wave. Je réfléchis d’ailleurs à remplacer certains modules par d’autres solutions, tant cette techno m’a posé des problèmes jusque là.

Pour répondre à @Madcow, oui, le sujet des routes est effectivement une piste que j’ai explorée, et j’ai rajouter en dur certaines routes pour le modules ayant une atténuation importante. Ceci ne résout malheureusement pas le problème d’engorgement du contrôleur.
J’ai également vu que la version intégrée à Jeedom avait du retard. J’avoue n’avoir pas regardé quelle était la version intégrée à d’autres plateformes comme HA.

Concernant le S2, y a-t-il des personnes qui ont intégré des modules en utilisant cette option ?

Bonjour.

Tentez de mettre a jour ZwaveJS dans sa version la plus récente :

Éditez le fichier suivant, avec l’éditeur de Jeedom :

plugin-zwavejs/core/config/zwavejs.config.ini

Modifiez le numéro de version, par :
11.2.1

Sauvegardez et réinstallez les dépendances du plugin pour valider la montée de version.

Et regardez si cela change le comportement du plugin.

Intéressant, merci ! Je vais tester ça au plus vite.

Le S2 génère moins de trafic que le S0 c’est certain.
C’est l’implémentation standard depuis quelques années en Zwave chiffré.

Je vais peut-être commencer par réinclure quelques modules en S2 pour commencer. De toute manière je n’ai pas intérêt à les laisser en S0 je pense.

Un peu de lecture générale sur S2 vs. S0 :

C’est indiqué notamment 3 frames pour le S0 alors que le S2 n’utilise qu’une seule frame.

1 « J'aime »

Bonjour,

Comme il y a des difficultés et de la latence il pourrait être intéressant de commencer par tester un moment en ne lançant pas des actions sur l’ensemble des volets d’un coup. Disons 3, voir si ça réagit, puis 3 autres…

Si c’est par scénario, idem en mettant 10 sec de pause entre chaque groupe.

On a déjà vu des cas de figure ou l’un des modules du réseau provoquait du flood et mettait le réseau à terre. C’est pas évident à tester par contre puisqu’il faut débrancher un module… Tester longuement puis passer à un autre…

J’ai effectivement plusieurs pistes à explorer grâce à vos indications. Toutes vont prendre du temps, ce que je n’ai pas forcément, mais bon, il va falloir que je fasse quelque chose…
Comme dit, passer mes modules en S2 devra être fait, donc autant commencer par là.

Bon, j’ai basculé 6 modules en non sécurisé, et un autre en S2. Malheureusement ce matin, j’ai encore eu de grosses latences. C’est vraiment épuisant :disappointed:. Vu que j’ai passé presqu’une journée à démonter les modules, les réinclure et adapter les scénarios, je n’ai pas encore eu le temps d’analyser les logs.

Je me pose cependant une question : lors de la remonté (ou de la descente) des volets, et sauf erreur de ma part, il y a certainement énormément de messages qui transitent car les volets remontent leur état au fur et à mesure de la progression. Je n’ai pas besoin d’avoir une telle granularité en temps réel au niveau du positionnement, n’y a-t-il pas moyen de diminuer cette valeur de refresh ?

Bonjour,

Normalement tu peux faire les exclusions/inclusions avec les interrupteurs.

Dans les récentes versions de zwavejsUI (>=10.6.1) il existe une option pour ça dans l’interface de zwavejsUI. Je l’utilise.

Oui je sais, mais ça ne fonctionne pas et je n’ai pas insisté vu que mon contrôleur n’est pas tout à côté…

Piste intéressante merci beaucoup ! Je vais explorer çà.