Sur leur GitHub j’ai vu des gens créer des fonctions via :
Mais je ne suis pas sûr que ce soit ce que tu as avec le plugin non ?
Que donnent les logs du plugin zwavejs ?
Tu dois avoir quelque chose d’assez proche de ce que j’ai mis dans mon tutoriel.
Ca te permettrait de voir si le thermostat réagit via un message MQTT publié par le thermostat.
Effectivement c’est disponible, et j’ai repris ce que tu as écris:
Mais j’ai le message d’erreur suivant:
Non, ici c’est du Javascript qu’il faut utiliser : Z-Wave JS UI
Là dans l’immédiat, j’inspecterais les logs pour voir si j’ai une réaction du node suite à l’envoi du payload MQTT, ça ressemble à ça les logs ZwaveJS normalement :
value: 6
2023-01-27T19:39:36.003Z SERIAL » 0x011d00a90125119f032100a59e67c338b139aa62a4a3e1f224000000000014 (31 bytes)
2023-01-27T19:39:36.003Z DRIVER » [Node 037] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x24
│ callback id: 0
└─[Security2CCMessageEncapsulation]
│ sequence number: 33
└─[SupervisionCCReport]
session id: 30
more updates follow: false
status: Success
duration: 0s
2023-01-27T19:39:36.010Z SERIAL « [ACK] (0x06)
2023-01-27T19:39:36.011Z SERIAL « 0x010401a90152 (6 bytes)
2023-01-27T19:39:36.012Z SERIAL » [ACK] (0x06)
2023-01-27T19:39:36.012Z DRIVER « [RES] [SendDataBridge]
was sent: true
2023-01-27T19:39:36.838Z SERIAL « 0x011e00a8000125159f038c00dff7585afe80325c7ab4c4110a97ca2a4300a5d2 (32 bytes)
2023-01-27T19:39:36.840Z SERIAL » [ACK] (0x06)
2023-01-27T19:39:36.841Z CNTRLR [Node 037] [Multilevel Sensor] Ultraviolet: metadata updated [Endpoint 0]
2023-01-27T19:39:36.842Z CNTRLR [Node 037] [~] [Multilevel Sensor] Ultraviolet: 0 => 0 [Endpoint 0]
2023-01-27T19:39:36.845Z DRIVER « [Node 037] [REQ] [BridgeApplicationCommand]
│ RSSI: -91 dBm
└─[Security2CCMessageEncapsulation]
│ sequence number: 140
└─[SupervisionCCGet]
│ session id: 31
│ request updates: false
└─[MultilevelSensorCCReport]
type: Ultraviolet
scale: UV index
value: 0
2023-01-27T19:39:36.852Z SERIAL » 0x011d00a90125119f032200554859664034746a695000e9a1240000000000dd (31 bytes)
2023-01-27T19:39:36.853Z DRIVER » [Node 037] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x24
│ callback id: 0
└─[Security2CCMessageEncapsulation]
│ sequence number: 34
└─[SupervisionCCReport]
session id: 31
more updates follow: false
status: Success
duration: 0s
2023-01-27T19:39:36.860Z SERIAL « [ACK] (0x06)
2023-01-27T19:39:36.863Z SERIAL « 0x010401a90152 (6 bytes)
2023-01-27T19:39:36.864Z SERIAL » [ACK] (0x06)
2023-01-27T19:39:36.864Z DRIVER « [RES] [SendDataBridge]
was sent: true
Bonsoir,
La passerelle je l’ai trouvé dans la configuration du plugin MQTT Manager
Topic racine Jeedom : jeedom
OK merci je n’y connait rien en javascript mais je vais tester
J’ai testé le javascript mais ça ne fonctionne pas. clairement je me suis trompé quelque part, mais mes connaissances limitées ne permettent pas plus.
Voici le code que j’ai écrit:
service: zwave_js.invoke_cc_api
data:
command_class: "49"
method_name: sendReport
parameters:
- 1
- 0
- 20
endpoint: "0"
target:
device_id: "9"
Et le message d’erreur qui est remonté:
Clairement ça bloque dejà à la première ligne
Petit update. Plutot que d’essayer de pousser la temperature exterieure vers mon thermostat de facon hasardeuse, je décidé d’essayer de setter la consigne tout en regardant le log de Z-Wave JS UI.
premierement j’ai setté la consigne à travers le widget, et le log me donne ça:
2023-02-07 14:42:14.861 INFO MQTT: Message received on zwave/9/67/0/setpoint/1/set: '20.5'
2023-02-07 14:42:14.869 INFO Z-WAVE: Writing 20.5 to 9-67-0-setpoint-1
2023-02-07 14:42:14.985 INFO Z-WAVE: Node 9: value updated: 67-0-setpoint-1 20 => 20.5
Ensuite j’ai créé une commande dans JMQTT avec une consigne de 18°C:
Je regarde à nouveau le log et voici ce que je vois:
2023-02-07 15:01:20.007 INFO MQTT: Message received on zwave/_CLIENTS/ZWAVE_GATEWAY-Jeedom/api/sendCommand/set
: '{"args":[{"nodeId":9,"commandClass":67,"endpoint":0},"sendReport",[1,0,18]]}'
J’en déduit que mon message se rend bien jusqu’à Z-WAVE JS, mais qu’il n’est pas compris. Qu’est ce qui ne va pas dans ma syntaxe?
Sur les liens que tu avais donnés, ils utilisent la CC49.
La documentation du STZW402+ n’étant pas très fournie, difficile de deviner, est-ce que tu peux m’envoyer par MP un dump de ton node ? Pour ce faire :
Je pense que le formattage est bon, la preuve la commande part.
On peut confirmer en regardant le code du thermostat sur Github (https://github.com/stelpro/Ki-Z-Wave-Thermostat/blob/d106ec8c640d3288850e672bf88352beff6f57c7/devicetypes/stelpro/stelpro-ki-thermostat.src/stelpro-ki-thermostat.groovy#L373) que les incréments se font bien de 0.5 en 0.5.
Donc il y a au minimum une précision de 1 (1 décimale) demandée. Refais le test avec 18.0 par exemple.
Ca devrait changer la valeur ici :
Si toujours pas, je t’avoue que je n’ai pas d’autre piste 
Alors plusieurs choses :
On a ici la preuve que ce que tu veux faire fonctionne : https://github.com/zwave-js/zwave-js-ui/issues/336, on remarquera qu’il y a la propriété « Air temperature » ET que la valeur qu’il a envoyée est à 1 décimale. Je pense que mon intuition se confirme. 55.0 aurait sûrement fonctionné également.
Concernant ton autre question reçue en MP, à savoir comment envoyer une commande setpoint via l’API, je te remercie car ça m’a permis de bien parcourir la doc et de comprendre enfin le fonctionnement de tout ça. 
L’erreur est d’utiliser une commande « sendReport » pour une action de type « setpoint ».
C’est ça qui m’a mis sur la piste : Z-Wave JS UI
Tu as deux méthodes pour envoyer des valeurs ou commandes sur des périphériques du réseau :
zwave/_CLIENTS/ZWAVE_GATEWAY-Zwavejs2Mqtt/broadcast/set
{
"commandClass": 67,
"endpoint": 0,
"property": "setpoint",
"propertyKey": 11,
"value": 20
}
Tous mes équipements qui ont une command class 67, lié au controlleur 0, avec une property « setpoint » (ce qu’on retrouve bien dans les topics MQTT classiques sans passer par l’API), de clé 11 (je dois préciser la clé car j’ai 1 ou 11, 1 étant le mode chauffe, 11 le mode éco) doivent recevoir la valeur 20.
Je me permets de ne pas ajouter de décimale à 20 car ma vanne accepte les précisions 0,1 et 2 (ou alors j’aurais écrit 20.0 ou 20.00) ce qui je le rappelle je ne pense pas être le cas de ton thermostat de précision a priori 1 uniquement.
Sauf cas particulier (gérable par scénario) où on souhaite changer la consigne de TOUS les équipements concernés, nous on va plutôt utiliser le multicast, valable pour un ensemble de noeuds (qui peut être unique).
zwave/_CLIENTS/ZWAVE_GATEWAY-Zwavejs2Mqtt/multicast/set
{
"commandClass": 67,
"endpoint": 0,
"property": "setpoint",
"propertyKey": 11,
"nodes": [17],
"value": 20
}
C’est très ressemblant mais ici j’ai défini une liste de noeuds (attention, ce n’est plus nodeId mais nodes, au pluriel même s’il y a un seul noeud).
Testé chez moi, ça fonctionne parfaitement.
Maintenant, la question, comment j’ai compris ce que je devais envoyer ? ben j’ai simplement regardé le dump json que tu m’as envoyé et les miens, exemple :
{
"id": "27-67-0-setpoint-11",
"nodeId": 27,
"toUpdate": false,
"commandClass": 67,
"commandClassName": "Thermostat Setpoint",
"endpoint": 0,
"property": "setpoint",
"propertyName": "setpoint",
"propertyKey": 11,
"propertyKeyName": "Energy Save Heating",
"type": "number",
"readable": true,
"writeable": true,
"label": "Setpoint (Energy Save Heating)",
"ccSpecific": {
"setpointType": 11
},
"stateless": false,
"commandClassVersion": 3,
"min": 8,
"max": 28,
"unit": "°C",
"list": false,
"value": 18,
"lastUpdate": 1675725811990,
"newValue": 18
},
Voilà ce que j’ai pour une de mes vannes, j’ai juste cherché les paramètres dont j’ai besoin pour caractériser la commande que je veux envoyer.
En utilisant MQTT Explorer, j’ai pu voir qu’à partir du moment où j’ai caractérisé la property, la command class, le noeud, etc… il a juste besoin d’une valeur :
{"time":1675725809000,"value":20}
A priori le temps est juste un timestamp pour le logging et l’historisation.
Finalement j’ai fini par y arriver! Je suis reparti d’un setup propre, j’ai supprimé mon broker et mon equipement, et recréé depuis zero. Et ça a fonctionné du premier coup. Il devait y avoir une erreur cachée quelque part.
Merci pour ton aide
Tant mieux !