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 !
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.
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
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).
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…
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
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é ?
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
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.