[Incompatibilité] Volet et Zwave

Salon des Développeurs
1

Visiblement depuis peut, les utilisateurs de mon plugin volet rencontre des probleme de passage en mode manuel.

La gestion du mode manuel est une detection des event sur l’etat du controleur qui ne sont pas autorisé
Si j’analyse les log qui me sont envoyé au niveau de l’etat j’ai cela

Pour un commande de 0 a 99%

[2019-02-12 08:10:04][INFO] : [Cuisine][Gestion volet cuisine][Etat] : Changement de l’état réel du volet => 99%
[2019-02-12 08:10:04][INFO] : [Cuisine][Gestion volet cuisine][Etat] : Changement de l’état réel du volet => 0%
[2019-02-12 08:10:18][INFO] : [Cuisine][Gestion volet cuisine][Etat] : Changement de l’état réel du volet => 99%

Donc le plugin émet un état a 99 puis a 0 immédiatement a la commande puis l’état final 15s plus tard
Que le plugin émet sa valeur actuel ne pose pas de problème par contre qu’il émet la valeur haute provoque l’acquittement de la valeur.

Est ce que des spécialiste du plugin zWave peuvent me dire si le comportement est desormais normal?

2

Salut,

J’ajouterais que ça ne pose pas de problème si le plugin ZWave émet la valeur initial lors d’une demande de changement a condition que la date valueDate retournée ne soit pas la même que la CollectDate.

J’ai un problème similaire avec la gestion des consignes de vannes thermostatiques, lors du changement de consigne (depuis jeedom, je penses que si manipulation directement sur la vanne pas de pbm).
Par exemple la consigne actuel est 19. Si on passe a 22 depuis jeedom, deux événements sont recu dans la même seconde, un avec 19°C et un avec 22°C et les deux on une date CollectDate = ValueDate (ce que j’ai interpréter comme une indication de changement de valeur). Du coup sans réponse a un post fait sur le forum, j’avais choisi de gérer un flag quand réception d’une valeur dont le CollectDate = ValueDate et d’attendre l’événement suivant avec un CollectDate != ValueDate pour prendre en compte mais c’est un contournement et applicable seulement au équipement ZWave (et je ne suis pas sur que ce soit applicable a toutes les vannes ZWave non plus).

A+

3

C’est quand meme pas tres logique comme fonctionnement.
On ne peux pas prendre tous les cas particulier en contournement, il faut que cela soit corrigé sur la source

Edit
Un tel contournement interdit donc toute retour d’etat dans la seconde qui suit, sauf que dans mon cas ce n’est pas impossible, cela dépend de la taille du volet de la vitesse du moteur et de la distance a parcourir
Si on demande un mouvement de 1% je pense que l’on est inférieur a la seconde

4

Bonjour,
J’ai eu un truc similaire en zwave sur les rgbw malheureusement côté jeedom ou plugin zwave il n’y a pas de bug le soucis vient du firmware du module qui remonte mal son état dans mon cas c’était un retour d’état avant la fin de la transition donc forcément c’était faux…

5

Visiblement le bug est récent est un défaut aléatoire?
Y a t’il pas moyen sur le plugin zwave de filtrer ce defaut

6

Je sais pas j’y connais rien en zwave je dis juste que vu le plugin ya de grande chance que ça vienne du module car le but du plugin c’est de toucher le moins possible au données issu des modules.

7

On est 2 dans ce cas.
Le soucis est apparue avec la dernière mise a jours du plugin zwave, est ce que les module on leur firmware mise a jours?

8

Non la faut que ludovic regarde je suis complètement incompétent sur le zwave (en plus j’aime pas le zwave)

9

Ok pas de soucis, de toute façon j’ai dis au utilisateur de désactiver la gestion manuel du plugin pour garder les autres gestion active.

10

@mika-nt28 c’est corrigé dans la dernière beta, si tu peux la récupérer (recompiler oui malheureusement c’est au niveau du code C) et me confirmer que tu as plus le cas

11

Bah moi je n’ai pas de zwave mais je vais demander au utilisateur s’il veulent bien faire un test
Est ce bien ce comportement qui est corrigé?
C’est a dire un event mais pas d’historisation a la sources?

image
image1402×739 20.2 KB

12

Je comprends pas juste au dessus tu dis « on est deux dans ce cas là ».
un évent non historisé n’a rien à voir avec le plugin
Par contre la remontée de l’état final après l’action oui et ça c’est corrigé (je parle de celles non induites par le module lui même bien sûr)

Ton testeur devra installer la beta du plugin zwave et la recompiler par contre

13

On est 2 a rien comprendre au Zwave
Des personnes ayant ce probleme j’en ai de plus en plus et tous avec le plugin Zwave

En faite si j’historise a la fois ce que mon plugin recois par un listener et ce que l’etat du plugin zwave je sui censé avoir la meme chose.
Or on vois clairement des les graph que je recois des informations qui ne sont pas dans le plugin zwave

14

J’attends le résultat du test. Je peux pas partir sur d’autre théorie sans savoir ce que donne ce que j’ai changé.

Quoiqu’il en soit j’avais un event de l’etat final avant modif et je l’ai plus. Donc pour moi cela corrige le soucis, mais il me faut confirmation

15

Bonjour,

Oui, je comprend bien
Je n’ai pas eu beaucoup de retour, juste 1 qui etait positif.

16

J’ai relancé le sujet sur le forum car je n’ai pas de nouveau retour sur la correction, mais une nouvelle personne avec le même problème
Est ce que la modification a été publié?

17

J’ai eu la confirmation de plusieurs personne sur la résolution du problème avec la beta du plugin zwave.

Avez vous une idée de quand il pourras etre passé en stable?

18

Je viens d’avoir une remonté d’un nouvelle mise a jours de la beta provoquant le meme soucis

19

J’ai de nouveau le meme probleme.
Des utilisateurs me remonte la meme chose apres la derniere mise a jours du plugin z-wave
Je leur ai demandé de cree un ticket de support pour que de votre coté se soit plus transparant
https://jeedom.atlassian.net/browse/JEED-974