Comme certains d’entre vous je galère quand il s’agit de switcher d’une VM de test à une autre avec le fil à la patte des clés USB sur proxmox. Cette semaine j’ai réussi à planter mon zwave a cause d’une clé montée sur 2 VMs à la fois ce qui m’a valu une grosse frayeur avec mon chauffage…
J’ai donc prévu de regrouper tous mes daemons dans un docker sur une VM séparée et de découpler le tout via MQTT. Je l’ai déjà fait pour theengs, je reviens donc a la charge sur le mode distant du plugin-zwavejs
J’avais déjà posé la question l’an dernier et c’était pas dans les priorités ce qui peut se comprendre vu le boulot de dev que ce plugin a du représenter.
Je suppose que je peux toujours me rabattre sur le container zwave-js-ui + plugin-mqttdiscovery mais c’est dommage de ne pas bénéficier de toutes les features en + du plugin…
docker distant c’est pas plug and play et c’est compliqué pour beaucoup. Ceci dit pour les autres une option de daemon distant non managé serait top!
Je vois que ma question déchaîne les foules…
Est ce que l’équipe Jeedom pourrait simplement nous indiquer si oui, non ou peut-être un jour le plugin-zwavejs deviendra modulaire pour enfin pouvoir dissocier les devices du core de jeedom?
Honnetement je vois pas la priorité pour jeedom.
C’est déjà possible en passant par plugin-jmqtt (ma solution) et plugin-mqttdiscovery donc le besoin est nul à mon sens.
Après si Loic fait le boulot a ta place c’est plus simple pour toi.
Bonjour
J’ai bien vu le sujet mais si je ne répond pas c’est simplement que je ne sais pas. Je ne connais pas du tout ce plugin donc aucune idée des plans sur celui-ci
Merci pour vos reponses
J’avoue avoir du mal a comprendre en quoi c’est spécifique au plugin zwavejs ?
Si je suis votre logique de tout sur la même VM pourquoi ne pas supprimer l’option serveur distant pour MQTT tant qu’on y est?
Au passage sans lancer de polémique c’est possible sur HA et je pense pas qu’ils soient en mode dégradé contrairement à la solution plugin-mqttdiscovery qui n’a pas été faite pour ca …
je ne sais pas si tu as bien interprété l’avertissement que j’ai fait donc je me permet de préciser vu que tu cites le passage: il est là pour prévenir qu’effectivement il ne sera pas possible de tout gérer via jeedom; toutes les commandes et tous les modules (reconnu par zwavejs) fonctionneront mais plugin-mqttdiscovery
ne gère pas l’installation de zwavejs, ni les mises à jour,
ne permet pas de faire les inclusions depuis jeedom (il faut aller sur l’interface de zwavejs)
ne permet pas de modifier les configs des modules, ni les groupes, ni ping, soins etc (de nouveau il faut aller sur l’interface de zwavejs)
n’affiche pas de graphique du réseau, ni la liste des voisins etc
bref, toute action liés au protocol sera à faire dans zwave-js-ui
tous le reste (utilisation des commandes et équipements) fonctionnera de façon transparente
et donc c’est possible sur jeedom aussi puisque c’est ce protocol qu’utilise plugin-mqttdiscovery
les gens qui font ca sous HA, eux aussi, ils installent eux mêmes leur zwavejs pour y arriver
Je comprends absolument pas ta réponse. J’ai juste dit que je ne m’occupe de ce plugin donc je peux pas vous dire si c’est prévu ou non…. Et oui c’est spécifique au plus car c’est lui qui s’occupe de décoder tous ce qui vient de zwavejs et de discuter avec lui si il n’y avait rien de spécifique il n’y aurait pas de plugin
Juste pour info je suis dans le même cas, j’utilisais le plugin ZwaveJS sur mon pi mais en passant sous Prowmox j’en ai profité pour isoler quelques processus, j’utilise donc maintenant l’interface web Z-Wave JS GUI pour le paramétrage et Jmqtt pour le côté Jeedom (je viens d’acheter mqttdiscovery pour la partie Bluetooth Theengs, je vais vois si je vais l’utiliser également pour le zWave).
C’est effectivement moins intégré qu’en passant par le plugin mais une fois que le paramétrage est fait, ça fonctionne parfaitement donc je comprends que ce ne soit pas la priorité.
Merci pour vos retours
Je comprends que ca n’est pas la priorité donc je vais faire comme @arcameca
Ceci dit je reste convaincu que la modularité de la plateforme devrait etre un objectif à moyen terme de l’équipe Jeedom, c’est le but même de la containerisation et des microservices. De ce que j’en vois ces derniers temps ca n’en prend pas vraiment le chemin…dommage
Je pense que les deux solutions doivent cohabiter.
La majorité des utilisateurs ont débuté la domotique sur un raspberry PI en utilisant les services intégrés mais pour ceux qui ont des installations plus importantes l’isolation des processus en utilisant la containérisation ou différentes VM est une option intéressante.
Juste pour info pour ceux que ca intéresse j’ai fait qques modifs dans le plugin-zwavejs
Il est maintenant capable de fonctionner avec un daemon docker distant
L’installation des dépendances locales zwave-js-ui n’est plus nécessaire.
Cf ces screnshots avec zwavejs/zwave-js-ui latest:
J’ai fait quelques tests tout a l’air de fonctionner normalement.
Si ca intéresse quelqu’un il faudrait faire qques ajustements:
Je n’ai pas adapté le paramétrage dans la page config, le daemon docker n’est pas managé et il faut copier les fichiers /var/www/html/plugins/zwavejs/core/config/config à la main sur le volume du docker
