FGBS-222 avec capteur d'ouverture filaire

Bonjour,

Tout nouveau dans home assistant, j’essaie de me débrouiller pour mettre toute la domotique en fonctionnement. Je suis depuis plusieurs années utilisateurs de Jeedom mais j’ai voulu changer suite à plusieurs plantages.

Pour le moment, je ne suis pas déçu même si c’est un peu plus compliqué je trouve (peut-être de mauvaise habitude avec Jeedom aussi).

J’ai réussi à peu prêt tout remettre en ordre sauf une chose (et j’avais pareil assez galéré sous Jeedom), la remontée de l’état du portail.

J’utilise un FGBS222 Smart Implant, je n’ai pas de problème particulier avec, j’ai mon interrupteur à l’intérieur et l’arrive à le piloter correctement.

Mais je bloque sur la remontée de mon capteur filaire branché sur l’entrée 1, de temps en temps ça fonctionne je le vois bien dans l’historique mais c’est assez rare, par contre la commande d’ouverture de portail fonctionne normalement.

J’aimerais débugger cette partie et trouver d’ou vient le problème mais je ne sais pas par ou commencer.
C’est pour ça que j’appelle à l’aide ici.

Merci para avance :smiley:





Personne :frowning: n’a d’idée ?

Si on reprend ton premier message :

  • Ouverture/Fermeture du portail ça fonctionne correctement.
  • Le binary_sensor de ton input 1 fonctionne de manière aléatoire (mais en gros c’est fonctionnel)

Donc on peut dire que ton module est à bonne portée de la clé zwave et que ses settings sont ok.

J’utilise le même module sur une motorisation Nice qui délivre du 24V sur l’entrée 1 lorsque le portail est ouvert, j’ai les mêmes paramètres même si je tourne sur l’ancienne intégration Zwave.
Lors de mes test en zwavejs je n’ai pas eu ce soucis.

As-tu scruté les logs zwavejs lors d’une ouverture pour voir si tu vois passer les bonnes trames (si besoin tu peux modifier le niveu de trace) ?

Et est-ce que par hasard tu as retouché au câblage de ton module depuis que tu es passé sur Home Assistant ?

Bonjour,

Oui c’est bien ça aucun soucis sur l’ouverture / fermeture du portail, ce qui exclut de fait la mauvaise portée (le FGBS est à moins de 15 mètres de la clé Zwave).
Depuis mon dernier message, je n’ai que très peu (voir aucune) remontées de l’état (et le plus souvent c’est au redémarrage de HA mais pareil très très rare)

Entre temps, j’ai aussi vérifié sur mon ancienne installation de Jeedom, j’ai exactement les mêmes paramètres.

Je n’ai pas touché au câblage depuis, c’est un Robus 600 de Nice.

C’est ça le soucis, c’est que pour le moment, j’ai encore un peu de mal à tracer, je peux modifier ou le niveau des traces ?

EDIT : je viens de trouver les niveaux de log, je poste le résultat dans quelques minutes

Je suis passé en niveau de log DEBUG, je ne sais pas si le mieux, voici le résultat (après une ouverture partielle et une fermeture auto) :

Niveau de journal modifié en : Debug
2021-11-22T14:23:37.139Z SERIAL » 0x010e00131407600d00062501ff250f6b                                  (16 bytes)
2021-11-22T14:23:37.162Z DRIVER » [Node 020] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      15
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      0
                                    │ destination: 6
                                    └─[BinarySwitchCCSet]
                                        target value: true
2021-11-22T14:23:37.175Z SERIAL « [ACK]                                                                   (0x06)
2021-11-22T14:23:37.200Z SERIAL « 0x0104011301e8                                                       (6 bytes)
2021-11-22T14:23:37.204Z SERIAL » [ACK]                                                                   (0x06)
2021-11-22T14:23:37.210Z DRIVER « [RES] [SendData]
                                    was sent: true
2021-11-22T14:23:37.275Z SERIAL « 0x010700130f00000aee                                                 (9 bytes)
2021-11-22T14:23:37.279Z SERIAL » [ACK]                                                                   (0x06)
2021-11-22T14:23:37.286Z DRIVER « [REQ] [SendData]
                                    callback id:     15
                                    transmit status: OK
2021-11-22T14:23:37.315Z CNTRLR   [Node 020] [~] [Binary Switch] currentValue: false => true        [Endpoint 6]
2021-11-22T14:23:37.425Z SERIAL « 0x010d0004001407600d0600250300a8                                    (15 bytes)
2021-11-22T14:23:37.437Z CNTRLR   [Node 020] [~] [Binary Switch] currentValue: true => false        [Endpoint 6]
2021-11-22T14:23:37.441Z CNTRLR   [Node 020] Scheduled poll canceled because value was updated
2021-11-22T14:23:37.446Z SERIAL » [ACK]                                                                   (0x06)
2021-11-22T14:23:37.454Z DRIVER « [Node 020] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      6
                                    │ destination: 0
                                    └─[BinarySwitchCCReport]
                                        current value: false
2021-11-22T14:24:24.037Z SERIAL « 0x0113000400140d600d01007105000000ff07000011                        (21 bytes)
2021-11-22T14:24:24.046Z CNTRLR   [Node 020] [~] [Notification] notificationMode: "push" [Endpoint 1] [internal]
                                   => "push"
2021-11-22T14:24:24.052Z SERIAL » [ACK]                                                                   (0x06)
2021-11-22T14:24:24.063Z DRIVER « [Node 020] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      1
                                    │ destination: 0
                                    └─[NotificationCCReport]
                                        notification type:   7
                                        notification status: 255
                                        notification state:  idle
2021-11-22T14:24:24.224Z SERIAL « 0x0113000400140d600d01007105000000ff07000011                        (21 bytes)
2021-11-22T14:24:24.231Z CNTRLR   [Node 020] [~] [Notification] notificationMode: "push" [Endpoint 1] [internal]
                                   => "push"
2021-11-22T14:24:24.237Z SERIAL » [ACK]                                                                   (0x06)
2021-11-22T14:24:24.248Z DRIVER « [Node 020] [REQ] [ApplicationCommand]
                                  └─[MultiChannelCCCommandEncapsulation]
                                    │ source:      1
                                    │ destination: 0
                                    └─[NotificationCCReport]
                                        notification type:   7
                                        notification status: 255
                                        notification state:  idle

Le « Endpoint 1 » correspond bien à l’entrée 1, le status 255 je pense que c’est le statut qui valide l’échange, pour le reste il faudrait qu’un vrai connaisseur zwavejs passe par ici pour analyser ça.

Par contre on voit sur tes captures d’écrans 4 entités désactivées, as tu regardais à quoi cela pouvait correspondre ?

Bien sur, voici les entités masquées :


J’ai comme l’impression que je me base sur la mauvaise entité …
J’ai pris binary_sensor.fgbs_portail_home_security_intrusion, mais ce n’est pas ça si ?

C’est forcement un binary_sensor et aucun n’est désactivé il ne reste plus que :

image

et

image

A voir si au moins un des deux réagit quand tu ouvres le portail, mais si ce n’est pas le cas alors il y’a vraiment un problème.

Les 2 réagissent de la même manière.
Ce qui est étrange, c’est que quand j’active ces 2 entités : sensor.fgbs_portail_home_security_sensor_status ou sensor.fgbs_portail_home_security_sensor_status_2, j’ai le capteur qui réagit

Je pense que le module redémarre c’est pour ça

J’irais vérifier les câblages au cas ou, je n’ai pas d’autres idées pour le moment

Actuellement mon capteur d’ouverture ne fait plus réagir le 222 mais il a fonctionné durant plusieurs mois. Si ça peut t’aider, voici ma config.

Le capteur filaire (aimant fixé au portail) fait varier le voltage d’un INPUT: 0V = fermé , dès que l’aimant se sépare ça fait monter le voltage.

Du coup j’ai créé un binary_sensor qui change selon le voltage pour me donner l’état de l’ouverture du portail, condition à l’automatisation de l’ouverture/fermeture:

#senseur qui donne l'état d'ouverture du portail selon le voltage du smart implant. 0V = portail fermé
binary_sensor:
  - platform: template
    sensors:
      ouverture_portail:
        friendly_name: "Portail ouvert"
        unique_id: "sensor.ouverture_portail"
        device_class: opening
        value_template: "{{ states('sensor.smart_implant_voltage_3')|float > 0 }}"

image

Cela fonctionnait très bien jusqu’à une coupure de courant il y a quelques semaines. Le seul pb que je rencontrais c’est qu’il y avait un délai parfois de plus de 10 secondes entre le changement du voltage et le changement du binary_sensor. J’avais remarqué que la valeur du voltage mettait assez longtemps à être vue par HA, donc je comptais ajouter un rafraichissement des valeurs de l’entité lors du lancement de l’automatisation ouverture/fermeture portail.

D’après le forum anglais, les entrées ne sont pas mise à jour par HA:

1 « J'aime »

Bonjour,

Ah mince, donc HA pour le moment ne sait pas gérer le FGBS (les inputs) … mince :frowning:

J’ai regardé pour le voltage, il ne varie pas non plus de mon côté
Il y a eu une ouverture de portail ce matin.

Je relance un peut le sujet, parce que ça me parait étrange. J’ai réussi à tout basculer depuis Jeedom sauf ça.
Je suis passé à Z-Wave JS to MQTT même résultat, mon capteur aimant sur le smart implant ne remonte pas (input).

ll n’y a vraiment pour le moment pas cette possibilité ?
J’ai parcouru pas mal le forum (celui de home assistant aussi), j’ai trouvé une solution de refresh du node toutes les 10 secondes mais bon ça me plait moyen comme solution, je n’ai pas testé.
Parfois, j’ai vu des personnes qui avaient réussi la remontée mais ce n’est pas très clair, je ne sais pas si ils l’ont en direct.

Personne n’a de FGBS sur Home assistant avec des inputs branchés ?

Merci :smiley:

PS : j’avais lu aussi que le FGBS doit être ajouté en mode unsecure mais c’est ce que j’avais fait à l’époque sous Jeedom je crois, il faudrait que je recommence ?

Bonjour,

Je me trouve dans la même situation, impossible de faire remonter les valeurs de l’input sans faire un rafraîchissement. Cela enlève tout l’intérêt du Fibaro implant.
Est ce que tu as trouvé une solution depuis ?
De mon cote l’objectif est de refermer le portail automatiquement au bout de quelques minutes lorsqu’il est ouvert donc un refresh toutes les 3 minutes par exemple est envisageable mais c’est pas super élégant .

Bonjour, je n’ai rien fait de spécial mais depuis quelques semaines, cela fonctionne très bien !
J’ai fait plusieurs suppression puis intégration de l’implant sans réussite, et un jour suite à une mise à jour c’était bon …