Hello
Merci pour ce tuto bien expliqué.
Cela m’a fait sauter le pas et je touche au but.
Installation de la VM : ok
Configuration de ZwaveJS2MQTT : ok - tout est récupéré sans soucis, inclusion de nouveaux jouets ok
Jeedom : création du broker : ok
Jeedom : création d’un équipement (fibaro wall plug) : ok pais uniquement pour les actions. Pour les info, les valeurs ne changent pas (alors qu’elles changent bien sur Zwave To MQTT) et je tourne en rond depuis le début d’après-midi
Je ne vois pas d’erreurs dans ce que tu.as fait, ça devrait fonctionner.
Est-ce que tu as utilisé la version stable ou bêta de jMQTT ? Si stable, tente la bêta.
Autre piste pour laquelle ce n’est qu’une intuition : essayer en renommant Brosse_à_dents pour esquiver ce « à » qui pourrait poser problème si mal pris en compte côté jMQTT. Brosse_dents ?
Je sais c’est bizarre que le on/off fonctionne mais bon faut bien tenter quelque chose
J’ai utilisé la version stable
Pour l’option 2, j’avais essayé mais cela n’avait pas fonctionné.
Mais j’ai continué à investigué et j’ai trouvé la solution.
Voila ce que j’ai fait si cela peut aider quelqu’un
J’avais initialement créé un équipement de 0 donc créé 5 commandes telles que sur ma capture d’écran précédente.
J’ai du en créer 3 autres : les commandes « mères » des infos (sans la notion {value} et à partir de là, tout fonctionne
Alors non je n’ai pas eu à faire ça sur les équipements et typiquement pour ma prise Fibaro j’ai fais exactement celle de ta première capture.
Je pense que la différence vient du fait que, comme je le disais dans le tuto, j’ai créé systématiquement un équipement avec « ajout automatique des commandes » mais que je n’utilise plus ensuite.
Comme tu t’en doute je ne maîtrise pas jMQTT puisque je ne l’ai pas codé mais du coup il semblerait que cette étape soit assez importante puisque ça n’a pas fonctionné pour toi en la zappant.
J’ai un petit question concernant la configuration notamment du port de la clé
Est il possible de force le port sur /dev/ttyACM1 ? Car zigbee2mqtt utilise le ACM0 déjà et cel rentre en conflit et j’ai donc les deux services qui déconne un max
Sorry quelques soucis hier soir,
Du coup cela fait quoi ce petit bout de code exactement ?
Il créé ce fichier a un endroit précis ou peut importe ?
En me faisant aider un peu hier soir on me dit que le soucis viendrait d’un problème au niveau des ports persistants sous Linux.
Linux décidé au démarrage du port qu’il va allouer à la premier clé qui va démarrer et que c’est la qu’entre en jeu l’histoire du port persistant que semble ne pas avoir intégré zwavejs2mqtt.
Il faudrait ouvrir une issue auprès de zwavejs2mqtt pour que dans la liste des ports au niveau du setting soit affiché les ports persistants.
Mais je ne sais pas faire ce point, je ne sais pas où ça se trouve pour faire une issue et je ne sais pas si ça va résoudre le problème aussi
Mais hier soir avant de me coucher j’étais en ACM1 tout fonctionnait top.
Dans la nuit de nouveau tou HS, je l’ai vu ce matin en levant.
J’ai mis ACM0 dans le setting et c’est reparti
J’aimerais que cela reste sur le même port tout le temps afin que cela fonctionne tout le temps
J’envisageais de te faire faire un lien symbolique pour faire pointer ton ttyACM0 vers un ttyUSBx.
Le script donne la correspondance entre les /dev/x et les matériels branchés pour bien voir quelle clef avait ACM0 et quelle clef avait ACM1.
Mais bon là j’ai l’impression que tu as un autre problème, ce n’est pas normal que, sans reboot, la clef zigbee ou zwave switch d’un ACMx à l’autre. On dirait qu’elle perd un instant le contact ou l’alimentation.
Ouvre un sujet à part histoire de voir si quelqu’un a une idée de ce « switch » de clefs
Pour ceux qui sont passés en zwavejs2mqtt, toujours contents par rapport a openzwave ?
Quels sont les améliorations pour qqun comme moi a de nombreux problèmes en zwave :
modules dead récurrents
ordres perdus
pleins de messages d’erreurs dans les logs « dropping command » ou autres « coudn(ta stack… »
queue qui sature
des associations qui se créent toutes seules entre modules (!)
Ces soucis disparaitraient ???
Je pose toutes ces questions car je me tâte soit a passer a zwavejs, soit abandonner le zwave …mais j’ai environ 60 modules…
modules dead : je ne peux rien dire, je n’avais pas ce problème avec openzwave
ordres perdus : depuis la bascule il y a quelques mois j’ai du avoir un ordre perdu seulement de mémoire et c’était exécuté depuis jeedomconnect du coup je ne suis même pas sûr que le problème est à imputer à zwavejs2mqtt mais peut-être à l’application qui ramait à ce moment là.
messages d’erreurs : quand ça marche comme sur des roulettes on ne regarde plus les logs
queue qui sature : ça n’existe plus
associations qui se font tout seul : je n’ai jamais constaté ça sous openzwave
Donc je l’ai déjà dit en début de tuto mais pour moi c’est un gros soulagement d’avoir migré.
Et avec 60 modules, franchement ça vaut le coup d’essayer d’autant plus que tu es visiblement sur VM et il te sera donc assez simple de monter la nouvelle infrastructure .
Module dead : aucun en 5 mois (sur plus de 60 équipements)
Ordres perdus : La fonction Qos prend en charge la réexpédition des ordres en cas de besoin, donc le problème n’existe plus
Message d’erreur : quasiment aucun
Queue qui sature : Cette notion n’existe plus au niveau ‹ user › avec MQTT, je n’ai plus jamais constaté de latence depuis ma bascule
Associations spontanées : Je n’ai jamais connu le problème
En un mot, passer à MQTT c’est, après des années de galères périodiques avec le plugin Zwave, UN VRAI BONHEUR, et si tu ajoutes la gestion du Zigbee, tu as un ensemble homogène qui demande ZERO maintenance
Pas de soucis, n’hésite pas à faire un retour, si des choses ne sont pas claires où se passent un peu différemment ça permettra de mettre à jour pour les suivants