Migration des détecteurs d’inondation FIBARO FGFS101 de OpenZwave vers ZWAVEJS

Migration des détecteurs d inondation FIBARO FGFS101 de OpenZwave vers ZWAVEJS sur jeedom V4.4

J’ai basculé d’OpenZWAVE vers ZWAVEJS sur JEEDOM V4.4.

La détection d’inondation et sabotage ne fonctionnait plus. La température et le niveau de batterie fonctionne correctement.

La suite est plutôt un tuto que des questions

Introduction.

Les commandes étaient bien présentes dans la configuration du module mais ne détectaient plus rien.

Le problème provenait de l’inéquation entre les paramètres ZwaveJS et OpenZwave. Il a fallu recréer les commandes et remplacer celle par défaut.

C’est que nous allons voir ci-dessous.

Dans mon cas le module a été bien inclus dans le réseau ZwaveJS.
migration OZW ZWJS A1
migration OZW ZWJS A2

Sur les commandes du module, les commandes de sabotage et fuite sont bien présentes


.

B. Vérification de la bonne réception des informations manquantes.
Si j’édite le module et je clique sur Valeurs.

Puis j’ouvre la zone Notification v5. Je peux voir les informations concernant l’inondation (Water Alarm-Sensor status) et le sabotage (Home Security-Cover status).

Si je bouge le module et provoque un sabotage alors on voit bien la ligne Home Security-Cover status se modifie. C’est bien le paramètre de sabotage.

C’est la même chose si je simule l’inondation en essayant de ne pas déclencher le sabotage.

C. Création de nouvelles commandes.
Recréons les nouvelles commandes. Depuis le menu des Valeurs, cliquons sur le stylo des deux commandes


migration OZW ZWJS C2
migration OZW ZWJS C3

D. Regardons les nouvelles commandes.
On voit bien les 2 nouvelles commandes avec leur propriété en adéquation avec les Valeurs du module

E. Recopions manuellement la configuration de la commande de l’ancienne sur la nouvelle.
Modifier le type de commande comme sur la commande originale

migration OZW ZWJS E1
migration OZW ZWJS E2

Pensez bien à sauvegarder à chaque fois.

Editons la configuration de l’ancienne commande

Et reportons-la sur la nouvelle commande sensor status xxxxx


Les onglets Alertes et Affichage sont selon votre configuration. Reporter de l’un vers l’autre
Pensez bien à sauvegarder à chaque fois.

Faite la même chose pour sabotage

migration OZW ZWJS E6
migration OZW ZWJS E7

Pensez bien à sauvegarder à chaque fois.
Et reportons-la sur la nouvelle commande Cover status-xxxxx


Les onglets Alertes et Affichage sont selon votre configuration. Reporter de l’un vers l’autre
Pensez bien à sauvegarder à chaque fois.
F. Renommer les commandes afin qu’elles soient plus compréhensibles.
Ne pas encore supprimer les anciennes.

G. Remplacer les commandes dans les scénarios
L’outil remplacer ne fonctionne pas car il ne permet pas de remplacer une commande du même module. Il permet de remplacer des commandes d’un module vers un autre module.
Il faut le faire à la main. Depuis l’onglet information de chaque commande quand vous les éditez, repérez les scénarios et faite les modifications nécessaire.

H. Vérifier que tous cela fonctionne.
I. Vous pouvez supprimer les anciennes commandes si tout est fonctionnel

3 « J'aime »

Merci beaucoup, tu me sauves!
Effectivement les commandes n’étaient plus fonctionnelles suite au changement de plugin et je ne m’en suis aperçu que maintenant!

Sans ton tuto j’étais dans la panade…
D’ailleurs je ne comprends toujours pas les values = à 2 ou 3 dans le calcul…
Mais j’ai suivi ta procédure pas à pas et ma détection de fuite refonctionne

Heureusement qu’il y a des gens comme toi qui partagent sur le forum. :handshake: :pray:

Bonjour,

Comme c’est une commande binaire, cela veut dire que c’est si la valeur « réelle » du capteur est égale (ce qui s’écrit == en php) à 2 alors le binaire passe à 1 (= vrai).