FGBS-222 n'a pas le bon état au reboot de Jeedom

Tags: #<Tag:0x00007fcbb09ef498>

Même soucis également sur mes 2 FGBS-222

  • Portail, pas grave, je force une ouverture/fermeture.
  • Alarme : plus grave, Change d’état Armé/désarmé ou désarmé/armé :woozy_face:

Je vais essayer de voir si je peux désactiver ces 2 scénario au démarrage et les réactiver 5mn plus tard.

Bonjour
J’ai eu le même soucis avec ce module que j’avais acheté chez Domotique Store
Il semblerait que le problème provienne de Jeedom et pas du module
La solution proposée par Domotique Store :
-Activer la l’interrogation du module toute les 5 minutes pour IN1et IN2 dans l’onglet Valeurs de la configuration du module
Ce qui veut dire que dans las 5 minutes qui suivront le redémarrage de Jeedom et du plugin Z-WAVE les états IN1 et IN2 remonteront automatiquement

Est-ce que cela a résolu le souci pour toi ?

Si tu regardes mes messages précédents, je doute que cela règle le problème car c’est le module qui ne maintient pas son état.

Je ne sais pas car la solution ne me convenait pas et j’ai retourné le module chez Domotique Store …

Alors pour commencer mon fgbs est alimenter avec une alim,comme ça
le fgbs et à 25m de la clé z-wave mais il et router par un module qui lui est à 35m (bizarre )
je suis en inclusion non sécurisé .
Je suis sur RPI b3+ sous en 4.0.61 Rasbian gnu/linux 9 (stretch)32bits
Sur le module, tu as quoi au niveau « Libray Version »et « Protocol Version » :
image

Tu pourrais nous faire une copie écran des paramètres de ton module ?
image

![i![image|590x218](upload://vRDu754bswlgrZAjpKOR18OaEWw.png)
image
image
image
Au niveau Zwave, tu as quelle version du plugin ?
image

Merci pour les infos. Je vais comparer avec ce que j’ai.

à première vue j’ai bien la même configuration et la même version d’OpenZwave.
Même version de Jeedom.

Je note par contre que les libellés ne sont pas exactement les mêmes chez moi.
image
« Unprotected » contre « No Operation Possible »

J’ai aussi les mêmes paramètres sur le module avec une VM buster 4.0.61 mais une version de plugin plus ancienne.

Pour le mode de protection, je suis aussi en « No Operation Possible ». C’est le paramètre qui permet de dissocier les entrées des sorties.

J’ai fait des tests avec une box Fibaro et le problème ne se pose pas, mais bon, j’ai envie de dire que c’est encore heureux avec deux produits Fibaro. En revanche, pas possible de voir quoi que ce soit sur leur box pour comprendre comment cela fonctionne. Tout est fermé.

En revanche, on peut voir dans cet article qu’il semble exister des paramètres cachés pour les associations.

<!--  Association Groups  -->
<CommandClass id="133">
<Associations num_groups="14">
<Group index="1" max_associations="1" label="Lifeline"/>
<Group index="2" max_associations="5" label="Input IN1"/>
<Group index="3" max_associations="5" label="Input IN2"/>
<Group index="4" max_associations="5" label="Analog Input 1" auto="false"/>
<Group index="5" max_associations="5" label="Analog Input 2" auto="false"/>
<Group index="6" max_associations="5" label="Output 1" auto="false"/>
<Group index="7" max_associations="5" label="Output 2" auto="false"/>
<Group index="8" max_associations="5" label="Temp internal" auto="false"/>
<Group index="9" max_associations="5" label="Temp external sensor 1" auto="false"/>
<Group index="10" max_associations="5" label="Temp external sensor 2 or humidity 1" auto="false"/>
<Group index="11" max_associations="5" label="Temp external sensor 3" auto="false"/>
<Group index="12" max_associations="5" label="Temp external sensor 4" auto="false"/>
<Group index="13" max_associations="5" label="Temp external sensor 5" auto="false"/>
<Group index="14" max_associations="5" label="Temp external sensor 6" auto="false"/>
</Associations>
</CommandClass>
<CommandClass id="142" ForceInstances="true"/>

Mais cela ne change en rien le comportement des entrées du module.

Néanmoins, cela permet d’apporter des améliorations au module.

En ajoutant ces associations (6 et 7), le retour d’état des sorties fonctionne sans avoir besoin de rafraichir manuellement.

Idem pour la remontée de température interne, elle remonte bien en fonction du paramètre 65 sans avoir besoin de rafraichir manuellement. Je n’ai pas essayé avec une sonde de température externe mais on peut penser que cela fonctionnera aussi.

J’ai également essayé en passant les entrées en mode Analogique. Les changement de tensions remontent bien grace aux associations 4 et 5 mais malheureusement, il y a un délai jusqu’à 10-15 secondes comme l’indique l’auteur dans son article. Parfois cela peut être moins, mais ce n’est pas instantané. Dommage, car cela aurait pu être une solution pour avoir le bon état des entrées au reboot.

En revanche, en relisant la doc du module, on peut voir que celui-ci supporte les scènes. En configurant les entrées en monostable et en configurant les paramètres 40 et 41 à 8 on peut donc récupérer les évenements « Key Hold Down » et « Key Released » qui correspondraient finalement à deux états binaire. La valeur du paramètre « Scene » étant seulement envoyée par le module et pas lu, la valeur est donc maintenue lors d’un redémarrage du plugin ou de Jeedom. L’inconvénient de cette méthode est que si les entrées changent d’états pendant le redémarrage du plugin/jeedom, l’état ne sera pas correcte mais ce ne serait vraiment pas de bol que le portail s’ouvre ou se ferme au même moment. Et de toute façon, avec la configuration classique, on est sur que l’état ne sera pas correcte à chaque fois lors d’un reboot. Ca diminuerait donc les chances d’avoir un mauvais états des entrées. Reste à vérifier maintenant que cela ne pose pas problème en fonctionnement « normal ».

Je crois avoir compris. C’est le paramètre Burglar qui prend la valeur 254 au premier réveil du module après le redémarrage du réseau Z-Wave.

:laughing: Moi c’était

Puisque mes modules se réveillent toutes les 6h, actuellement, la parade est de fermer toutes les portes pendant les 6 premières heures après le redémarrage du réseau Z-Wave.
Je le fais de préférence la nuit, mais c’est pénible et surtout pas normal.

La solution est d’ignorer cette valeur 254. Explications ici

Ben, comme il y a une couille dans l’implémentation d’openzwave, on retrouve ce problème sur plusieurs modules et sur plusieurs plateformes (Jeedom, openhab, Home Assistant). Donc, Fibaro a raison de dire que ça ne vient pas de chez eux.

En effet, c’est ce que j’avais remonté ici.

254 pour l’entrée 1 et 255 pour l’entrée 2.

Salut,

Merci pour le retour donc si je résume dans la configuration de « État entrée 1 » il faut mettre :
254 dans la valeur interdite ?

Ainsi au reboot l’entrée 1 aura un bulgar de 254 et comme cette valeur est interdite elle ne sera pas prise en compte.
A la prochaine ouverture du portail ça passera à 1 puis à 0 et ça roule ?

J’ai l’impression qu’il me manque un truc puisque tu faisais un calcul #value#-22 pour ton module ?

Oui

Pas tout à fait, pour éviter que la valeur 254 soit bien prise en compte dans les valeurs ignorées, il faut mettre le type en « Numérique »
image

Cette expression était pour les module de portes qui prenait l’info sur le paramètre Access Control.
Ici, pas de calcul. Tu auras 255 ou 0 et la valeur 254 sera ignorée

Si tu voulais vraiment avoir 1 ou 0 en sortie (mais tu n’auras pas le wigdet du Binaire), il faudrait rajouter dans la Formule de calcul (#value# pour la valeur) : #value#/255 et mettre en Valeurs interdites (séparées par ";") : 254/255 ou 0.996078431372549

  • 255 -> 1
  • 254 -> 254/255 (valeur ignorée)
  • 0 -> 0

À tester

1 J'aime

Ok merci, je m’appuie sur un virtuel pour voir mes états du coup ça ne mettra rien en l’air en passant en numérique.

J’ai donc passé l’entrée 1 en numérique et interdit la valeur 254.

Je fais un reboot demain matin pour voir ce que ça donne

EDIT : C’est ok, la valeur de l’entrée 1 reste bien à 0 après le reboot de Jeedom en interdisant la valeur 254 et en passant en numérique à la place de binaire

Merci beaucoup @Domatizer :grinning:

Bonne nouvelle ! 2021 commence bien :smiley:

Maintenant, je suis convaincu que tout le monde (utilisant openzwave) a ce problème de valeur inconnu à 254 avec la classe 113 (Alarm) pour certains modules lors du premier réveil après le redémarrage du réseau. Avec les modules sur piles, ça rajoute un petit côté aléatoire. :smile:

C’est juste qu’en fonction de l’utilisation du module, on ne s’en aperçoit pas.
@Bison Si ton portail était toujours ouvert par défaut, tu n’aurais pas vu le problème.
Moi, j’ai vu le souci sur les module de portes intérieures qui se fermaient toutes seules alors qu’avec mes fenêtres fermées à 99.9% du temps, je n’aurais strictement rien vu.

À qui faut-il remonter ce problème sachant que la version 1.4 d’openzwave n’est plus supportée ?

Merci @Domatizer :smiley:

Voici ce que cela donne de mon côté pour l’entrée 1 : Les valeurs valides étant 0 et 2.

En conservant le type binaire,

image
j’ai configuré ceci

image

En revanche, pour l’entrée 2 c’est une autre histoire. Elle n’utilise pas la même classe (32/1/0 au lieu de 113/1/10). Les valeurs valides sont 0 et 255 mais 255 correspond également à un état inconnu :woozy_face:

EDIT : Pour que cela fonctionne aussi avec l’entrée 2 en la passant également en numérique, il faut aller modifier le paramètre 52 qui est à 255 par défaut en le passant à 1 par exemple.

image
Du coup, on se retrouve bien avec 3 états : 0, 1, 255(redémarrrage) et on peut mettre 255 en valeur interdite. :grin:

1 J'aime

Attention il a indiqué qu’il fallait passer l’information en numérique sinon la valeur interdite n’était pas prise en compte.

Ah oui, en effet. Oups … la valeur interdite n’est pas prise en compte en binaire.

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.

Ou simplement mettre #value#==255 dans le calcul, ou #value#==23 pour l’autres exemple, en restant avec une commande binaire.

1 J'aime