Bonjour,
Dans le plugin boilerThermostat, je prend en compte les evenements de changement de consigne qui interviennent sur les vanne thermostatique pour mettre a jour la consigne dans le plugin et agir en conséquence.
Dans le cas de vanne thermostatique ZWave, les evenements sont assez etrange, par exemple si la consigne actuel est 20. Si je change sur la vanne et que je met 18, je vais bien recevoir un evenement qui va m’indiquer que la consigne de la vanne est 18 et j’ai en plus une information qui me dit que c’est une mise a jour de la consigne (car le « collectDate » de la commande d’info de consigne est égale au « valueDate »). Ca c’est parfait.
Par contre si je change la consigne depuis jeedom, le comportement est très différent. Par exemple, si la consigne actuel est 20. Je change la consigne via jeedom et je met 18. Je reçois deux événement dans la même seconde qui me disent :
1 - la consigne est 18 et c’est un changement (car valueDate = collectDate)
2 - la consigne est 20 et c’est un changement (car valueDate = collectDate)
L’ordre de ces deux événement peuvent changer.
Comment exclure l’événement incorrect? (voir les deux car a priori au moment de ces événement, la vanne n’a pas encore réellement changer et elle changera vraiment a son prochain réveil).
Ça me pose de gros souci car le plugin set la valeur de consigne des vannes en fonction de la consigne défini sur l’équipement du plugin et inversement. Quand les consignes sont cohérentes, pas de souci mais les « faux » événement font que ça boucle
Si on ne peut pas filtre ces événements, est il possible de gérer une variable de l’instance de la class afin de garder un « historique » des valeurs de consigne de la vanne et ainsi pouvoir identifier un événement réelle. Attention, il ne faut pas stocker ces valeur en base car il faut un grande réactivité sur la lecture et la maj des valeurs (du fait que deux evenements peuvent se produire dans la même seconde dans le cas d’une maj de consigne de la vanne via jeedom).
Enfin si ce n’est pas possible, quel solution vous semble envisageable? (au pire une variable static dans la classe équipement pourrait être utiliser?)
Merci
A+