Bon, toujours pas fonctionnel.
Je vais attendre.
1 « J'aime »
Bonjour à tous,
Pour information j’ai fais aujourd’hui l’exclusion puis l’inclusion de toutes les vannes Danfoss et voilà le résultat sans aucune modification sur les commandes
Malheureusement ils ne sont toujours pas membre d’aucun groupes
Bonjour,
J’ai aussi un problème de fonctionnement avec des vannes POPP.
J’ai identifié que les groupes sont vides. Il y a bien une liaison en zwave, les valeurs remontent bien. Par contre, le lien fonctionnel avec jeedom ne marche pas: ils ne sont pas dans le meme groupe.
J’ai fait un ticket en Decembre. Le sujet devait etre réglé dans la mise à jour suivante. Pour le moment, l’évolution n’a pas été apportée et n’est pas tracée dans le changelog
@Heliospeed
Bonjour,
Je teste Z-Wave JS avec mes têtes Danfoss LC 13.
Dans Z Wave j’utilise ton widget Danfossliving et cela fonctionne parfaitement. Toutefois avec Z-Wave JS j’ai bien l’icone mais aucune info dans le rond central et aucune possibilité de « + » ou « - ».
Peut être que cela ne fonctionne pas avec Z-Wave JS ?
Bonjour,
Je viens de voir ton message.
Je n’ai pas encore testé le widget, car la commande pending ne fonctionne plus avec Z-Wave JS. Du coup, faudrait un mode dégradé pour piloter la température ou faire un nouveau widget…
Comme le plugin Z-wave JS est gratuit et que je n’ai pas de pack Jeedom, je ne peux pas ouvrir de ticket pour avoir de l’assistance pour rendre fonctionnelle la commande Pending de la vanne.
@Heliospeed
Merci pour ta réponse.
Dommage car j’aimais bien ce widget: très représentatif et fonctionnel.
Peut être que quelqu’un aura une oreille attentive pour régler ce problème ?
Merci à cette « oreille »
@naif, j’espère aussi que quelqu’un trouvera une solution pour cette commande qui est pourtant bien créé sur le nouveau plugin.
Sinon peut-être qu’il faut un scénario avec du code pour affecter une valeur à la commande pending lorsque l’on change la consigne. Ou en passant par un virtuel… C’est des idées qui me passe par la tête, mais j’ai peur que ce soit des usines a gaz pour une fonctionnalité qui est probablement corrigeable dans le plugin.
Bonjour, j’utilise la « consigne pending » openzwave de ces vannes pour détecter les actions manuelles sur la vanne et les répercuter sur le thermostat Jeedom, et pour agir comme si les changements de consigne étaient instantanés dans certains scenarii. Rien de bloquant mais certains enchaînements seront moins réactifs sans cette information…
L’info n’est pas sur l’arbre de la vanne, ni en openzwave, ni en zwavejs, comme s’il s’agissait d’une astuce dans openzwave pour simuler une commande qui serait absente du module (je spécule, si quelqu’un a une explication nous en saurons plus).
Peut-être est-il possible de recréer l’information (dans un virtuel ou une variable) en se basant sur la commande « statut du noeud » (Awake/Asleep) et la fonctionnalité « Action avant/après exécution de la commande » dans la configuration de la commande de consigne.
Je ne sais pas (encore) s’il est possible de récupérer la valeur de la commande slider elle-même…
Si vous avez plus élégant je suis preneur 
Bonjour,
En attendant qu’une nouvelle fonctionnalité voit le jour (ou jamais…), j’ai créé un virtuel reprennant toutes les commandes de ma vanne (que j’ai besoin) + un scénario.
Principe de fonctionnement :
Lorsque je souhaite modifier une température, j’interviens que sur le virtuel et plus précisement sur la valeur du pending et je la répercute vers la commande (du plugin z-wave) via un scénario.
Si j’interviens sur la vanne/tête (physique) sur le radiateur, je fais l’opération inverse pour mettre à jours la commande pending du nouveau virtuel.
Avec ce principe, je pense avoir retrouvé l’ancien fonctionnement.
L’idée est la suivante, mon virtuel s’appele « Tête radiateur » et la vanne dans le plugin z-wave à le même nom auquel j’ai rajoute " hardware" derrière (ex :« Tête radiateur hardware »). J’ai nommé le virtuel avec un nom plus « user Friendly » car c’est lui qui sera visible sur le dashBoard.
Ensuite pour le virtuel, je remets les commandes suivantes :
Remarque, mon virtuel et le non-virtuel doivent être dans la même pièce.
Pour le scénario, je déclenche le scénario avec des évenements lorsque la consigne pending du virtuel est différente de la consigne du virtuel. (La consigne du virtuel pointant sur la consigne zwave)
ex de déclencheur :
J’ai mis dans le scénario ce bloc de code pour réaliser les opérations que j’ai décris plus haut (c’est un premier jet de code)
J’ai fais du code pour avoir tous les déclencheurs de toutes mes vannes sur un seul scénario (ce qui est plus facile à maintenir surtout au début)
$trigger = $scenario->getRealTrigger();
$triggerName = cmd::cmdToHumanReadable($trigger);
if (strpos($triggerName,'pending')>0){
// Action sur la vanne virtuelle => commande consigne pending du virtuel
$cmdNameConsignePending = cmd::byString($triggerName);
// valeur de la consigne correspondante
$newConsigne = $cmdNameConsignePending->execCmd();
// Définition de la commande de la vanne hardware (renommage par rapport au nom du virtuel)
$cmdNameCommandeHardware = str_replace('[Consigne pending]', '[Commande]',$triggerName);
$names = explode("][", $cmdNameCommandeHardware);
$cmdNameCommandeHardware = str_replace($names[1], "$names[1] hardware",$cmdNameCommandeHardware); // Ajout de hardware dans le nom de la commande
$cmdConsigneCommandeHardware = cmd::byString($cmdNameCommandeHardware);
// Application de la consigne sur la commande hardware.
$options = array('slider'=>$newConsigne);
$cmdConsigneCommandeHardware->execCmd($options, $cache=0);
scenario::setData($cmdNameCommandeHardware, strval($newConsigne));
$scenario->setLog("Maj commande (hardware) : $cmdNameCommandeHardware : $newConsigne");
}
else{
// Action sur la vanne physique ou objet zwave direct => Commande Consigne du Virtuel (qui pointe sur la consigne Hardware)
$cmdConsigne = cmd::byString($triggerName);
// Valeur de la constigne correspondante
$newConsigne = $cmdConsigne->execCmd();
// Définition de la commande "Commande" du virtuel qui mettre à jour la "Consigne pending" du virtuel
$cmdNameCommande=str_replace('[Consigne]', '[Commande]',$triggerName);
$cmdConsigneCommande = cmd::byString($cmdNameCommande);
// Application de la commande sur le virtuel
$options = array('slider'=>$newConsigne);
$cmdConsigneCommande->execCmd($options, $cache=0);
scenario::setData($cmdNameCommande, strval($newConsigne));
$scenario->setLog("Maj commande (pending) : $cmdNameCommande : $newConsigne");
}
C’est pas parfait et ça pourra être certainement amélioré (j’ai pas testé tous les cas possible ex déclanchement manuel du scénario, tests nombre occurrences tableaux, …).
Je ne sais pas s’il ne faut pas envisager de faire une fonction personnalisé.
Je partage si cela peut servir à quelqu’un.
Bonne soirée
Bonjour à tous,
Petit up sur le sujet, à date tout fonctionne bien avec la clé zwave.me, pas avec la gen7 …
Probablement une incompatibilité avec cette clé.
Bonjour,
Avais-tu essayé de la mettre sur une rallonge usb ?
Slt,
Oui les têtes thermostatiques ne veulent rien savoir …
Bonsoir
Je viens de tester ta solution pour consigne pending avec zwavejs… et c’est parfait pour moi .
Je viens de modifier 5 LC13 (sur 10) et c’est bien OK dans les 2 sens (bon les temps de réponse des LC13 ne sont pas tjrs tres rapides . mais on s’y fait)
Merci encore et bonne soirée