Remontée Etat Nice Bidi IBT4ZWAVE

Bonjour,

Je viens d’installer un module Nice Bidi Zwave (Version 7.0) sur un moteur de porte de Garage Nice.

J’arrive bien à le contrôler et recupérer son état via le plugin-openzwave avec les commandes suivantes :

En revanche, je note une différence de comportement pour la remontée des états d’ouverture/fermeture selon que l’on utilise la télécommande Nice du moteur ou les commandes Zwave.

Avec la télécommande Nice :

  • 0 => Fermé
  • 99 => Ouvert
  • 254 => Ouverture en cours, fermeture en cours, arrêté

Ce qui semble cohérent avec la doc (112,1 Ko) du module :

Avec les valeurs décimales :

image

Avec les commandes Zwave :

  • 0 => Fermé
  • 99 => Ouvert
  • 254 => Arrêté (Pas de remontée de l’ouverture ou fermeture en cours)

Pour les possesseurs de ce module, avez-vous également cette différence de comportement suivant que l’on utilise la télécommande Nice ou les commandes Zwave ?

J’ai aussi effectué des tests avec le nouveau plugin-zwavejs (voir ici sur Discord) mais la différence de comportement semble identique.

J’espère qu’avec le le nouveau plugin-zwavejs, on pourra récupérer les 5 états.

Merci.

J’ai refait quelques tests et je note une différence de comportement entre le plugin-openzwave et le plugin-zwavejs.

Avec le plugin-zwavejs, l’état ne remonte jamais la valeur 254. Seulement les valeurs 0 et 99 sont remontées.

En comparant l’arbre zwave à partir du plugin-openzwave

"38":{
                  "data":{
                     "0":{
                        "updateTime":1668961256,
                        "help":"",
                        "typeZW":"Byte",
                        "genre":"User",
                        "read_only":false,
                        "expected_data":null,
                        "poll_intensity":0,
                        "name":"Level",
                        "val":0,
                        "pendingState":null,
                        "type":"int",
                        "data_items":"A byte between 0 and 255",
                        "value_id":72057594076299260,
                        "units":"",
                        "write_only":false
                     }

Bidi_Arbre_OpenZwave.txt (29,3 Ko)

et celui du plugin-zwavejs

"38-0-targetValue":{
         "id":"2-38-0-targetValue",
         "nodeId":2,
         "toUpdate":false,
         "commandClass":38,
         "commandClassName":"Multilevel Switch",
         "endpoint":0,
         "property":"targetValue",
         "propertyName":"targetValue",
         "type":"number",
         "readable":true,
         "writeable":true,
         "label":"Target value",
         "stateless":false,
         "commandClassVersion":4,
         "min":0,
         "max":99,
         "list":false,
         "value":0,
         "lastUpdate":1668957969833
      }

Bidi_Arbre_ZwaveJS.txt (93,4 Ko)

on peut voir qu’il y a une valeur max à 99 pour le plugin-zwavejs. Cela pourrait-il être la cause de la non remontée de la valeur 254 ?

Cette valeur max provient-elle du plugin-zwavejs ou de la librairie ZwaveJS UI ?

Comment faire en sorte que cette valeur puisse bien être prise en compte par le plugin-zwavejs ?

as-tu résolu ton souci ? je n’ai pas encore installé le mien, j’attends la livraison d’un nouveau coffret compatible avec. sinon je pense que tu peux signaler le truc sur discord.

Si j’interprète bien, ce qu’il y a dans les specs de la Zwave Alliance, page 100, on peut trouver ce tableau qui semble indiqué que la valeur 254 (0xFE) peut exister.

image

Dans la librairie ZwaveJS, le max semble limiter à 99 :

Multilevel Switch CC

Du coup, il faut probablement aller creuser côté Zwave JS.

Déjà fait en juillet mais aucune réponse …

je vais relancer, car je vais pas tarder à installer le mien et c’est tout l’intérêt de savoir s’il est en mouvement ou pas …

@Salvialf : comme le discord est fermé pour zwave-js, sais-tu comment on peut faite étendre la plage de valeur pour cet équipement de 99 à 255 pour la valeur max ?

Oui, le top serait d’avoir les 5 états que propose le module avec la combinaison de la TargetValue, currentValue, et duration.

je ne pense pas qu’on peut faire ça au niveau de l’objet connecté, car il n’est pas prévu de champ calculé.

C’est pas compliqué à faire via un virtuel et un widget sur mesure pour afficher les états du portail. ça je saurais le faire, mais il faut déjà que je fasse marcher le truc pour pouvoir tester chez moi.

Oui mais c’est peut être faisable avec une config spécifique dans le plugin pour ce module.

Néanmoins, j’utilise déjà un bloc code qui en fonction de la valeur précédente et de la valeur courante de l’état permet de déduire si il s’agit d’une ouverture ou d’une fermeture en plus de l’état Ouvert ou Fermé. Je pourrais partager le code si tu veux.

ok, le plugin zwave-js ne permettra pas je pense de calculer ça, par contre effectivement un bout de code et des variables ou un virtuel doivent faire l’affaire. je reviendrai vers toi quand je vais installer le truc. pour le moment j’ai toujours pas le coffret et vu les délais sur l’électronique j’ai des doutes pour l’avoir avant noel :slight_smile:

En creusant côté ZwaveJS, il s’avère que celui-ci remonte par défaut les valeurs « unknown » en « undefined ».

/**
 * Some Command Classes support reporting that a value is unknown.
 * When this flag is `false`, unknown values are exposed as `undefined`.
 * When it is `true`, unknown values are exposed as the literal string "unknown" (even if the value is normally numeric).
 * Default: `false`
 */
preserveUnknownValues?: boolean;

La valeur unknown ne remonte donc jamais jusqu’à Jeedom.

En revanche, en changeant la valeur par défaut de l’option Zwave preserveUnknownValues en la passant à true, les valeurs remontent bien.

Pour cela, il faut ajouter l’option à la ligne 149 dans le fichier /plugins/zwavejs/core/class/zwavejs.class.php et redémarrer le démon du plugin. Mais cette modification sera à refaire à chaque mise à jour du plugin. A voir si l’ajout d’un champ options sur le plugin-zwavejs est envisageable.

		$settings['zwave']['options'] = array(
			'preserveUnknownValues' => true
		);

Pour les détails, voir ici :

Néanmoins, il reste un souci lorsque cette option est activée : Driver: options is not a MultilevelSwitchCCStartLevelChangeOptions (ZW0322) / "options":{"preserveUnknownValues":true} · Issue #5237 · zwave-js/node-zwave-js · GitHub

il vaudrait mieux que zwave-js prenne en charge cette mécanique unknown plutôt que de changer des settings qui peuvent avoir un effet secondaire sur tous les autres équipements.

Oui, je suis bien d’accord. Je préfererais que ZwaveJS laisse remonter cette valeur numérique 254 plutôt que de la transformer en unknown ou undefined mais ce n’est malheureusement pas le cas pour le moment.

Bonjour ,
vous avez réussi à faire fonctionner le module avec le plugin #plugin-zwavejs ?
Car après migration je n’ai plus aucunes commandes même après avoir fait « Recharger commandes »

J’ai finalement réussi à faire fonctionner un minimum le module avec le plugin #plugin-zwavejs en créant les commandes en manuel .
Par contre même problème . je ne récupère pas la remontée de la valeur 254
le status du portail reste donc à l’état fermé jusqu’à l’ouverture complète :confused:

Bonjour,
Je me retrouve dans la même situation via le plugin zwavejs, quelles sont les commandes que tu as recréées?
j ai fait une integration S2 avec des commandes du type « type=buttonaction&action=press » en 38/1/1 pour l open mais je n ai pas de reaction.
Merci

Bonjour,

Comme indiqué précédemment, c’est côté ZwaveJS qu’il’ faudrait changer le comportement pour les « unkown » values.

N’hésitez à mettre un commentaire sur le sujet côté ZwaveJS. Plus il y aura de demandes, plus il aura de chances que cela soit pris en compte.

https://github.com/zwave-js/node-zwave-js/discussions/4804#discussioncomment-4298074

Bonjour,
j’ai créé les commandes via l’onglet « valeurs » de l’équipement

Merci pour ta réponse, ca fonctionne en effet.

De rien reste qu’a espérer une mise à jour de ZwaveJS pour prendre en charge le status d’ouverture :wink: