Fibaro FGBS-222 - Premier déclenchement alarme ne remonte pas

Tags: #<Tag:0x00007fcbb2bd9b58>

Bonjour,

Je suis sous Jeedom 3.3.53 avec un module FGBS-222 sur lequel est connecté un sabot détecteur d’ouverture de porte de garage (branché sur IN2/GND, même comportement sur IN1) et un DS18B20. Inclusion en non sécurisé, la version sécurisée fonctionne très mal chez moi.

Le capteur de température fonctionne bien (en polling toutes les 5 minutes, dommage) et le sabot aussi, à une exception près: la première remontée d’ouverture après mise en route du module ne fonctionne pas. Je suis obligé de faire une ouverture puis une fermeture du capteur, ensuite toutes les alertes fonctionnent et remontent immédiatement.
J’ai essayé de jouer en « inversant » l’état d’entrée dans Jeedom ainsi que passer en « normally open input », sans succès.

Je joins une capture d’écran de mes paramètres. Si quelqu’un a une idée ce serait très volontiers, merci!

Annotation 2020-11-09 091508

Annotation 2020-11-09 090318-2

Annotation 2020-11-09 090318-3

Bonjour,

Qu’entends-tu par « après mise en route du module » ? Si c’est suite au redémarrage du Zwave, j’ai le même souci. Voir ci-dessous.

Merci @arnog23 pour ta réponse rapide! Je parle de la mise sous tension du Fibaro, pas côté Jeedom.
Toutefois, ta solution me donne une idée: peut-être dois-je forcer une mise à jour des valeurs par scénario lorsqu’un wakeup est détecté ?

As-tu essayé de faire un refresh manuel de l’input après le démarrage du Smart Implant. J’ai envie de dire que Jeedom ne peut pas deviner l’état si le module ne lui indique pas.

Néanmoins, comme indiqué sur le post que j’ai mis en lien, le Smart Implant ne semble pas maintenir son état. Donc, même si tu rafraichis manuellement, ce n’est pas sur que tu obtiennes le bon état.

As-tu essayé un démarrage du Smart Implant avec le sabot ouvert plutôt que fermé pour voir s’il y avait une différence de comportement ?

Pour le WakeUp, s’agissant d’un module secteur, il n’y a pas de paramètre de WakeUp sur ce module.

Il semble en effet que nous ayons le même souci. J’ai essayé ton idée avec le sabot ouvert par défaut: ça fonctionne, mais je sais pourquoi: comme tu l’indiques dans ton autre post, la valeur n’est pas correcte au démarrage. La valeur « Basic » est sur 255 au redémarrage du module (ouvert) si je force un refresh, peu importe la position du capteur!
J’en déduis que le Fibaro est incapable de connaître l’état du module sans un aller-retour manuel du capteur, et indique donc 255 par défaut.
C’est assez grave, car si j’ai une coupure de courant (imaginons sans onduleur, ou trop long), l’alarme me fera une alerte alors que tout va bien.
Est-ce que tu as trouvé une parade ?

Non, pas de parade malheureusement :frowning:

Peut être un truc à essayer avec la valeur de tension de l’entrée qui elle est peut être correcte tout le temps mais je ne suis pas sur qu’elle remonte automatiquement sans refresh. A tester.

Haha, j’ai pensé exactement à la même chose! Malheureusement j’ai 0V dans tous les cas… Merci cela dit!

J’ai bien des tensions différentes entre mes deux entrées. Une est ouverte et l’autre fermée.

image
image

En revanche, je vois que je n’ai pas de date de refresh pour l’entrée 1 ni même le bouton pour le forcer d’ailleurs …

Pour info, la réponse que j’avais eu de la part de Fibaro …

Il faudrait que je fasse le test avec une box Fibaro pour comparer le comportement et verifier ce que dit Fibaro mais je n’ai jamais pris le temps de le faire.

Il faut espérer que la nouvelle version du plugin Zwave (quand elle arrivera) permettra de corriger cela …

Très intéressant, merci pour les infos! Pour ma part j’ai bien un bouton de refresh pour les deux Voltage, étrange. J’ai d’ailleurs parlé un peu vite: en forçant le refresh de la valeur du Voltage de IN2, j’ai bien +10V lorsque j’ouvre le sabot, même la première fois. « Basic » reste à zéro, par contre. J’avais 255 avant, j’ai du mal à comprendre!
Merci pour le quote de Fibaro, bon à savoir aussi.
En workaround pas propre, je pourrais guetter la dernière communication du module et forcer la lecture du Voltage, et ignorer la valeur de Basic si cela ne correspond pas au bon voltage.
Un peu galère quand même :grin:

Bonjour,

Je me permets de reprendre ce fil car j’ai également le même souci avec mon FGBS-222.
J’avais pris contact à l’époque avec Fibaro qui ne comprenait pas le problème. A l’époque, je n’utilisais pas Jeedom mais OpenHAB, donc le souci vient bien du module en lui même à priori et non pas du système domotique.
Le vrai souci pour moi, c’est que ce phénomène apparait après un arrêt/redémarrage du module (après une coupure de courant par exemple), mais aussi après un certain temps sans sollicitation du FGBS. Je l’utilise pour détecter l’ouverture de mon portail et systématiquement, tous les jours, la première ouverture du matin n’est pas détectée, ce qui est un peu emmerdant.

Avez-vous pu trouver une solution/workaround depuis le temps ?

C’est plus qu’emmerdant mais par contre j’ai pas du tout ce problème pour ma part.

Autant l’état de remonte systématiquement pas comme il faut après reboot de Jeedom autant je n’ai pas de raté dans la détection de la 1ere ouverture du matin hormis si, une fois, l’info ZWave n’est pas « capté » par Jeedom car perdu.

Ce serait possible d’avoir vos paramètres pour voir si je n’ai pas râté un truc d’évident (j’en doute vu qu’on est plusieurs à avoir le même souci apparemment).

J’ai peut-être une piste sur le fait que c’est seulement la première remontée qui foire.
Lors du premier réveil sur certains modules, la valeur de l’alarme Burglar (ou Access Control) passe à 254 : un état inconnu !
image

Je viens de regarder sur mon module
image
Or la commande IN1 utilise cette info de merde
image
Bref, ça pu ! Lors de la conversion en booléen pour transformer 0-255 en 0-1, la valeur 254 est différente de 0 donc elle est vue comme un 1.

Oui, il faut un aller retour (ouverture /fermeture) du capteur pour que tout rentre dans l’ordre !

Je vous laisse méditer sur ce sujet

EDIT : L’astuce d’ignorer la valeur 254 a résolu de problème pour @Bison

Ah OK, effectivement, je comprends mieux maintenant. Merci pour l’explication, c’est très clair.
Je vais tenter une autre solution un peu « bidouille » quand j’aurai le temps : mes entrée IN1 et IN2 sont en temps normal fermées, je vais les « faire passer » par la sortie OUT2 que je n’utilise pas avec un scenario qui ouvre/ferme cette sortie si IN1 ou IN2 sont dans un état inconnu pour les réinitialiser.

Super merci! Je vais regarder ça de plus près!