Bonsoir a tous, j’utilise Zwavejs et depuis quelques que jour j’ai migrer de la gen5 a la gen7 et je rencontre un soucis.
Quand mon scénario pour ouverture ou la fermeture totale de tous mes volets roulant (fibaro fgr-222), physiquement il sont tous bien fermer mais sur Jeedom j’ai de mauvais retour états, et sa le fait aléatoirement sur divers volets.
Hello !
J’ai trouvé ton post resté sans réponse car je rencontre les même problèmes : j’ai migré sur ZWaveJS très récemment et je vois que quand je commande l’ouverture ou la fermeture de tous les volets en même temps (j’en ai 9), y en a souvent 1 ou 2 qui dont le retour de position ne se met pas bien à jour (soit il est resté dans son état d’avant (0 ou 99) soit parfois il est vu en état intermédiaire.
Physiquement les volets sont à la bonne position.
Ce qui pourrait nous mettre sur la voie : y avait un post similaire sur de FGR223 ici dont en gros les premiers firmware étaient connus pour ce comportement:
Qqn avait aussi évoqué ce pb ici mais resté sans réponse claire à mes yeux :
Perso je n’ai que des FGR222 en firmware 25.25.
Et de toute façon, j’ai compris que les firmware Fibaro n’étaient pas téléchargeables facilement.
Quelqu’un a t il trouvé un contournement élégant ou une solution ?
Merci beaucoup !
J’ai exactement le même problème, as tu solutionné le problème ?
J’ai constaté ce soucis après mon passage sur Luna, mais plus précisément j’ai l’impression depuis la MAJ d’une des dernières version de ZwaveJS.
Je n’avait pas ce problème sur mon ancienne box avec une aeotec zstick gen5 et une version de ZwaveJS datant de 2023 (il faudrait que je la rallume pour vérifier la version)…
Hello, non je n’ai pas trouvé de solution. Idem, jamais eu de pb avec openzwave…
Je me disais qu’il y avait peut-être un réglage de QoS (Quality of Service) qu’on pouvait paramétrer pour forcer nos équipement à envoyer plusieurs fois jusqu’à s’assurer que le message est arrivé…
Mais je n’ai pas encore creuser (cherché dans le forum ou ailleurs) donc je ne peux pas décemment demander de l’aide là-dessus !
Je suis curieux de voir la configuration de vos commandes, parce par exemple « Positionnement » ne fonctionne pas chez moi (la propriété ici est targetValue alors que dans openzwave c’était setvalue, je trouve ca bizarre …)
effectivement je n’ai que Haut et Bas qui fonctionnent pour le moment.
Je vais tenter avec un autre volet roulant pour voir si le pb vient de ce module spécifiquement
Bon, je n’ai finalement pas rencontré le problème avec aucun des mes 10 autres FGR222 … j’ai du mal à savoir ce qui se passe avec celui là ? Il y a moyen de faire un reset factory d’un module ?
J’ai eu exactement le même pb que décrit par d’autres.
Depuis la migration d’OpenZwave à ZWaveJS UI, j’avais un volet roulant FGR 222 pour lequel la remontée de l’Etat ne se faisait pas correctement. Il fallait manuellement rafraichir les valeurs des noeuds pour voir son état actuel.
Et j’ai résolu hier mon problème de manière très très simple.
J’ai modifié la valeur du paramètre Configuration V1 (112) /Reports Type (3)
Il était sur la valeur 1. (retour d’état géré par Fibaro). Je l’ai basculé à la valeur 0. (retour d’état géré par Zwave).
Depuis cette modif, aucun pb, dès que le volet change d’état, le retour d’état dans mon Jeedom est correct.
J’espère que cette petite modif de configuration aidera les autres impactés !
J’ai eu un immense espoir en voyant ton message !
Sans doute que ça améliore beaucoup la situation, mais dans mon cas, à par 1 de mes 9 volets qui était sur N/A, tous les autres étaient déjà sur 0.
Dans mon cas c’est le fait d’arrêter de tous les commander en même temps qui améliore la situation.
Max 5 à la fois, même s’il arrive quand même parfois (1 à 2 fois par semaine) qu’un état ne remonte pas correctement.
Ah zut, j’aurais bien aimé que ça soit si simple pour tout le monde !
Peut-être que les volets qui galèrent chez toi sont ceux qui ne sont pas en route directe vers le contrôleur zwave ? As-tu remarqué sur ta route de réseau Zwave s’il y a des noeuds en erreur, ou nécessitant des sauts, et que tous les équipements intermédiaires sont en bonne santé ?
Non je n’ai pas remarqué ça.
Qui plus est, parfois c’est le volet du salon qui est le plus proche du controleur dont l’état ne remonte pas bien…
J’avoue que je n’ai pas essayé de trifouiller dans les routes, j’aime à croire que le système zwave est plus malin que moi…
J’ai exactement le même problème avec une partie de mes 7 FGR-222.
Pourtant tout marchait bien il y a encore quelques temps après une migration OpenZwave vers Zwavejs.
Les changements :
mise à jour de la clef usb ZWave.me UZB du firmware 5.05 vers 5.39, en passant par des intermédiaires
mise à jour de tous mes FGR-222 en firmware 26.26 (la raison étant que cela corrige un bug que j’avais signalé alors concernant un défaut avec les interrupteurs bistables générant un recalibrage en passant trop vite entre bas/haut) depuis un 25.25 à l’aide d’une box fibaro prêtée pour l’occasion
Il m’a fallu rouvrir les boîtiers car impossible d’exclure/inclure sans appuyer sur le bouton interne (j’ai pourtant essayer d’activer up qui est branché sur S1 3 fois de suite, mais rien).
J’ai réutilisé les objets existants en changeant l’id du noeud pour m’éviter un travail fastidieux (même si j’ai cru comprendre que la fonction REMPLACER était là pour aider).
Constatant le défaut, j’ai tenté quelques commandes pour regénérer les commandes, soigner le noeud, etc, mais rien n’y fait.
Mais j’ai tous les jours 1 ou 2 VR qui remontent mal leur état dans le cas de scénario qui lance 3 ou 4 VR en même temps, alors qu’avant tout fonctionnait.
De plus, j’ai un Aeon Led Bulb 5 dont l’état alive/dead ne remonte plus bien lorsque j’éteins avec l’interrupteur. Là j’ai carrément recréé l’objet complètement, mais cela ne change rien.
J’ai du revoir un scénario où je me basais sur l’état car il ne fonctionnait plus bien.
Bref la confiance est rompue…
A noter que j’ai bien la valeur 0 - Blind position using Z-Wave command sur le 3 Reports Type.
Par contre je viens de voir que le problème s’est posé tout à l’heure sur 2 nœuds où il y a un intermédiaire au niveau du routage.
Autrement je suis étonné que le dialogue avec mqtt soit aussi bavard : à chaque fois le noeud envoie toutes ses valeurs, et non juste la propriété qui est modifiée.