Merci du retour.
Pour la classe 37 ca ne semble pas fonctionner :
J’ai loupé quelque chose?
Bonjour,
Là je suis à court d’idée.
Re-tenter maintenant que tout est d’équerre une exclusion/inclusion ? Sinon je ne sais plus trop quoi proposer.
Voilà les commandes qui sont accessibles et qui fonctionnent chez moi. Tu devrais les avoir dans les valeurs du nœud et tu peux les créer à partir de cette fenêtre.
targetValue false pour descendre et true pour monter.
@Madcow merci pour ton aide, la reinterview est censé réinterroger et recréer les commandes du nœud comme lors de l’inclusion mais j’essaierai de le supprimer pour l’inclure à nouveau au cas où.
Je suis tout à fait d’accord avec ça. Mais bon on ne sait jamais ça peut faire tomber en marche 
Merci. Effectivement ça fonctionne.
J’ai ouvert un ticket pour voir si l’équipe Jeedom a une solution ou connait le problème.
Ok super, si tu peux nous tenir informé d’une éventuelle solution ça serait chouette.
Hello, je tente moi aussi de passer sur zwavejs, et je rencontre le même problème avec mes 3 FGRM-222 (firmware 22.22), avec les mêmes vérifications/symptômes que Choukajohn et mnementh.
A noter : j’ai aussi des 4 FGR-222 (firmware 25.25) qui n’ont posé aucun problème.
Je suis donc aussi très intéressé par le retour de l’équipe Jeedom !
Salut,
Information très intéressante, cela pourrait donc venir de la version du firmware, malheureusement impossible de mettre à jour le firmware des modules sans une box fibaro… Ce qui permettrait de confirmer l’hypothèse.
En fait, je pense surtout qu’il s’agit d’une différence de prise en charge entre FGR-222 et FGRM-222
Oui tu as probablement raison, apparemment les FGRM222 correspondent à une version antérieure aux FGR-222.
Bonjour,
C’est ce que je disais plus haut : FGR222 (shutter 2) parfaitement opérationnels. Le problème semble exister uniquement sur les Fgrm222 (shutter 1).
Merci Fibaro pour avoir décidé de noms aussi proches alors que ce ne sont pas les mêmes modules (ce n’est même pas une question de FW) …
Attendre le retour du ticket de @mnementh …
Evidemment
Bonjour,
Je rencontre également des problèmes similaires à ceux évoqués ici. Je possède des FGRM-222 et des FGR-222, j’ai procédé à l’inclusion de tous sans difficulté, les FGR-222 sont pleinement fonctionnels mais pas les FGRM-222, pour lesquelles les commandes de la classe 38, pourtant bien créées par Jeedom, ne sont pas renvoyées par Zwavejs et n’apparaissent pas dans les valeurs du noeud.
Quelques constats :
- lorsque je lance une nouvelle interview du noeud, zwavejs ne remonte aucune donnée pour la classe 38
- à l’usage du volet (calibration, qui fonctionne, ou utilisation d’interrupteur/télécommande), la valeur « currentValue » remonte et zwavejs l’ajoute dans la classe 38, mais pas les autres (targetValue, Open, Close…). Je peux donc voir l’état du volet, mais pas le commander
- la propriété « fibaro-venetianBlindsPosition » (classe 145) avec le paramètre #slider# permet de commander le positionnement du volet, à la place du 38/0/targetValue/#slider#
- les commandes de classe 37 permettent de faire monter et descendre le volet (37/0/targetValue avec paramètres false pour descendre et true pour monter), mais pas d’option « stop »
J’arrive donc à bricoler ainsi, mais c’est pas très pratique.
A noter aussi que j’ai un interrupteur Fibaro Walli Controller Zwave (sur pile, aucune connexion filaire) que j’ai inclus dans Jeedom et associé au volet en mettant le volet dans l’association groupe 6-Multidevice du Walli controller. L’interrupteur fonctionne complètement : il communique bien avec le volet, monter, descendre, positionnement intermédiaire et le stop fonctionne. Idem avec une télécommande zwave associée elle aussi au volet.
Le problème semble donc venir de la communication ZwaveJS-moduleFGRM222. ZwaveJs-UI n’apporte pas d’information supplémentaire, on n’y voit rien dans la classe 38, des re-interview ou des refresh ne changent rien. Pourtant l’interrupteur Zwave arrive à communiquer avec le module, donc les informations et commandes doivent être quelque part.
Ah j’ajoute une dernière information : ce problème est survenu chez moi hier, alors que je venais de migrer d’un Razberry sur mon RPI (ZwaveJS) à une clé USB Aeotec Z Stick 7 (via exclusion-inclusion) ZwaveJS également. Avant, sur le Razberry, mes volets fonctionnaient sans bricolage ! Mais je ne pense pas que le problème soit lié à la clé. Sur le Razberry, l’inclusion et l’interview du module datait de plusieurs années, et avait été faite à l’origine sous le plugin Zwave de Jeedom, avant de passer au fil du temps sous Openzwave, puis ZwaveJS. Le module fonctionnait donc peut être correctement avant sur mon Razberry car il avait d’abord été correctement intégré au réseau zwave avant le passage à zwaveJS. Je soupçonne plutôt un problème du côté de la communication ZwaveJS-FGRM222 lors de l’interview, soit le ZwaveJS interprète mal les données soit le FGRM222, assez ancien, envoie les données de manière un peu trop « exotique » …
Merci pour ton retour.
De mon côté je n’ai toujours pas de retour du suivi de mon ticket par Jeedom.
@Loic : comment savoir si ce ticket est bien pris en charge SVP?
Bonjour
Il est toujours pris en compte et si c’est sur gsh alors tu as eu un retour j’ai aucun ticket en attente. Regarde tes spams par exemple. Attention aussi pour les mails avec free ils ont une tendance à les supprimer directement sans raison
Merci pour ton retour.
Exactement les mêmes constats de mon côté.
la propriété « fibaro-venetianBlindsPosition » (classe 145) avec le paramètre #slider# permet de commander le positionnement du volet, à la place du 38/0/targetValue/#slider#
J’avais essayé cette commande mais sans succès, je vais me repencher dessus voir si j’arrive à bricoler aussi.
Merci pour le retour.
J’ai bien vérifié dans les spams mais je n’ai rien.
Le ticket a été dépose le samedi 22 juin.
Je suppose qu’il faut encore attendre …
j’ai mis ces commandes :
Ca fonctionne ici … mais « à peu près ». Parfois, les commandes ne marchent pas, sans explication particulière. Et remarchent après, après quelques manipulations qui semblent « réveiller » le module. Bizarre pour un module alimenté directement. A ce propos, un autre point que j’avais pas noté, c’est que ZwaveJS lors de l’interview ne semble pas toujours identifier le type d’alimentation des FGRM222. L’alim est notée comme « inconnu » dans ZwaveJS-UI, et le module en statut « Asleep » :
ce qui n’est pas le cas de mes FGR222, bien identifiés comme étant sur secteur et donc toujours statut « Alive » :
C’est un ticket zwave ou gsh ? Je veux bien essayé de te renseigner et de t’aider mais il faut détailler ? Déja que faire passe plat comme ca j’aime pas je prefere passer du temps a corriger les bugs mais si en plus vous faite rien pour aider c’est toute la communauté que tu penalises au final…
J’utilise bien les commandes en 37 mais elles fonctionnent toujours je n’ai pas le problème du module en Asleep comme tu as.