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)