FGMS001 qui reste bloqué en détection parfois

Voici mes valeurs (pas de problème à priori)


image

Merci pour le partage de ta config.

Bon, malheureusement aucune amélioration, deux œils bloqués en détection ce soir. Et ce sont deux qui ont des piles relativement jeunes (3 et 6 mois)

Tu serais pas en mode sécurisé ?

Sous OpenZWave, je me souviens qu’en mode sécurisé ces modules restaient « bloqués » fois sur 1 fois sur 10. Normalement, avec ZWaveJS, le mode sécurisé est bien géré,mais bon, on ne sait jamais. Perso, je n’ai jamais refait mes inclusions en mode sécurisé depuis car trop traumatisé à l’époque.

Sinon, il reste le problème du maillage. Ces 2 modules sont-ils trop éloignés du réseau ?

J’ai 2 modules autres que les oeils qui sont encore en sécurisé.
Pour le maillage je pense que c’est plutôt bon, j’ai pas mal de modules secteurs, j’ai parfois des routes à 2 sauts mais c’est rare.
Après c’est vraiment aléatoire sur les 12 oeils, je le vois parce que l’alarme me dit qu’elle ne peut pas s’activer, sinon je ne le verrais pas.
Je me pose la question aussi avec le contrôleur. C’est une clé qui a quelques années, une everspring SA413, est ce qu’elle arrive encore à suivre avec tous les modules. Mais vla le boulot pour la remplacer par une nouvelle génération !

Donc ça ne vient pas d’un module en particulier.

Après, il peut avoir aussi des modules qui mettent le bazar dans tout le réseau.

Oui, il faudrait effectuer une migration vers une clé Aeotec sans avoir à refaire les inclusion. En principe, cela doit être possible. Il faut trouver le bon tuto.

Oui ça serait l’idéal. Mais avec les quelques sujets que j’ai trouvé sur le forum, j’ai pas vraiment l’impression que ça soit faisable sans tout reinclure.

1 « J'aime »

Bonjour,

Entre 2 série 500 c’est réalisable sans problème normalement via le backup NVM réalisé par le plugin. Il y 1 cependant une limitation de sdk.

Bonjour,

J’ai vu également dans un autre poste que vous suggériez de mettre deux clés en parallèle (Changement de clé Z-Wave (Aeotec Gen5 -> Gen7) - #14 par Madcow). Ca pourrait être une solution pour migrer tranquillement vers une gen-7.
Mais c’est jouable avec le plugin ou c’est un truc costaud a faire avec 2 machines ?

Oui, c’est possible mais ca revient au même que d’exclure et réinclure sauf que tu peux le faire tranquillement, à ton rythme. Le système continuant à fonctionner

Oui ca serait l’idéal, mais j’avoue ne pas bien comprendre la faisabilité.
Sauf erreur, on ne peut renseigner qu’un device dans la configuration.
image

ce n’est pas possible, un seul contrôleur à la fois.

D’accord Merci. Bad news pour moi.
A mon avis, migrer vers une nouvelle clé, juste par supposition que ça peut être ça qui pose soucis est quand même bien complexe pour un gain inconnu.

Mon problème s’étant encore produit hier soir. Dans l’immédiat, je vais réinclure en non sécurisé les 2 modules sécurisés. Juste pour éliminer cette probabilité.
En regardant ce que je peux voir avec le plugin, j’ai quand même quelque chose qui me saute aux yeux, mais je ne sais pas l’interpréter.
Dans les statistiques, les oeils ont l’air vachements actifs par rapports à d’autres modules (RX/TX).


Est ce que ça ne flood pas tout le réseau ?

J’ai toujours des messages abandonnées, est ce que c’est normal ou un problème que je dois vérifier ?

Est ce que ça vaut le coup d’activer les logs de debug ? ou est ce que ça ne donnera pas d’informations particulières ?

Merci pour l’aide en tout cas ! Parce que la je suis largué…

Bonjour,

En effet ces modules causent beaucoup, mais ils reportent la T°C et la luminosité.

Ces fréquences de mise à jour sont modifiables, mais de là à flooder le réseau j’ai un doute. Cependant, tu ne devrais avoir aucun paquet droppé.

Tu peux essayer d’ajuster les fréquences de mise à jour des modules, pour la température et luminosité.

Bonjour
Voila, ça fait 5 jours que j’ai réinclus les 2 modules sécurisé vers du non sécurisé.
Je n’ai pas eu de nouveaux soucis sur ces capteurs depuis. Pourvu que ça dure…

C’est cool que ça fonctionne bien maintenant.

En revanche, si le mode sécurisé ne fonctionne pas mieux avec ZWave-JS, c’est bof pour la sécurité ! Après, c’est peut-être l’inclusion sécurisée faite par OpenZWave qui posait souci. Il faudrait refaire l’inclusion sécurisée avec ZWave-JS pour en être certain. Remarque, je n’ai jamais réussi à faire une inclusion sécurisée sous ZWave-JS pour mes derniers modules :joy:

Récapitulons :

  • Z-Wave non sécurisé et fiablité : OUI, fiabilité excellente mais pas de sécurité
  • Z-Wave en mode sécurisé : OUI, mais pas fiable du tout avec OpenZWave et fiabilité à démontrer avec ZWave-JS.
  • Sécurité et fiabilité : OUI du WiFi par exemple, mais pas de Z-Wave !

Est-ce possible avoir du Z-Wave, de la sécurité et de la fiabilité ? :smiley:

Le jour où le wifi sera aussi secure que le zwave, ça sera une grande avancée.
Toutes les communications z-wave sont, de base, cryptées. Le mode sécurisé inclus une sécurité supplémentaire. Donc pas de souci à avoir.

Sur les module sécurisé, il indiquait un label S0_legacy ou quelque chose dans le genre. C’est peut-être un truc hérité de openZwave qui reste merdique, mais pas vu d’info dans la doc. Honnêtement, pas le courage de tester dans l’immédiat, ça marche, je ne touche plus quelques temps !

Mais par contre, je ne partage que modérément l’enthousiasme que j’ai pu lire sur zwavejs. Entre certains volets qui remontent des fausses positions malgré les règles, entre les FGMS001 en 3.2 qui ne fonctionnent pas après inclusion sans modifier le json, … Ca a corrigé des trucs sur mon installation, mais en a cassé d’autres ! Relativisons, c’est que le début du plugin !

J’ai un FGBS222 en sécu S2,
en dehors de ce produit (qui gère la porte de garage) pas vu de besoin d’activer cette fonction pour mes détecteurs FGMS ou autres.

La sécurité S2 augmente la lourdeur des com et consomme donc plus, pas super sur un simple détecteur à pile.

Concernant ZwaveJS, j’ai remarqué en effet quelques difficultés en mode sécu que j’ai quand même testé. A l’inclusion de certains modules, il ne remonte pas toujours tous (pas tous les groupes d’associations par exemple) alors que le produit est bien en état d’inclusion ‹ complete ›. Ce qui génère des soucis aléatoire en fonction de ce qui remonte à l’inclusion ou pas :slight_smile:

Bonjour

Oui j’ai également remarqué des soucis d’inclusions de modules complet en non sécurisé.
Par exemple un des FGMS que j’ai réinclus qui remontait un état présence « clignottant ». Exclusion/reset module/inclusion a résolu le soucis mais je trouve ça curieux.
De même pour un des deux détecteurs de fumée fibaro qui était bien inclus via zwavejs mais qui ne remontait rien. Même manip a remis le truc d’équerre.
A mon avis, faut bien contrôler directement à l’inclusion que tout fonctionne parce que zwavejs a l’air de créer quelques soucis.