Je viens de vérifier, il y a bien le topic lors de la modification de la consigne sous Jeedom via le slider mais rien lorsque la tête se réveille pour appliquer le réglage.
Le QoS ne permettrait pas de gérer ça?
Pour info, voici le log zwavejs2mqtt lorsque je modifie la consigne sur Jeedom de 26 à 21:
QoS de 1
noeud zwave 22
equippement Tête_cuisine_C
-----consigne de 26 à 21-----
2021-12-14 16:42:49.771 INFO MQTT: Message received on zwave/Tête_cuisine_C/67/0/setpoint/1/set: '21'
2021-12-14 16:42:49.771 INFO ZWAVE: Writing 21 to 22-67-0-setpoint-1
-----réveil de la tête-----
2021-12-14 16:43:44.246 INFO ZWAVE: Node 22 is now awake
2021-12-14 16:43:44.246 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/status: { time: 1639500224246, value: true, status: 'Awake', nodeId: 22 } with options { qos: 1, retain: true }
2021-12-14 16:43:44.283 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/67/0/setpoint/1: { time: 1639500224283, value: 21 } with options { qos: 1, retain: true }
2021-12-14 16:43:44.284 INFO ZWAVE: Node 22: value updated: 67-0-setpoint-1 26 => 21
2021-12-14 16:43:44.322 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/67/0/setpoint/1: { time: 1639500224322, value: 21 } with options { qos: 1, retain: true }
2021-12-14 16:43:44.322 INFO ZWAVE: Node 22: value updated: 67-0-setpoint-1 21 => 21
2021-12-14 16:43:44.364 DEBUG ZWAVE: Node 22: mapping value(s) of property 'level' (level) from CC 128 (Battery) to node property 'minBatteryLevel
2021-12-14 16:43:44.364 DEBUG ZWAVE: Node 22: mapping value(s) of property 'level' (level) from CC 128 (Battery) to node property 'batteryLevels
2021-12-14 16:43:44.364 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/status: { time: 1639500224364, value: true, status: 'Awake', nodeId: 22 } with options { qos: 1, retain: true }
2021-12-14 16:43:44.365 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/128/0/level: { time: 1639500224365, value: 68 } with options { qos: 1, retain: true }
2021-12-14 16:43:44.365 INFO ZWAVE: Node 22: value updated: 128-0-level 68 => 68
2021-12-14 16:43:44.365 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/128/0/isLow: { time: 1639500224365, value: false } with options { qos: 1, retain: true }
2021-12-14 16:43:44.365 INFO ZWAVE: Node 22: value updated: 128-0-isLow false => false
-----la tête se rendort automatiquement-----
2021-12-14 16:43:45.398 INFO ZWAVE: Node 22 is now asleep
2021-12-14 16:43:45.398 DEBUG MQTT: Publishing to zwave/Tête_cuisine_C/status: { time: 1639500225398, value: true, status: 'Asleep', nodeId: 22 } with options { qos: 1, retain: true }
Etonnamment, il n’y a pas plus de communication avec une QoS de 2…
Ca doit discuter plus sur la couche réseau.
Peut être un truc à essayer avec le flag retain. Est-ce que tu as coché la case retain en face de la commande de slider ?
Edit :
Bof non ça doit pas aider.
Peut être en regardant le timestamp pour déterminer si oui on non le module a reçu la dernière information…
Exact, avec un retain ça feraitmon affaire 
Saut que je n’arrive pas à la lire la valeur du set (23) 
Je n’ai pas compris ?Je reprends les valeurs de ta capture pour exemple.
Ca va correspondre à la valeur du slider le 23 donc pourquoi aller la lire ? C’est toi qui l’a défini. J’avais compris que tu voulais que la valeur info reste à 24 le temps que le module se réveil, non ?
En fait j’utilise un widget code sur mes têtes thermo qui affiche la consigne réglée (consigne pending).
Si la consigne en action sur la tête est différente, la valeur s’affiche en rouge.
Mais il faut bien 3 choses pour que ça fonctionne:
- la commande (slider)
- la consigne pending (en gros c’est la valeur du slider qui est en attente d’envoi à la tête)
- la consigne appliquée (différente de la consigne pending tant que la tête ne s’est pas réveillée)
La « consigne pending » correspondrait à « set » (23)
1 « J'aime »
Et bien du coup ça devrait le faire non ?
- La commande d’action slider qui fait le /set
- Une commande info (a créé) qui reprend la valeur du slider donc la consigne pending
- la commande info qui est le …{value} et qui correspond à la consigne appliquée
Sinon désolé je dois rater qqchose d’évident pour toi 
Celle là je ne vois justement pas comment faire 
Et bien ne rien mettre dans la commande consigne (elle est liée au slider).
Et créer une commande info « consigne appliquée » avec l’actuel contenu de ce que tu as mis dans la commande info consigne.
Si je ne renseigne rien dans un topic (ton carré rouge):
Et c’est le slider qui prend la valeur de la consigne non? pas l’inverse?
Ah j’avais jamais essayé de ne rien mettre.
Tente de faire un virtuel du coup 
.
La commande slider passe au Broker l’instruction de faire le /set donc de modifier la consigne de la tête thermostatique, elle ne récupère rien.
Donc je ferai :
Équipement jMQTT :
- commande action slider sans lien avec une commande info
- commande info « consigne appliquée » avec le {value} du cadre rouge
Équipement virtuel :
- commande action qui appelle la commande action de jMQTT et lié à la commande info consigne
- commande info consigne vide
- commande info « consigne appliquée » qui appelle la commande info de jMQTT
Si je peux faire sans un virtuel j’aimerais autant mais si pas le choix tant pis…
- commande action slider sans lien avec une commande info
Sauf erreur de ma part, ce qui est entouré en rouge permet au slider de prendre la valeur de la commande « consigne » (ici le slider prend 22 au repos) sinon le slider ne sait pas quelle est sa valeur actuelle avant qu’on ne le modifie.
- commande action qui appelle la commande action de jMQTT et lié à la commande info consigne
- commande info consigne vide
Même remarque que précédemment si info « consigne » vide, ce n’est pas en liant la « commande » action que info « consigne » changera de valeur, c’est l’inverse…
Ah, ben voilà, cool 
1 « J'aime »
Alors, ton objet répercute la consigne sur le topic au moment du réveil, et pas avant, comme attendu, et à l’inverse des modules de @Mael …
La seule différence c’est le module à pile, zwavejs attend son réveil avant de publier le topic de confirmation dans ce cas. Ce n’est pas un retour d’état.
Salut,
Pour info, il est possible de rafraîchir isolément les valeurs, pour récupérer seulement celles dont on a besoin sans surcharger le réseau.
Il faut créer une commande avec comme topic : zwave/_CLIENTS/ZWAVE_GATEWAY-zwavejs2mqtt_RPi/api/refreshCCValues/set
(à modifier en fonction du nom sous lequel zwavejs2mqtt communique avec le broker mqtt)
Et comme valeur : {"args": [4, 38, 1]} où 4 représente le node et 38, 1 le topic mqtt. Pour référence, voici la commande info concernée : zwave/salon/jalousie_2/38/1/currentValue{value}
Voilà toujours une chose qui marchait bien avec openzwave, qu’il est finalement possible de faire avec zwavejs2mqtt ! Par contre, il n’est pas possible d’utiliser des templates pour automatiser la création de ces commandes avec jmqtt.
J’ai vu qu’en redémarrant le client MQTT concerné les informations non rafraichies mais présentent en « retained » dans le topic remontent.
Ok merci pour l’information, le but est donc de forcer une remontée d’information sans attendre un report ou un changement de valeur naturelle d’un module c’est ça ?
C’est ça. Ça permet de forcer le retour d’état lorsqu’il ne se fait pas correctement, pour une raison ou pour une autre. Je m’en sers pour des modules volets roulants qui ne signalent pas toujours les mouvements commandés par les interrupteurs.
