Bonjour à tous. J’utilise actuellement un FGBS 222 de fibaro. Mais ce module présente des soucis d’actualisation notamment en cas de redémarrage du réseau sur les valeur renvoyer sur l’entrée 1. J’ai trouver des solutions pour y palier. Mais je ne suis pas complétement satisfait de cette situation.
Je réfléchis donc à trouver une solution alternative. Qui permettent d’une part de réaliser un contact sec pour ouvrir une porte de garage. Et d’autres part de remonter l’état d’un sabot fonctionnant en contact normalement ouvert.
Effectivement. J’ai trouvé tes infos si j’ai bonne mémoire : passage en numérique au lieu de binaire, et exclusion de la valeur alarm à 254.
J’ai vu une autre solution que j’ai mise en œuvre : exclusion du paramètre command class alarm pour que le module ne remonte plus ce type de commande du coup plus de prob.
Toutefois avec une mise à jour du plugin éventuel de zwave ca risque de faire sauter ce paramètrage.
Donc soit je fais avec le passage en numerique.
Soit je change le module
De plus quand tu veux utiliser les deux entrées ca complique ca si j’ai bien lu c’est command class basic qui revoit une valeur au redémarrage.
Alors en tout cas pour le soucis que j’avais remonté à savoir qu’après reboot l’état de l’entrée 1 n’était pas à 0 et qu’il fallait que j’actionne mon portail pour que ça fasse du 1 puis à 0, oui absolument. Je n’ai plus jamais eu ce soucis en passant l’entrée en numérique et en interdisant la valeur 254 dans la configuration de la commande.
En revanche je n’avais ce problème qu’au reboot de Jeedom ou au restart du daemon Zwave.
Les autres problèmes que j’ai pu avoir (infos qui ne se mets pas à jour parfois) n’était absolument pas dû au module FGBS-222 mais à l’ensemble des modules Zwave et de façon aléatoire. C’est pourquoi j’ai migré ensuite sur zwavejs2mqtt, j’en avais marre .
Bonjour,
Moi j’utilise le qubino contact sec (me rappelle plus de la référence exact mais il n’y en a qu’un avec deux inputs ).
En input il n’a pas un sabot mais un contact du moteur de la porte de garage, même principe.
Et en sortie il pilote l’ouverture bien sûr.
Et il est alimenté en 24vdc directement sur le moteur, pratique.
donc avec un module j’ai l’action et l’info.
Les mises à jour du plugin écrasent les fichiers de config. Tant que tu ne ré-inclus pas ce module ou ne régénères pas les infos du nœud ou du réseau, c’est bon.
Soit tu remplaces OpenZWave , soit tu changes de protocole : si tu restes en Z-Wave avec OpenZWave, les autres modules auront des soucis similaires avec les command class Alarm.
@Bison Tu confirmes qu’avec ZWaveJS2mqtt, ton portail (plutôt le FGBS-222) fonctionne sans bidouille ?
Oui c’est sur car j’ai ajouté de nouveaux virtuels pour mes équipements jMQTT et les commandes sont des binaires sans aucune notion d’exclusion de valeur.
L’état des entrées restent bien à 0 après reboot de Jeedom ou Mosquito.
Donc plus de bidouille nécessaire .
Faut que je me penche sur le mqtt.
Mais ca ferait encore un élément de plus à gérer. @Bison la transition de openzwave vers zwaveJsmqtt n’est pas trop lourde à réaliser ?
.
.