Door/Window Sensor 2 se ferme tout seul lors du 1er réveil

[Domatizer]

Bonjour à tous,

J’ai observé un bug (reproductible) avec les détecteurs Fibaro Door/Window Sensor 2 uniquement lors du premier réveil.

J’ai installé des détecteurs d’ouvertures partout sur toutes les fenêtres, porte-fenêtres, portes extérieures et intérieures.
J’ai d’abord remarqué que j’avais seulement des soucis avec ceux installés sur les portes intérieures.
Comme ces portes intérieures sont les seules ouvrants qui restent entre ouverts très souvent, j’ai pu identifier le problème.
À l’extérieur, elles sont toutes fermées à 99% du temps, donc pas le temps statistiquement de voir le problème.
J’ai mis du temps à comprendre car cela me paraissait aléatoire au début.

Explications du bug : lors du démarrage du réseau Z-Wave, les états remontés sont corrects, ensuite si on ouvre ou ferme les portes, les états changent correctement aussi.
Par contre, si les portes restent ouvertes lors du premier réveil uniquement, leurs états passent à 0 (donc à fermé) les unes après les autres au fur et à mesure de leur réveil respectif.
Ensuite, tout rentre dans l’ordre après une fermeture puis une ouverture.
Mais entre temps, les scenarii liés à ces modules font n’importe quoi dans la gestion de la présence, cell-ci est complètement faussée.

Puisque mes modules se réveillent toutes les 6h, actuellement, la parade est de fermer toutes les portes pendant les 6 premières heures après le redémarrage du réseau Z-Wave.
Je le fais de préférence la nuit, mais c’est pénible et surtout pas normal.

J’ai vu aussi que certains utilisateurs anglophones avaient eu des problème similaires même avec d’autres capteurs et d’autres box :
[Zwave Fibaro Smoke sensor / state change during regular wakeup - Bindings - openHAB Community](http://Zwave Fibaro Smoke Sensor + OpenHab (openzwave))
[Door sensors change state by themselves - #14 by matthewcky2k - Z-Wave - Home Assistant Community](http://Sensitive Strip + Home Assistant (openzwave))
[NEO door-sensors changes its status to "Closed" when sending "wake-up" - #19 by PetervdK - Questions & Help - Homey Community Forum](http://Neo Door Sensor + Homey)

Je n’ai pas vu vraiment de solution à part filtrer ce changement d’état à 0 lors du premier réveil.
Que peut-on faire sur Jeedom pour ignorer ce changement d’état lors du premier réveil ?

[Domatizer]

Je vois que ça n’inspire pas grand monde. Je me réponds car j’ai un peu mieux cerné le phénomène.

La commande Etat récupère la valeur de Access Control (Classe 113, Instance 1, Index 9)
Access Control prend la valeur 22 lorsque la porte est ouverte et 23 lorsqu’elle est fermée.
Etat doit être à 1 quand Access Control est à 22
Etat doit être à 0 quand Access Control est à 23
Pour effectuer cette conversion, il est rajouté dans Configuration commande à la ligne Calcul et arrondi
Formule de calcul (#value# pour la valeur) : #value#==22

Le souci, c’est qu’après le redémarrage du réseau Z-Wave, la valeur Access Control est bonne. Mais dès le premier réveil du module, la valeur passe à 254, ce qui devrait correspondre à « état inconnu ».
Comme 254 n’est pas égale à 22, le résultat est de 0 pour Etat, c’est-a-dire que la porte se ferme alors qu’elle bien ouverte et ça pose problème pour les scenarii associés.

Pour éviter le problème, il ne faudrait pas mettre à jour la commande Etat lorsque Access Control prend la valeur 254.

De mon côté, pour être puriste, j’ai commencé par remplacer #value#==22 par 23-#value# pour la commande Etat, ainsi, je satisfait toujours
Etat est à 1 quand Access Control est à 22
Etat est à 0 quand Access Control est à 23

Maintenant, si Access Control passe à 254, Etat vaut -231.
J’ai donc essayé d’ignorer cette valeur à la ligne Gestion des valeurs
Valeurs interdites (séparées par ";") : -231
La prise en compte des valeurs interdites est effectuée après le calcul de l’arrondi.

De plus, j’ai mis le type de la commande en Numérique au lieu de Binaire pour éviter que le -231 ne se transforme en 0 avant d’être ignoré.

Je viens corriger mon post car j’ai refais ce que je viens de décrire ci-dessus et cette fois-ci, ça fonctionne.

De la même façon, je me suis rendu compte d’un même souci avec un détecteur de présence Everspring SP816 qui s’allumait tout seul et pendant des heures (et la lumière avec la nuit) quelque temps après le redémarrage du réseau Z-Wave. J’avais manuellement créé une commande Presence qui se base sur Burglar (Classe 113, Instance 1, Index 10) et non pas sur Sensor qui ne fonctionnait pas le jour car réglé en fonction du seuil de luminosité. Idem, ce Burglar passait à 254 au premier réveil.
Donc, pour ce capteur, j’ai mis les réglages suivants :
Formule de calcul (#value# pour la valeur) : #value#/8
Valeurs interdites (séparées par ";") : 31.75
Ainsi,
Presence est à 1 quand Burglar est à 8
Presence est à 0 quand Burglar est à 0
Presence n’est pas mise à jour quand Burglar est à 254

Je pense que c’est bon, je passe le sujet en résolu

EDIT: Autre solution découverte par hasard
Pour éviter que Access Control ne soit mis à jour et prenne la valeur 254 lors du premier réveil, il suffit de rajouter dans le fichier config du module /var/www/html/plugins/openzwave/resources/openzwaved/config/fibaro/fgmszw5.xml

<!-- COMMAND_CLASS_ALARM (0x71) AlarmCmd_Get not supported -->
<CommandClass id="113" getsupported="false"/>

Après inclusion ou détection du noeud et ensuite arrêt du réseau Z-Wave, le fichier de config du réseau /var/www/html/plugins/openzwave/data/zwcfg_0x*.xml devrait contenir getsupported="false" dans la ligne COMMAND_CLASS_ALARM pour les modules concernés

<CommandClass id="113" name="COMMAND_CLASS_ALARM" version="5" request_flags="2" getsupported="false" innif="true">

Ainsi, lors du premier réveil après le redémarrage du réseau Z-Wave, le log indique ceci
Info, NodeXXX, AlarmCmd_Get Not Supported on this node
Access Control n’est plus mis à jour avec la valeur inconnue 254.
Mais, les valeurs 22 et 23 continueront d’être remontées. (Pas très logique mais ça fonctionne)