Bonsoir,
Je tiens à préciser que le retour d’état semble fonctionner lorsque les volets sont positionnés de manière individuelle. Le positionnement simultané de plusieurs volets pose problème.
Peut-être que le problème ne provient pas du module FGR-223, mais plutôt d’un défaut dans la gestion du flux d’informations par Z-Wave JS (associé à MQTT Manager configuré par défaut dans mon cas) ?
Bonjour,
Regarde dans ce cas dans zwavejs UI ce qui est envoyé en mqtt.
Bonjour,
C’est effectivement une piste que je pourrais explorer.
Si, entre autres, le démarrage rapide de Z-Wave JS en regard de OpenZWave est une réelle évolution, le retour d’état, en tous cas pour le module FGR-223, est une régression.
Et je ne peux ni ne veux me substituer au travail des développeurs.
Bonjour,
Quand tu vas sur un module dans zwavejs UI tu peux voir directement les messages mqtt échangés. Cela te permettrait rapidement de déterminer si le problème vient de zwavejs UI ou de mqtt manager.
Sinon ouvre un ticket si tu as un pack Jeedom.
Salut,
Je n’utilise pas le plugin zwavejs mais directement zwavejs-ui+jmqtt et je n’observe pas ce soucis à première vue.
Ce que tu dis si je reformule c’est que systématiquement (ou juste parfois ?) dès que tu descends 4 volets (ça marche bien jusqu’à 3 ?) les volets descendent bien physiquement mais une fois en bas certains volets on un retour d’état variable entre 1 et 98 ?
Le vrai changement entre openzwave et zwavejs c’est que maintenant l’état passe à 0 dès l’envoi de l’action down et le nouvel état est retransmis quand le module fini son travail et le communique.
Un volet baissé à 50% va donc passer à 0 puis descendre et transmettre 50 quand il sera finalement arrivé à 50% (sa destination)
Je fais comme toi.
C’est ce que tu constates sous zwavejs-ui. A la vue d’autres discutions, je pense que le comportement de zwavejs-ui est modifié par le plugin-zwavejs.
Par exemple, pour le module Hank HKZW-SCN04, les utilisateurs du plugin-zwavejs parlent d’un retour de 4 valeurs possibles, soit 0, 1, 2 et 90. Moi sous zwavejs-ui, je n’ai que le retour de 3 valeurs possibles, soit 0, 1 et 2 puis la valeur [value] disparaît du JSON. Donc jamais de valeur 90.
Ah, OK. Étonnant d’avoir fait ça mais bon … peut-être qu’il ont cherché à améliorer le fonctionnement natif du moteur zwavejs pour certains modules si ce comportement semblait un peu étrange comme ce que j’ai décris pour les FGR-223
Comme indiqué par Madcow est-ce que tu peux ouvrir l’interface de zwavejs-ui (j’ai cru comprendre que c’était possible depuis le plugin) puis aller regarder sur le module dont l’état n’est pas remonté correctement
Dans la partie Events :
Je déclenche le down à 12:53:31 (l’état passe de 99 à 0) :
Une fois arrivé en bas à 12:53:49 le module stop et renvoi son état (état qui était à 99 et qui « confirme » être à 0) :
Si à ce niveau tu as des newValue qui ne sont pas à zéro … ça va pas le faire.
Si elles sont bien à zéro alors il y aura comprendre pourquoi et quand le passage via le plugin MQTT puis le plugin zwavejs ne remonte pas cette bonne information
Donc problème côté zwavejs UI.
Sinon un contournement (c’est ce que je fais chez moi) pourrait être de décaler les fermetures de chaque volet de quelques secondes. Car dans ce cas précis on soupçonne toujours une saturation réseau en 1er lieu (ce qui n’est peut-être pas la raison du problème au final ici).
De rien 
Je viens de lire un long sujet sur HA, et ce problème semble avoir existé il y a 1 an, avoir été corrigé, mais être revenu vers octobre sous zwavejs UI.
Plus précisément ici :
Salut
Une maj vient de sortir cette nuit pour notamment le fgr223 qui remontent mal certains état
- Modification de la configuration Fibaro FGR-223 première configuration à utiliser le moteur de refresh (en effet ce module à un bug connu, il ne remonte pas les positions ou de manières erronées lorsqu’un mouvement est initié par le Z-Wave) pour récupérer les refresh (allez dans recharger commande en choissisant “sans recréer commandes”) vous devriez voir les “refreshs” dans l’onglet options.
- Modification de la configuration Fibaro FGR-223changement des endpoints power et energy
- Modification de la configuration Fibaro FGR-223 rajout de notification hardware et over-current
- Modification de la configuration Fibaro FGR-223remplacement de la propriété scene par centralscene
Changelog pour plus de details.
Bonjour,
Je pense que c’est prématuré d’avoir cliqué sur « Solution ».
Attendons de voir si cette mise à jour résout le problème.
Salut,
C’est moi qui ai cliqué solution, tu multiplies les sujets et les posts c’est juste impossible à suivre. Le principe du forum étant d’abord de chercher si la réponse à la demande n’y est déjà présente, ensuite demander de l’aide puis clore le sujet en indiquant la solution pour les suivants qui se poserait la même question.
Bonjour,
Je viens de faire la mise à jour.
Le refresh ne fonctionne pas chez moi, ou alors je n’ai pas compris comment l’employer.
J’avais trouvé une parade en changeant dans la commande Up et Down TargetValue 99 et 0.
Bonjour,
Normalement le refresh est configuré dans le template FGR223.
Tu as quoi dans Options ?
N’étant pas l’auteur du post, ni modérateur je n’aurais pas pu cocher mon message comme solution.
Pour en revenir au sujet, as-tu pu tester?
J’ai bien le refresh dans la configuration
J’ai installé la mise à jour, fait une synchro, puis recréer les commandes.
Lorsque je lance un mouvement de volet par le « slider », le positionnement remonte bien.
Si je fais un mouvement par les buttons, le positionnement ne se met pas à jour.
Salut,
Montre tes commandes haut et bas
Elles doivent être 38/1/targetValue/0 ou 99 pour retourner le bon état.
Elles l’étaient avant la mise à jour
En recréant les commandes, il faut à nouveau changer la commande.
Dommage de faire une mise à jour, mais de devoir « bidouiller » apres.