Je suis sur Jeedom depuis 4 ans maintenant et utilise le plugin Openzwave depuis le début. Aujourd’hui, tous mes interrupteurs muraux sont des modules Fibaro et dépendent donc du z-wave.
Ayant acté la fin de vie du plugin Openzwave pour cause de dépendance à Python2 et à l’heure où le passage à Debian 11 devient vraiment un sujet, je me pose la question de la meilleure stratégie à adopter. Ainsi, je me permets la création de ce nouveau sujet en espérant que mes réflexion puissent être utiles à d’autres.
La stratégie choisie doit forcément prendre en compte l’existant. Aussi, voici un bref résumé de mon installation :
NUC Proxmox
VM Jeedom + VM MQTT(debian+mosquitto)
plugin openzwave et clé aotec sur Jeedom
plugin JMQTT sur Jeedom
OrangePi avec clé conbee et Zigbee2MQTT
Utilisation de mon broker MQTT par Jeedom, Zigbee2MQTT et Rhasspy
Après avoir lu quelques articles et posts, il me semble que la solution présentée ici conviendrait pas mal à mon infra. Je pourrais ainsi à terme me passer de mon OrangePi et rapatrier la partie Zig2MQTT dans un container sur ma VM MQTT de la même manière que pour la partie z-wave.
L’utilisation du nouveau plugin zwavejs sur Jeedom semble utiliser de toute manière MQTT pour communiquer avec Jeedom. Aussi, je me demande si, malgré la tentation de simplement migrer sur ce nouveau plugin, mon installation ne gagnerait pas en simplicité en installant zwavejs2MQTT à part et en utilisant mon broker MQTT déjà existant et le plugin JMQTT déjà présent dans mon installation.
Je serais très intéressé de vos avis sur mes interrogations et heureux de bénéficier de conseils de personnes ayant mieux fait le tour du sujet que moi.
Je n’ai pas testé zwave2mqtt en direct mais j’ai testé #plugin-zwavejs et vu que les deux reposent sur zwavejs2mqtt en fait, la différence est simple: il n’y a pas (ou quasi pas vu que c’est en beta) de soucis d’intégration et de gestion des modules, surtout ceux actuellement reconnu par #plugin-openzwave donc on branche et ca marche; c’est un gain de temps non-négligeable.
De nouveau, pas testé zwavejs2mqtt mais il faut je pense créer pas mal de choses manuellement, parfois il faut chercher les bons paramètres pour son module etc (retour uniquement sur base des questions que j’ai vu passer sur community)
Dans les 2 cas il reste la migration des équipements et commandes jeedom (depuis les équipements #plugin-openzwave vers le nouveau) mais ca c’est identique dans les 2 cas et un nouvel outils de migration va probablement voir le jour pour faciliter cela
Donc si vous cherchez la simplicité, le #plugin-zwavejs s’impose…
et pour finir, vous pouvez utiliser votre broker existant, aucun soucis, mais il faut installer #plugin-mqtt2 et connecter ce dernier à votre broker actuel (et ne pas en installer un nouveau).
Vous n’utiliser par #plugin-jmqtt ou autre avec #plugin-zwavejs
C’est une question intéressante que je me suis aussi posé il y a 2 ans
A l’époque, je n’avais pas de souci avec le plugin zwave, mais je sentais bien que les envois de commande et les retours d’état n’étaient pas ultra rapides.
J’ai intégré mes premiers modules zigbee à ce moment-là, j’avais alors du temps et du matériel (hors prod) pour faire des tests avec docker et zigbee2mqtt et mosquito en docker.
Mes tests ont été concluants et j’ai été séduit par la modularité et l’indépendance entre les briques fonctionnelles proposée par le MQTT (au point de m’investir directement dans le plugin jMQTT).
Ca permet entre autre, pour chaque brique (protocole), sans impacter Jeedom ou le reste :
une meilleure surveillance des systèmes,
des mises à jour au plus près des solutions source (sans la couche Jeedom),
des la sauvegardes simplifiées,
la mise en place d’une version spécifique ou un retour arrière rapide vers une version précédente en cas de problème.
Aujourd’hui, j’ai migré tous mes protocoles/devices domotique en MQTT (zw, zb, bt, esp), Jeedom ne fait que les tâches évoluées (scenario, gestion du chauffage et des volets, etc) et tout roule
Si tu ne l’as pas vu, il y a un autre sujet intéressant ici :
Merci pour ton retour qui apporte de l’eau à ma réflexion.
Effectivement, j’ai un peu de mal à évaluer le travail de portage que je vais avoir à faire dans les 2 cas. Si un outil de migration plugin-openzwave => plugin-zwavejs voit le jour, il apparaît que le plugin zwavejs devrait être la solution la plus simple à mettre en oeuvre.
Mais sera-t-elle pour autant la plus pertinente ? Avoir des plugins qui fasse doublons ne m’enchante pas. De même que le fait d’avoir le plugin zwavejs et jeedom sur la même machine qui communique via une machine tierce me semble pas optimal même si cela ne doit poser aucun problème.
Plutôt que Proxmox, je suis parti sur VMware ESXi, il existe une version gratuite avec toutes les fonctionnalités, mais prend ce avec quoi tu es le plus à l’aise.
Pour l’autre VM, je te recommande de faire une VM Docker plutôt que juste une VM Mosquitto.
Ca fait un peu inception (Docker dans la VM dans le NUC…), mais cette VM Docker sera le socle idéal pour évoluer par la suite.
En installant Portainer, tu auras un panneau de contrôle Web de tous tes containers (Mosquitto, zw, zb, etc) et la possibilité de cloner ou migrer un container, de faire des tests dessus et revenir en arrière si ça se passe mal.
Coté migration, il n’y a malheureusement pas de raccourci :
Il faut refaire la découverte de chaque équipement dans zwavejs2mqtt et zibee2mqtt, mais les docs sont au poil pour qui veut les lire.
Ensuite les intégrer dans jMQTT, en s’aidant des templates, des topics exposés visibles dans MQTT Explorer, de la WebUI et des docs (exemple : TRADFRI Remote Control et FIBARO Wall Plug) et de la communauté qui regorge d’exemples.
Enfin, récupérer les historiques des anciennes commandes et remplacer les anciennes commandes (sur les anciens équipements) par les nouvelles (sur les nouveaux équipements).
Le plus long c’est le premier équipement, après c’est globalement la même mécanique.
A titre indicatif, j’ai migré mes 30 équipements Zwave en une après midi, sans avoir besoin des les réassocier et de même pour mes équipements BT (mais j’ai changé de système je suis passé du plugin BLEA à Open MQTT Gateway sur esp32).
Lesquels? pcq plugin-mqtt2 (mqtt manager) et plugin-jmqtt (ou plugin-mqtt) ne sont pas du tout des doublons (alors que les 2 derniers le sont):
ok ils peuvent tous les deux éventuellement installer mosquito et ils ont tous les deux besoin de s’y connecter en pré-requis, mais cela s’arrête là.
il n’y a de base pas d’équipement dans mqtt2 et c’est pas le but d’en avoir je pense (mais c’est possible)
le but premier de plugin-mqtt2 (mqtt manager) est de permettre à n’importe quel autre plugin d’envoyer et recevoir des messages via mqtt sans avoir besoin de se préoccuper des détails => potentiellement tous les plugins peuvent faire ce que font plugin-mqtt et plugin-jmqtt mais sans que l’utilisateur ne doive savoir ce qu’est un mqtt, ni un « topic », pas de « template » etc
ce plugin est en quelque sorte un plugin pour les autres plugins, pas pour l’utilisateur final; c’est une couche d’abstraction pour ne pas devoir intégrer un client mqtt dans chaque plugin.
À y réfléchir, je pense également que c’est là une utilisation de Jeedom vers laquelle je souhaite tendre, à savoir : une certaine indépendance vis-à-vis des modules matériels et une utilisation accès sur les scénarios. Une sorte de « domotique de haut niveau ».
Je vais essayer de me remonter un environnement de test pour jouer un peu avec zwavejs2MQTT. Mais, étant déjà plus que satisfait de mon utilisation de zigbee2MQTT, je suis assez emballé par le fait que mes modules zwave communiquent avec Jeedom via MQTT. Ma principale inquiétude étant d’avoir assez de temps à consacrer à ça…
