Tu fais du double donc un inactif qui te sers à avoir la source et un productif ok 
A date, le daemon jMQTT reçoit tous les messages pour les topics souscrit sur les équipements, et les envoie à Jeedom qui fait l’association entre les messages réellement destinées à des commandes info.
Le daemon n’a pas la vision des commandes info, juste des topics souscrits.
Donc en supprimant les topics inutiles, tu réduis légèrement la charge de traitement de Jeedom, car il n’a pas besoin de mettre à jour des commande et faire de historisation, mais ce n’est pas fulgurant non plus.
En résumé, fait au plus simple pour toi 
2 « J'aime »
Salut,
Je rencontre un problème assez bizarre. J’ai voulu tester zwavejs2mqtt d’abord sur mon NAS puis sur mon Raspberry. Dans les deux cas, je suis passé par Docker, avec le même résultat : tout fonctionne très bien pendant quelques jours, plus l’interface web de zwavejs2mqtt devient impossible à charger, alors que je docker continue à tourner. Les messages s’échangent normalement avec le broker mqtt, mais lorsque je rentre l’adresse du docker dans mon navigateur, je n’obtiens que des pages vides. Je suis tellement perplexe, et peu compétent en docker, que je ne sais pas où commencer à chercher.
Mon NAS est un Synology DS218+ sous DSM 7. Mon Raspberry est un 3B+ fraîchement installé, sans rien d’autre que la dernière version de Raspberry Pi OS, docker et le container zwavejs2mqtt. J’ai tout installé avec les paramètres par défaut, sans toucher à rien à part l’adresse de la clé zwave.
J’ai résolu provisoirement le problème sur le NAS en passant le container en mode host. Mais je ne sais pas s’il ne vas pas réapparaître, ni comment faire sur le Pi.
Des idées ?
Bonjour,
tu devrais relancer le container docker zwave je suppose. Vois dans ses logs si tu a des erreurs ? ça m’est arrivé ce matin il a planté lorsque j’ai tenté l’inclusion d’un nouveau module.
docker ps
pour voir la liste des containers et repérer le libellé de ton container zwave
docker logs -n 20 zwavejs2mqtt
c’est peut être possible d’avoir ces logs via l’interface de ton synology ? Sinon je te conseille de lancer un portainer c’est une image docker qui te permet d’ausculter / relancer / paramétrer les autres containers avec une interface graphique.
Merci pour ta question ça m’a permis de voir que j’ai plein d’erreurs dans mon container zwave 
Salut,
Merci pour ton retour. Sur le NAS, depuis que j’ai passé le container en mode host, je n’ai plus de problème. Ça m’ennuie un peu de laisser tourner un container avec les droits root en permanence, mais c’est une autre question. Surtout, mon NAS est mal placé tout au fond de la maison, donc j’aimerais mieux utiliser le Raspberry pour le mettre au milieu. C’est là que ça se complique : j’ai essayé de regarder les logs, mais comme seule l’UI ne fonctionne pas, ils sont saturés des messages reçus du réseau zwave et retransmis vers le broker mqtt. Les choses se passent un peu s’il y avait une redirection qui fonctionnait en mqtt mais pas en http. Je vais essayer d’installer portainer pour rechercher une anomalie quelconque, mais ça me chagrine vraiment après avoir suivi la procédure officielle d’installation à la lettre ! Est-ce qu’il ne vaudrait pas mieux une installation avec snap, comme dans le tuto de Bison ?
Moi aussi je suis nouveau sur le zwavejs2mqtt, en vrai je viens de terminer cette migration il y a 2 jours, mais depuis ça tourne bien. Je suis comme toi sur docker sur un rpi4. Avec portainer (pour investiguer si besoin dans les containers), mais aussi avec Nginx Proxy Manager (proxy pour gérer mon nom de domaine), avec zwavejs2mqtt, le broker mosquito… bref 7 containers en tout et jusqu’ici ça tourne bien. Et mon jeedom est sur un autre RPI. Mais c’est temporaire je vais tenter de tout mettre sur le même.
Nous en sommes donc presqu’au même point Ça confirme quand même que ce bug est vraiment curieux. Tu n’as rien fait de particulier pendant l’installation ?
non rien, mais jusqu’à peu j’étais en mode test, je l’ai redémarré régulièrement mon zwave, donc je n’ai pas encore de recul.
Mais d’autres l’utilisent depuis longtemps et il est réputé stable, tu as quelle version ?
Les dernières j’imagine : 6.1.0 pour zwavejs2mqtt et 8.9.0-beta.0 pour Z-Wave JS. Ce sont celles que j’ai obtenues en utilisant zwavejs2mqtt:latest sous docker.
Mais bon, je ne suis pas certain de faire la transition finalement : en testant davantage, je n’arrive pas à contrôler certains modules aussi bien qu’avec openzwave. Lorsque l’on change une valeur avec un slider, zwavejs2mqtt transmet la commande au module, mais envoie aussi au broker un message spécifiant que la nouvelle valeur est atteinte, sans attendre le retour d’état du module. C’est un comportement volontaire, qui vise apparemment à éviter des soucis récurrents avec des dimmers. Mais sur des BSO, c’est très problématique, car il faut attendre qu’ils aient terminé leur mouvement vertical avant d’envoyer la commande d’inclinaison des lames. C’est impossible aujourd’hui avec zwavejs2mqtt. J’ai fait remonter l’info aux développeurs, mais j’avoue être assez peu motivé à passer encore 10 soirées à optimiser le fonctionnement des BSO sous zwavejs2mqtt, alors que je suis arrivé à un fonctionnement satisfaisant avec le plugin zwave.
C’est un point très délicat. Il faut pouvoir distinguer la commande action et la commande info du retour d’état.
En principe, la commande se fait avec mqtt/ma_commande/set 45 et le retour d’état se fait sur le topic mqtt/ma_commande et vaudra 45.
Si la commande se fait avec mqtt/ma_commande 45 alors le topic mqtt/ma_commande vaut déjà 45 même si la commande sur le module ne s’est pas exécutée en parallèle.
Remarque, ne suis pas encore passé à ZWaveJS2MQTT. Mais, dans mes équipements JMQTT, je me retrouve à gérer l’action mqtt/ma_commande et le retour d’état mqtt/ma_commande_actuelle qui correspond à la réalité.
Exemple :
-
Si je modifie le slider, le topic
mqtt/ma_commandeest modifié, l’action sur le module est effectué seulement en cas de changement de valeur, puis le retour d’état du module met à jour le topicmqtt/ma_commande_actuelle -
Si je modifie directement le topic
mqtt/ma_commande, la commande info qui lit le topicmqtt/ma_commandemet à jour le slider, l’action sur le module est effectué seulement en cas de changement de valeur, puis le retour d’état du module met à jour le topicmqtt/ma_commande_actuelle -
Si je modifie physiquement le module (exemple changement de consigne sur une vanne), le retour d’état du module met à jour le topic
mqtt/ma_commande_actuelle. Ensuite, j’ai un scénario NodeRed qui met à jour le topicmqtt/ma_commandeafin que le slider soit mis jour, sans relancer d’action sur le module. En effet, il a réellement une action sur le module lorsque la valeur du topicmqtt/ma_commandeest différente de celle du topicmqtt/ma_commande_actuellecar il faut absolument éviter les boucles.
Je suppose que chaque protocole implémente le mqtt à sa sauce (?) Pour le zwave j’ai l’impression qu’on a toujours cette convention, en tout cas pour tous les objets que j’ai pu intégrer:
-
zwave/topic/ma_commande/currentValue{value}représente l’état de l’objet, la valeur, le retour d’état, etc… et c’est en lecture seule on ne peut pas publier sur cette valeur, si on le fait c’est juste ignoré, et ça n’aurait pas de sens (si par exemple c’est un capteur de température, ce serait idiot de publier une consigne de température à ce capteur) -
zwave/topic/ma_commande/targetValue{value}ou plutôtzwave/topic/ma_commande/targetValue/setreprésente la consigne, la commande, etc.
Cette convention se retrouve quasiment partout dans mes modules.
Le {value} permet de n’avoir que la valeur du json, sinon on a aussi un timestamp, un nodename, une location etc… dans le json.
Merci @Domatizer pour ces précisions. J’ai constaté la même chose que @pifou : le problème que je pointe est vraiment un comportement intentionnel de zwavejs2mqtt, qui aligne la currentValue sur la targetValue sans attendre le retour d’état du module (cf. la discussion ici avec les développeurs).
Votre discussion me fati penser à ce que j’essaie de comprendre (je débute avec MQTT).
Je pensais ceci:
- On modifie un slider sous JEEDOM → 2) Envoie sur le broker MQTT → 3) ZwaveJS lit et se prépare à envoyer la trame Zwave au module → 4) le module reçoit le message → quid des confirmations??
Je prend l’exemple d’une tête thermostatique Danfoss que j’essaie de configurer. Comme elle se réveille toutes les 10 minutes, il peut y avoir un moment ou la valeur du slider (et donc celle présente dans le broker) sont différentes de celle de la tête.
Avec le plugin Zwave, sur ce modele il y avait la possibilité de différencier la valeur « consigne » de la valeur « consigne-pending »:
Or je n’arrive pas à faire de même en MQTT:
Est-ce que cette information « consigne prending » est dans le fichier json de ce module ?
C’est peut être en effet le même comportement:
tu publie le topic .../tete_cuisine_c/67/0/setpoint/1/set = 23 comme consigne et tu t’attends à recevoir .../tete_cuisine_c/67/0/setpoint/1{value} = 23 au moment où le module aura effectivement reçu la consigne (donc à son réveil s’il est à pile)
Mais le mode OptimisticValueUpdate de zwaveJS te renvoie cette valeur de 23 immédiatement - à tort - comme si le module était mis à jour instantannément.
Est-ce que tu reçois un autre topic lorsque le module se réveille et reçoit la consigne ? Tu devrais voir la même valeur mais avec un timestampe différent dans ce cas.
A quel niveau?
Non, visiblement ça n’y est pas.
Je me demande comment le plugin Zwave arrive à gérer ça et à quoi correspond la la partie « instance »…
node_22.json.txt (11,5 Ko)
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.