Faire fonctionner le module Fibaro FGBS222 « smart implant » avec Openzwave & Jeedom

Etant équipé de Jeedom, cet article sera illustré par des écrans Jeedom. Néanmoins il s’agit d’informations qui peuvent être intéressantes pour toutes les plateformes domotiques et en particulier celles utilisant openzwave : Jeedom, Domoticz, Home Assistant, etc …

J’ai récemment acheté une module Fibaro FGBS222 « smart implant » pour contrôler ma porte de garage (article à venir). J’ai voulu en faire un peu plus avec ce module mais j’ai eu bien du mal à obtenir les résultats attendus. Au vu des différents messages dans les forums, je ne suis pas le seul dans ce cas, d’où cet article.

Les difficultés rencontrées avec ce module

1. L’état des 2 sorties du modules sont par défaut dépendant de l’état des 2 entrées
2. Le module n’envoie pas automatiquement  de  mise à jour de l’état de ses entrées-sorties et des ses capteurs
3. En inclusion sécurisée on perd une bonne partie des fonctionnalités du modules

Les deux premiers points sont liés à des spécificité du module, cela peut être utile à tout ceux qui l’utilisent.
Le dernier point est lié à une limitation actuelle de openzwave. C’est donc ceux qui sont équipés du système domotique basé sur openzwave qui seront intéressés.

L’état des 2 sorties du modules sont par défaut dépendants de l’état des 2 entrées

Le smart implant semble avoir été développé pour être plutôt intégré dans un système d’alarme. Dans ce cadre le module est configuré par défaut pour reporter l’état de ses entrées vers ses sorties.

Cela est débrayable de deux façons :

1. Celle que j’ai testée : configurer les entrées en tant qu’entrées analogiques
   • Cliquer sur le nom du module
   • Rentrer dans les Paramètres avancés
   • Onglet Paramètres
   • Changer les deux premiers paramètres
2. L’autre méthode que je n’ai pas testée mais présentée dans les forums
   • Cliquer sur le nom du module
   • Rentrer dans les Paramètres avancés
   • Onglet Système
   • Changer le ou les paramètres Protection
   • Choisir la valeur en No operation possible

Le module n’envoie pas automatiquement de  mise à jour de l’état de ses entrées-sorties et de ses capteurs

C’est ce post qui m’a mis la puce à l’oreille : le FGBS222 a des paramètres d’association non documentés qu’il faut activer pour que le remontée d’information soit active. Or le profil de configuration par défaut d’openzwave n’intègre pas (logiquement) ces configurations.

Les étapes à suivre sont les suivantes :

1. Voici un fichier fgbs222.xml de configuration mis à jour qui contient ces paramètres d’association non documentés. Je reverse ce fichier aux contributeurs openzwave pour qu’ils l’intègrent par défaut si ils le souhaitent. En attendant cette intégration, ce fichier peut être copié, pour une installation jeedom, dans le répertoire /var/www/html/plugins/openzwave/resources/openzwaved/config/fibaro/ à la place du fichier fgbs222.xml existant.
2. Une fois le fichier mis à jour, une nouvelle procédure d’exclusion-inclusion du module est à réaliser. Si tout se passe bien vous aurez accès à ces nouveaux paramètres d’association ( Paramètres avancés –> onglet Associations )
3. Rajouter les associations avec le contrôleur domotique pour les périphériques qui doivent remonter. Rajouter la racine du contrôleur plutôt qu’un endpoint (pas de chiffre entre parenthèse au bout du nom)
4. Cette association va sembler ensuite ne pas se terminer : l’icône va rester actif et le nom du contrôleur ne va pas se rajouter à la liste. Je pense que cela est lié à au module qui ne gère pas tous les messages Zwave sur ces paramètres cachés ( « get association » non implémenté ? A confirmer.).
   Rassurez vous, l’association est quand même active. Pour que l’icône d’association s’arrête de tourner, mon astuce est de lancer une action de rafraîchissement des infos du noeud.
5. Enfin, il s’agit de paramètrer les conditions d’envoi des mises à jour de valeur (onglet paramètres).
   Exemple pour les entrées analogiques :
   

Une fois ces étapes faites, vous devriez avoir les valeurs qui remontent automatiquement du module, sans devoir faire du polling.

Après essai sur entrée analogique et sonde de température externe, la remontée d’information se fait bien mais n’est pas encore parfaite  :

• la conversion analogique semble se faire sur une période de 10 – 15 secondes, ce qui correspond plus ou moins au délai nécessaire pour recevoir une valeur lorsque changement
• même si j’ai programmé le module pour envoyer une mise à jour pour un delta de température de 0.1°C ou toutes les heures, le module semble se limiter à envoyer un message avec un intervalle minimal semblant être 30 minutes, j’ai donc eu certains changements plus importants que 0.1°C.

En inclusion sécurisée on perd une bonne partie des fonctionnalités du modules

Alerte préalable : la résolution proposée n’est accessible qu’à des utilisateurs avancés. En cas de mauvaise manipulation vous pourriez corrompre votre installation zwave et devoir tout réinstaller. Je n’irai pas trop dans les détails sur ce chapitre, si des éléments ne vous sont pas compréhensibles c’est peut être qu’il est risqué de vous y frotter…

Par ailleurs, même si ma manipulation fonctionne, tout n’est pas 100% sous contrôle. En particulier une évolution logicielle d’openzwave peut rendre cela caduque.

Racine du problème : Les lignes de code nécessaires à la détection des « endpoints » à l’inclusion d’un module en mode sécurisé n’ont pas encore été écrites dans openzwave. Dans le cas du FGBS222 les capteurs sont justement assignés à différents endpoints donc on les perd en inclusion sécurisée.

La méthode générale pour les retrouver :

1. faire une inclusion non sécurisée
2. récupérer les infos détectées par openzwave en non sécurisé dans le fichier de configuration
3. réinclure le module en mode sécurisé
4. merger dans le fichier de configuration les éléments non détectés à l’inclusion qui étaient présents en mode non sécurisé

Le fichier de configuration d’openzwave est disponible dans le répertoire /var/www/html/plugins/openzwave/data/ et se nomme zwcfg_0x’something’.xml, ‘something’ étant le code de votre réseau Z-wave.
Ce fichier est enregistré sur le disque lorsque openzwave est désactivé et il est pris en compte à son redémarrage. Prenez donc soin de le lire ou de l’écrire après extinction d’openzwave, donc après extinction du plugin zwave sous jeedom.

A noter également que le redémarrage d’openzwave prend du temps, soyez patient. Si vous arrêtez ce re-démarrage vous risquez des mauvaises surprises. Attendez tranquillement que le compteur de messages en attente arrive à 0 et que l’état soit Topology loaded dans le panneau « Réseau Zwave »

J’ai réalisé pour ma part ce merge en utilisant notepad++ et son plugin de comparaison. Voici le résultat de ce merge  que j’ai ré-intégré dans le fichier zwcfg_0x’something’.xml.

Au redémarrage d’openzwave, cela ne se passe pas parfaitement (de nouveaux endpoints sont re-détectés pour certaines commandes si on relance un « rafraîchissement des infos du noeud »), mais dans l’ensemble c’est fonctionnel.