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

Tags: #<Tag:0x00007fcbabd9b790>

Bonjour,

Et tu n’as pas actionné ton portail « pendant le reboot » on est d’accord? sinon le plugin n’aura évidement pas reçu l’info et cela expliquerait pourquoi tu n’as pas la bonne valeur.

Non bien sûr je n’ai pas actionné le portail :slight_smile:

Ben après reboot envoie une commande ouvre suivie d’une commande ferme …

Bonjour,

J’ai constaté le même phénomène. Il faut un changement d’état de l’entrée pour que la valeur devienne exacte.

Après le reboot tu es sur que tu as bien attendu la fin du redémarrage de ton zwave dans l’état de santé ?
Comment jeedom si le protocole n’est pas du i de charge peut déjà fournir des valeurs ?
Dans le processus de démarrage on arrive sur le dashboard avec des modules et des valeurs affichées alors que le service n’est pas lance comment c’est possible et ne pas provoquer des risques d’erreurs ?

J’ai constaté la même chose mais cela ne semble pas dû ni au reboot, ni au redémarrage du plugin Zwave mais au comportement du module.

Pour le moment, je n’ai pas trouvé de solution de contournement (à part ouvrir/fermer le portail après un redémarrage mais ce n’est pas « propre »).

Voici la réponse que j’avais eu de la part du support Fibaro :

Unfortunately i think this can be related to the integration created by Jeedom.
I cannot reproduce that situation on here because we do not have a Jeedom controller.

There is no way to force the device to keep inputs values, it should be kept anyway.

In Home Center there is no situation like that.

I am sorry for inconvenience.
1 J'aime

Même si c’est pas top, on en arrive bien a la même chose …

Bon et bien merci pour vos réponses et donc à l’impossibilité de régler le bug :disappointed_relieved:

Je voulais déjà vérifier que je n’avais pas fais d’erreur de configuration par exemple.

1 J'aime

Hello,
Je n’avais pas trouvé ce post lors d’une première recherche, j’ai le même problème

Je me suis habitué malheureusement, quand je reboot Jeedom je préviens la famille : « pas d’inquiétude vous allez entendre le son du portail qui s’ouvre, je reboot Jeedom » :sweat_smile:

1 J'aime

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.