Petit up aussi! 
1 « J'aime »
Bonjour,
idem petit Up, j’aimerais pouvoir bénéficier du retour d’état sur Q2 lors d’un déclenchement depuis l’interrupteur
Bonjour à tous,
Après avoir cherché a résoudre ce problème d’état de Q2, voici ce que j’ai trouvé.
La configuration du fichier /var/www/html/plugins/openzwave/resources/openzwaved/config/fibaro/fgs224.xml n’est pas bonne.
Il faut modifier les classes 96 et 142 comme ceci :
Ensuite aller dans la configuration du module:
« configuration > actions > régénérer la détection du nœud »
Le réseau zwave va redémarrer.
Ensuite retourner dans la configuration du nœud et modifier les commandes pour on 2 off 2 et état 2
définir l’instance sur 2 à la place de 3.
Vérifier pour finir le groupe d’association de la lifeline qui doit être sur Jeedom UZB Z-Wave USB Adapter (Instance: 1)
Après vous devez avoir le retour de Q2 qui fonctionne.
Attention, si vous refaites par la suite un « confis modules » dans la configuration zwave, cela va effacer la modification dans le fichier xml et reproduire le problème sur les nouvelles inclusions de FGS224.
Par contre j’arrive toujours pas à inclure en mode sécur 
Voila si ca peut vous aider, bonne config a vous,
Styfun
Bonjour @styfun,
Merci de ton partage, je viens d’essayer ta méthode qui permet de façon relativement aléatoire de récupérer le retour d’état. Par contre cela se fait au détriment d’autre commande et notamment les scenes.
J’ai cherché sur Github et essayé plein de combinaison sans aboutir à un résultat notamment :
<CommandClass id="96" mapping="endpoints" forceUniqueEndpoints="true"/>
<CommandClass id="142" ForceInstances="true"/>
Pour la partie sécurisé, c’est hyper aléatoire et en répétant les procédures de Nechry, cela fonctionne à la fin.
https://nechry-automation.ch/2018/01/23/inclusion-securise/
Vivement que quelqu’un de qualifié se penche dessus.
Le fichier xml du module est disponible ici si quelqu’un se sent d’attaque :
https://products.z-wavealliance.org/Products/3980/XML
Salut @HpNoTiQ,
Je pense que le mieux c’est de réécrire le fichier de configuration. Le fichier qui est utilisé dans Jeedom est pour la version 1.6 d’openzwave hors Jeedom est en 1.4.
Sur Github dans le dépôt openzwave, ils expliquent bien comment faire. Le truc c’est qu’a mon avis ils vont pas nous aider sur le version 1.4.
De mon côté le comportement est fiable mais je n’utilise pas les scènes.
Je pense que tu peux regarder le contenu de la CommandClass id=« 112 » qui liste les paramètres du module. Il y a des erreurs et il manque des paramètres (J ai comparé avec la doc Fibaro).
Tu peux aussi supprimer toutes les balises MetaData au début, dans la version 1.4 elles ne servent a rien, voir elles posent peut être un problème.
Je vais faire un test de mon côté.
@plus
Pour les scènes j’ai ajouté ca dans la commandclass 112
<Value genre="config" index="40" instance="1" label="S1 input - scenes sent" max="15" min="0" size="1" type="byte" value="0">
<Help>
This parameter determines which actions result in sending scene IDs assigned to them.
1 - Key pressed 1 time.
2 - Key pressed 2 times.
4 - Key pressed 3 times.
8 - Key Hold Down and Key Released.
Default setting: 0 (none)
</Help>
</Value>
<Value genre="config" index="41" instance="1" label="S2 input - scenes sent" max="15" min="0" size="1" type="byte" value="0">
<Help>
This parameter determines which actions result in sending scene IDs assigned to them.
1 - Key pressed 1 time.
2 - Key pressed 2 times.
4 - Key pressed 3 times.
8 - Key Hold Down and Key Released.
Default setting: 0 (none)
</Help>
</Value>```Bonjour à tous,
Comme bien d’autre, j’arrive sur ce fil avec beaucoup d’intérêt car je rencontre le même problème d’impossibilité de lire le retour d’état de Q2.
En revanche je suis depuis le début en inclusion sécurisée. J’ai lu sur un autre forum que ça pouvait être le soucis et qu’il valait mieux rester en non-sécurisé. J’essayerai si personne n’a réussi à un résultat en mode sécurisé.
Donc pour ma part, avant de modifier le fichier de config comme suggéré plus haut, je ne voyait aucun paramètre.
En suivant les conseils de @styfun j’ai modifié comme suit:
<!-- -->
<CommandClass id="96" mapping="endpoints"/>
<!-- <Compatibility>
<MapRootToEndpoint>true</MapRootToEndpoint>
</Compatibility>
</CommandClass> -->
<!-- Association Groups -->
<CommandClass id="133">
<Associations num_groups="3">
<Group index="1" label="Lifeline" max_associations="1"/>
<Group index="2" label="On/Off S1" max_associations="5"/>
<Group index="3" label="On/Off S2" max_associations="5"/>
</Associations>
</CommandClass>
<CommandClass id="142" ForceInstances="true"/>
<!-- <Compatibility>
<ForceInstances>true</ForceInstances>
</Compatibility>
</CommandClass> -->
Puis après une régénaration du noeuds, je n’ai pas eu à remettre l’instance des commande On 2, Off 2 et Etat 2 à 2 car l’instance n’avait pas changé.
Ensuite j’ai récupéré des paramètres. Je dis des car il en manque certains (le 151 par exemple qui définit le type de sortie Q2. Cependant elle doit être sur son réglage usine à 0 donc utilisation normale qui me convient.
Comme le retour d’état ne fonctionne toujours pas chez moi (absence de retour, donc ni un 0 ni un 1), j’ai quand même tenté un ajout de paramètre manuel 151 (value = 0, taille = 1).
Mais sans succès.
Voilà où j’en suis, si quelqu’un a fait des progrès je suis tout ouïe.
Merci à vous
Un truc qui me parait bizarre quand je compare les valeurs de mon FGS224 avec celles de mon FGS222:
Sur FGS222 (dont les 2 relais fonctionnent bien):
Sur mon FGS224 qui merdouille du Q2 (jeu de mot):
Donc sur le FGS224 j’ai bcp plus de valeurs mais le n’ai pas d’instance 2 d’une valeur switch. Ce serait pas ça le problème ?
Le truc c’est que j’ai aucune idée comment pousser plus loin l’investigation.
Donc si qqn y comprend qqch…
Merci à vous !
Salut,
Je partage ton avis sur le fichier config qui est incomplet et pas dans la bonne version d’OZW (1.6)
J’avais rajouté les scenes 40 et 41.
Je viens de passer 4h à essayer de lire les fichiers openZwave et tenté plein de paramètre sans y arriver.
J’en suis au 30ème appairage… D’ailleurs si quelqu’un sait s’il est possible de supprimer des noeuds exclus du contrôleur cela m’aiderait.
J’ai tout de même trouver une solution : il vous suffit de créer une nouvelle commande nommée refresh et une commande scene.
Ensuite, vous allez dans les paramètres avancées de la commande scène :
La réception par Jeedom d’un appui simple sur l’entrée S2 demandera la rafraichissement de son état!
Bref, que du bonheur!
Salut à tous,
Essayant sans succès depuis un moment de faire fonctionner le contact Q2 sur mon FGS-224, j’ai lu avec beaucoup d’attention cette discussion (ainsi d’ailleurs que toutes les autres traitant du même sujet que j’ai pu trouver sur ce forum). Je pense aussi avoir essayé de mettre en œuvre toutes les solutions proposées par les uns et les autres, malheureusement sans succès.
Comme le mentionne plus haut @TonioBDS, il manque chez moi dans les valeurs une deuxième instance de switch :
Or comme le mentionne la documentation Jeedom
Le « mapping » des commandes est entièrement basé sur ces informations. (les valeurs, donc).
Dans mon cas tout du moins (et celui de @TonioBDS) il me semble qu’il n’y a aucune chance de faire fonctionner Q2 tant que cette deuxième instance de Switch n’apparait pas.
Là où je m’interroge (pardonnez-moi si je suis à côté de la plaque, je débarque complètement dans ce domaine des fichiers XML de config d’OpenZWave), c’est qu’il ne me semble pas y avoir de section du fichier de config fgs224.xml qui décrit les valeurs. Selon http://wiki.micasaverde.com/index.php/ZWave_Command_Classes (pour autant que ce soit une bonne référence), la commandClass 112 décrit les paramètres (on a vu qu’on pouvait rajouter ceux qui manquent tels le 151, 40, 41), la commandClass 133 décrit les groupes d’association. Pas de bons candidats donc. Restent les commandClass 96 (COMMAND_CLASS_MULTI_INSTANCE) et 142 (COMMAND_CLASS_MULTI_INSTANCE_ASSOCIATION) qui ont l’air de pouvoir jouer un rôle dans la gestion des instances. D’où certainement la proposition de @styfun de faire des corrections au niveau des attributs de ces éléments (mapping=« endpoints », ForceInstances=« true »). Ces modifications n’ayant pas eu pour moi l’effet escompté, je me demande à quoi correspondent ces attributs. Est-ce qu’ils déclenchent un processus de détection des instances disponibles? Est-ce qu’ils font appel à un autre fichier de configuration pour savoir quelles instances mapper? Quelqu’un peut-il éclairer ma lanterne à ce sujet?
Up !
Quand même dingue de ne pas avoir un support sur ce module commun !
Est-ce que le plus simple ce n’est pas l’upgrade de OZW ??
Bonjour à tous
Je comprenais pas le comportement de mon FGS-224 et je découvre ce feed.
Je me joins à la liste des désespérés 
Est-ce que certains ont réussi à progresser ? Ou savent vers qui il faut se tourner pour faire avancer le dossier ?
Merci pour vos partages
Ne trouvant pas plus d’infos ailleurs, j’ai ouvert une demande de support auprès de l’équipe Jeedom. Je vous tiens au courant quand j’ai un retour.
Merci c’est sympa. Je ne l’avais pas fait et pourtant ça m’intéresse aussi ! Donc encore merci !
Hello, des news du support du coup?
Bonjour,
j’ai un module fgs224 connecté. J’ai bien le retour Q1, Q2, en revanche aucune info sur la conso…
Dans les paramètres du module, je n’ai pas la classe 50 alors que dans les paramètres du module, je vois que la puissance est reliée à cette classe …
L’affichage de la puissance fonctionne chez vous ?
Merci.
PS : je viens de cliquer sur recharger configuration de ce module (juste créer les supplémentaires), ben les paramètres puissance et conso ont disparu !
et en plus maintenant Q2 ne marche plus !!!
J’ai repris la sauvegarde de cette nuit, Q2 est de nouveau fonctionnel avec retour d’état …
Salut tout le monde, désolé pour l’absence de retour, cela tient au fait que j’ai du attendre longtemps pour avoir une réponse du support technique, réponse qui malheureusement n’a pas aidé…
J’ai donc relancé le support technique pour mieux comprendre à quoi tient le problème, sans réponse à ce jour. Je vous tiens au courant…
Voici la réponse si ça vous intéresse :
Bonjour. Ce problème est connu. Et est normalement résolu avec les dernières confs (synchroniser conf sur la page du plugin). Il faudra peut etre exclure et reinclure le module (ou aller sur sa page confgi et cliquer sur redecouvrir). Cependant selon les firmwares il se peut qu’il y ait encore des soucis notamment au niveau du retour d’état du canal 2. Cordialement, Ludovic
Et le message que j’ai envoyé pour avoir plus d’informations :
Bonjour,
Merci pour votre réponse, et désolé pour le délai de ce retour, j’ai eu un peu de peine à trouver un moment suffisamment long pour tester tout cela.
J’ai suivi vos instructions (captures d’écran ci-dessous pour m’assurer que je vous comprends bien car je ne retrouve pas exactement les termes que vous utilisiez dans Jeedom) :
1. synchroniser conf sur la page du plugin
*2. exclure et réinclure le module *
3. aller sur sa page config et cliquer sur redecouvrir
Aucune de ces opérations n’a amélioré les choses. Le contact Q1 fonctionne parfaitement (pilotage par le bouton sur S1, pilotage depuis Jeedom), alors que le contact Q2 fonctionne uniquement via pilotage par le bouton S2 (Les commandes On 2 et Off 2 envoyées par Jeedom n’ont pas d’effet, la commande Etat 2 renvoie une chaine vide).
Les valeurs affichées dans Jeedom ressemblent toujours à ceci (Il semble toujours manquer les valeurs représentant le 2ème contact du module) :
Au niveau des paramètres, cela semble plus complet, mais à mieux y regarder il devrait certainement y avoir un paramètre 151 qui serait l’équivalent pour le deuxième canal du 150 (les paramètres en lien avec 150 selon la description à droite ont tous un équivalent pour le deuxième canal, ce qui confirme donc l’idée qu’il doit y avoir un paramètre 151) :
Quand vous dites : selon les firmwares il se peut qu’il y ait encore des soucis notamment au niveau du retour d’état du canal 2, je ne comprends pas bien ce que cela signifie :
• Est-ce que le firmware Fibaro est incorrect et le module doit être mis à jour ? Dans ce cas pouvez vous me dire jusqu’à quelle version le problème est présent, respectivement à partir de quelle version il est corrigé ?
• Même si le module a un problème de firmware, il me semble curieux que cela ait une influence sur le fait que sa représentation dans Jeedom est incorrecte (ce que je suppose au vu des valeurs ci-dessus qui ne mentionnent pas de 2ème switch/button/etc.). Comme je le comprends Jeedom se base sur des fichiers de description des modules, qui sont indépendants de la version du firmware dudit module. Pourriez-vous m’expliquer un peu plus en détail à quel niveau cela coince exactement ?
• Comment puis-je trouver la version du firmware de mon module FGS-224 ? Est-ce l’une des valeurs affichée sous Systèmes ?
Merci d’avance pour votre aide, cordiales salutations,
1 « J'aime »
Salut tout le monde,
Les développeurs jeedom vont discuter le cas en réunion ce vendredi pour savoir si c’est bien un problème de fichier de configuration.
Je vous tiens au courant quand j’ai leur retour.
@+
1 « J'aime »
Cool, merci pour les informations