Je continu mes tests avec le plugin z-wavejs et je constate que les commandes pour affecter les températures ne fonctionne pas ainsi que la remonté de ces dernières.
Avant nous avions 3 commandes principale :
Commande pour affecter une température
Consigne pour visualiser la température sur la tête
Consigne pending pour visualiser la température affectée (en attente du reveil pour prise en compte)
Ces commandes sont bien remontés lors de la detection mais elles sont inopérantes :
Bonjour a tous
même comportement chez moi
jeedom a jour dernière version 4.3.10
clé AEROTEC GEN 5
Z-WAVE JS version stable
MQTT version stable
même en recréant les commandes rien y fait
merci et bonne journée a tous
J’ai des Popp et leur équivalent Devolo. Je n’ai aucun soucis de remonté de la sonde température, mais oui, il est impossible de modifier la consigne des vannes chez moi aussi
Je suis dans le même cas de figure et la manip ne fonctionne pas.
La valeur de la commande ne se copie pas dans la consigne (ni consigne pending de fait).
Bonsoir,
Les vannes POP ou Danfos son très longue a réagir, 300 secondes dans le mode par défaut.
les miennes fonctionnes parfaitement avec plusieurs changement de consigne par jour.
la commande Pending ne fonctionne pas, et si vous rafraîchissez la page de la vanne, la command reviendra a la consigne affiché. il faut attendre que la nouvelle consigne soit prise en compte par la vanne pour revenir sur la vue.
Je vous envoie une copie de mes commandes.
Bonjour,
tu n’as pas modifié propriété de la commande consigne et de la consigne avec setpoint-1 et dans les paramètres de la commande consigne rentre #slider#. et ça devrais fonctionner.
Bonjour,
Merci pour vos retours si je comprend bien il faut remplacer les propriétés 0 de Consigne par setpoint-1 pour les commandes suivantes : commande, consigne, consigne pending
remplacer dans la commande : « commande » la valeur « type=setvalue&value=#slider# » par « #slider# »
Dans mon cas la commande et consigne sont fonctionnelles sauf que consigne pending n’est pas pris en compte.
C’est beaucoup plus technique à configurer
Merci @Dome pour ton aide, je vais pouvoir basculer sur le nouveau plugin
Bonsoir,
J’ai effectué ma bascule vers le nouveau plugin.
J’ai eu une remonté d’alerte pour les piles à 0% alors qu’avec l’ancien plugin j’étais vers 60%.
Généralement les têtes ne fonctionnait plus peu de temps après 40%.
Et effectivement la tête en question avait le logo pile d’allumé… Les autres ont le même pourcentage donc même piles étaient en fin de vie.
Tout ça pour dire qu’il y a une anomalie sur le type de pile pour la tête c’est 2x1.5V AA et non AAA.
Je remonte l’info ici car je n’arrive pas a ouvrir de ticket pour ce plugin au support.
Bon … fausse joie.
Les modifications fonctionnent parfaitement, mais la tête perd la liaison avec la clé Z-WAVE (erreur E5 sur la tête), et ce même à moins de 3 mètres …
Yes, elle fonctionne bien à peu près 3h heures et elle se met ensuite en erreur E5.
Dans le doute, j’ai changé les piles, mais pas d’amélioration, pourtant elle a bien une « activité » récente …
Peut-être une incompatibilité avec la clé Aeotec ZWA010-C Z-Stick 7 ?
Et avec l’ancien plugin tu n’avais pas cette perte de liaison.
Après je ne sais pas s’il y a des différences de portée/commuication entre une tête LC-13 et MT02650.
As-tu essayé de mettre une prise z-wave dans la même pièce pour voir si cela n’améliore pas le maillage du réseau (et le transfert d’info).
Moi c’est ce que j’avais fais car j’avais une tête qui avait du mal a communiquer avec la clé controlleur.
Slt,
J’ai profité de ce nouveau plugin pour changer de clé, j’avais une zwave.me avec l’ancien plugin.
Pour le coup, non je n’avais pas de perte de portée/com.
Et oui, j’ai ajouté 2 prises fibaro dans la même pièce (déplacées VS le screenshot) + une distance de moins de 3 mètres du contrôleur.
Salut,
Effectivement c’est probablement lié à la clé… Il faudrait tester l’ancienne clé avec le nouveau plugin par exemple.
Pour ma part, j’ai migré en gardant l’ancienne clé (zwave.me)
