VM Jeedom et externalisation zigbee, zwave sur container LXC -> besoin de vos lumières

Bonjour à tous et tous mes meilleurs vœux à vous tous 🙂

Je remets les mains dans le cambouis 😉

J’ai Jeedom qui tourne sur un mini PC NUC en VM Proxmox avec le Plugin MQTT Manager en Broker local Mosquitto.

Les plugins JeeZigbee (Dongle-E USB Zigbee Sonoff) et Z-wave JS (Dongle USB Aeotec Zwave+ Gen7) y sont abonnés.

Je dois changer de disque (SSD) et avant de procéder je fais des tests sur un autre NUC pour apprendre à externaliser les protocoles Zigbee2mqtt et Zwave de Jeedom et me faire une idée si intérêt ou pas pour moi.

J’ai donc installé Proxmox 8.3, réalisé une VM avec ISO Debian 12.8 puis installé Jeedom 4.4.19 en ligne de commande → RAS 🙂

J’ai ensuite utilisé 2 scripts depuis tteck(github) :

  • 1 pour installer un container LXC pour MQTT

  • 1 pour installer un container LXC pour zigbee2mqtt

J’ai testé via MQTT Tool → OK pour le LXC MQTT, j’ai bien édité le fichier YAML pour Z2M tout semble bon, j’ai bien accès à l’interface WEB pour Z2M.

RAS pour ces parties….c’est rare pour le souligner ici car avant de me lancer j’ai décortiqué beaucoup de tutos et lu beaucoup de forums et beaucoup d’entre-nous rencontre des problèmes d’installation.

Maintenant les questions que je me pose :

1- comment faire pour inclure un équipement (Zigbee pour mes test) ?
Depuis l’interface Web du LXC zigbee2mqtt ? Pas très ergonomique je trouve !!

J’imagine que je dois installé sur la VM Jeedom le plugin MQTT Manager pour récupérer les infos depuis le Broker qui est maintenant distant car installé sur un LXC.

2-Est-ce que j’ai besoin d’installer également le plugin JeeZigbee ?

3-Est-ce que cela aurait été préférable de garder le Broker MQTT en local sur la VM Jeedom et juste laisser zigbee2mqtt en container LXC afin d’éviter des soucis ?

Merci pour vos retours, soluces, avis, ce que vous avez fait, etc …car je cale un peu mais j’aime apprendre 🙂

Salut,

Je suis entrain de remettre jeedom sur lxc en debian 12 egalement. J ai un soucis pour faire apparaitre la cle zigbee dans jeezigbee alors je n ose imaginer que toi cela soit plus simple.

Pour faire ce que tu veux il faut

Un lxc avec Mosquito

Un lxc avec z2m

Sur le lxc avec jeedom

Mqtt manager distant sur le lxc mosquito
Il te faut jeezibee sur mqtt distant pointer aussi sur le lxc mosquito

Et ton lxc z2m pointe sur lxc mosquito

La vraie question c est l interet de tout dissocier ?

Moi avec un lxc jeedom et jmqtt mosquito jeezigbee le processeur et ram son au mini de la charge.

Bon courage pour le montage

1 « J'aime »

Si si, c’est très simple et très pratique de mon point de vu.

Si tu veux rester en plugin officiel oui. Mais je ne suis pas sur de saisir l’idée derrière la question.

Perso, zwave-js-ui, zigbee2mqtt et mosquitto ont chacub leur lxc dédié. Pourquoi? Installation simple avec les scripts ad-hoc (voir lien) et facilité pour sauvegarder, restaurer, etc une lxc. Le cas du week-end, zigbee2mqtt), une sauvegarde avant mise à jour, update, plantage restauration, retour au point de départ en moins de 10 min.

Jeedom devrait proposer un script de ce type, amha.

Antoine

1 « J'aime »

L’avantage aussi d’externaliser les services (donc zigbee2mqtt et le broker), c’est qu’en cas de plantage jeedom, ton réseau zigbee continue « de vivre », et à la réinstallation/restauration de jeedom, y’a rien a configurer, tout rentre dans l’ordre instantanément.

Aussi, l’externalisation permet de facilement interfacer un autre système domotique (comme home assistant par exemple), et de pouvoir jouer avec ton réseau zigbee à la fois depuis jeedom et depuis home assistant, sans que l’un soit dépendant ou n’interfère avec l’autre.

J’ai moi aussi récemment passé mon réseau zigbee sur deux containers LXC (zigbee2mqtt & mosquitto), que je « consomme » grâce au plugin jeeZigbee depuis jeedom ,configuré en « mode distant ».
J’en ai aussi profité pour changer de dongle (anciennement SONOFF ZigBee 3.0 TI CC2652P) en passant sur un SMLight SLZB-06. Je me préserve ainsi des problèmes liés à l’USB passthrough des fois capricieux sur container LXC.

Depuis tout fonctionne parfaitement !

1 « J'aime »

Salut

J’ai sur mon promox une vm jeedom, une zigbee2mqtt et zwavejs2mqtt et un boker mqtt.
Sur jeedom le plugin qu va super bien jmqtt.
Tu configures ton broker et apres tu peux gerer tes devices.
J’adore ce principe ca m’évite davoir tout sur la meme machine et j’ai même un jeedom de teste qui est sur un mini pc et je peux faire mes testes de scénario . Si cest ok juste à migrer de l’un à l’autre.

Ps finalement idem que @Dreaky :rofl: voir même que beaucoup d’autre qui ont goûté à Proxmox.

1 « J'aime »

Salut et merci de ton retour d’expérience.

Comme indiqué dans les autres réponses c’est pour pouvoir partager mes équipements via d’autres système domotique et même via un autre Jeedom afin de tester.

Si j’ai bien compris ta config tu as tous sur un seul LXC ?

Salut Tonio16,

Si tu veux rester en plugin officiel oui. Mais je ne suis pas sur de saisir l’idée derrière la question.

En effet je me demandais l’utilité car je n’avais pas saisie le principe :wink:

Perso, zwave-js-ui, zigbee2mqtt et mosquitto ont chacub leur lxc dédié. Pourquoi? Installation simple avec les scripts ad-hoc (voir lien) et facilité pour sauvegarder, restaurer, etc une lxc. Le cas du week-end, zigbee2mqtt), une sauvegarde avant mise à jour, update, plantage restauration, retour au point de départ en moins de 10 min.

C’est en effet dans ce but que je souhaitais en profiter pour externaliser :slight_smile:
Cependant je ne comprend pas pour quoi une restauration d’un backup Jeedom ne remet pas tout en place contrairement à une restauration d’un Backup VM ou LXC.
Je te dis ça car avec le problème récent suite MàJ proposée de la version de Zigbee2MQTT en 2.0.0 (je suis actuellement en 1.42.0) il 'était impossible de revenir en arrière depuis une restor Jeedom, il a fallu une restor VM pour que cela fonctionne ???

Salut Dreaky et merci pour tes infos :slight_smile:
comment as-tu procéder pour la bascule ?
En effet je n’ai pas envie de devoir tout réappairer.

Parce qu’une restauration d’une sauvegarde jeedom ne prends pas en compte les dépendances des plugin (c’est à dire des packages ou librairies tierces nécessaires au fonctionnement dudit plugin). Pour le cas du plugin z2m, la dépendance est zigbee2mqtt (et la conf qui va avec).

Avec une restauration de VM, c’est une copie « hardware » du contenu du disque, donc on récupère TOUT (toute la couche OS). C’est d’ailleurs pour ça que la taille d’une backup VM promox est beaucoup plus grosse que celle d’une backup jeedom.

Pour tous les LXC, j’ai utilisé les « helpers scripts » de proxmox.
Alors j’ai procédé étape par étape.
D’abord le LXC qui porte le mosquitto : création+install du LXC via le script-helper, config du serveur (très simple) et j’ai ensuite fais la modif sur tous les plugins/devices qui faisaient référence au broker (modification de l’ip du broker+user+mdp). Donc plugin jeedom, devices qui se connectent en MQTT (chez moi tous mes modules shelly + opendtu solaire etc). Ensuite je vérifie que tout fonctionne correctement.
Facultatif : Installation du nouveau dongle SMLight SLZB-06. Vérification que j’y accède et je le met à jour.
Si tout est ok, je passe à l’étape suivante : Création+install du LXC zigbee2mqtt. Puis sa config : pour l’instant consistant juste à configurer sur le nouveau dongle que je viens de configurer (en mode ip donc, et plus en USB).
Ensuite, la partie la plus touchy : récupération de l’ancienne save/config du zigbee2mqtt qui était porté par le plugin z2m, pour la coller sur le nouveau zigbee2mqtt du LXC. Ici j’ai merdé, puisque impossible de récupérer mes modules, y’a fallu que je réappaire tout…
Et enfin, une fois que c’est bon (après que tes modules remontent bien dans ton nouveau LXC ou après ré-appairage) : configuration du plugin z2m en mode distant. On indique donc dans le plugin que le zigbee2mqtt est installé « ailleurs » (on renseigne l’ip+port de ton LXC zigbee2mqtt) dans le plugin. Et tu vérifies que les infos remonte bien dans tes équipements jeedom via le plugin z2m.

Facile hein :grin:

1 « J'aime »

Salut et merci également de tes infos,

as-tu tjrs utilisé jMQTT ou auparavant JeeZigbee ?

As-tu fait une migration en externalisant ? Si oui quels points d’attention à prendre (surtout afin de ne pas perdre l’appairage des modules déjà inscrits) ?

Avant j’avais encore plus anciens. Le plugin zigbee tout simplement. Il est obsolète.
J’adore jeedom mais pour les protocoles comme zigbee2mqtt etc le faire sur des vm ou lxc c’est tout simplement génial. Moi j’y ai goûté, lu pas mal de tuto etc, j’ai adopté.
Sauvegarde mensuel des vm et lxc sur un nas. Et ca roule.

La seule chose que je faisais mal au debut c’était de mettre les disk des vm et lxc sur le nas (5to) tant qu’à faire stocke dessus. Problème, rare mais c’est arrivé, apres une coupure d’électricité mise en route de l onduleur, Sauvegarde etc…arrêt. au redémarrage je me suis rendu compte que promox allait beaucoup plus vite que mon nas et que rien ne fonctionnait. Donc a éviter.

1 « J'aime »

Bonjour,

Je suis ce sujet car je me pose la même question.
Sur mon promox sur un nuc avec une vm debian 12 et tout embarqué (zigbee2mqtt jeedom mosquitto) et un lxc avec proxy inversé.

Je pèse les + et - a monter un lxc zigbee2mqtt.

En effet connaître les +(avantages) et - (inconvénients)car pour le moment j’ai tout intégré également et cela fonctionne très bien mais comme je dois migrer sur un nouveau disk SSD Nvme cela serait l’occasion de séparer Jeedom des protocoles Zigbee/Zwave !
De plus à force de lire et décortiquer les tutos ça donne plein d’idées et peut-être changer ma clé Zigbee sonoff USB pour passer sur un Adaptateur SMLIGHT Ethernet POE Zigbee 3.0 Zigbee2mqtt !

Encore un test ici :

1 « J'aime »

Super et merci Dreaky :grinning:car j’ai bien compris la différence entre une restauration Jeedom et un backup VM … C’est plus clair :ok_hand:

J’ai vu que sur le plugin JeeZigbee on pouvait réaliser dans Configuration du réseau puis dans l’onglet Actions effectuer la « Création d’un zip contenant une sauvegarde du réseau ».
Est-ce cela qui n’a pas fonctionné de ton côté ?
Et est-ce que cela est compatible sur un changement de Coordinateur ?

Concernant le remplacement de mon Dongle-E USB Zigbee Sonoff par un SMLIGHT SLZ -06 et éviter de devoir tour réappairer je viens de tomber sur cette petite vidéo sympas même si en anglais :grinning:
Les commentaires approtent aussi quelques réponses.

Une soluce pour moi sûrement mais vous quand pensez-vous ?

Perso j’y voie que des avantages. Exemple ce week-end j’ai voulu tester la v2 de zigbee2mqtt, jai fait un backup mise à jour etc. Rien ne fonctionnait correctement, j’ai vu sur le github qu’il y avait des problèmes, donc revenu sur mon backup et hop ca refonctionne.
Tu peux facilement revenir en arrière sans que jeedom ne soit impacté.
Inconvénient au debut la compréhension des json mqtt , mais maintenant pour moi c’est et je l’espère de tout coeur un protocole de communication d’avenir.
Autre exemple je teste node red actuellement. Pas besoin de faire des liens dans jeedom, je cais chercher l’information en mqtt je m’amuse.
Voilà mon petit retour

1 « J'aime »

Alors j’avais vu cette méthode aussi, mais il faut savoir que la modification de l’adresse IEEE est sans retour possible, et possible qu’une seule fois ! J’ai vu pas mal d’endroit ou c’était déconseillé. C’est un peu la méthode facile mais risqué !

Normalement, le concept de save de zigbee2mqtt permet de déporter sur une nouvelle install sans devoir tout reappairer.
Chez moi la sauvegarde n’était pas acceptée par la nouvelle install, car j’avais une erreur comme quoi l’interface ne matchait pas (usb vs ip), et du coup le restore ne fonctionnait pas. Au bout de 2h j’ai arrêté de batailler, car le temps de régler le problème allait me prendre plus de temps que de réappairer mes 35 devices à la main (même si très chiant à faire).

Du coup pour cette partie, je préfère laisser la parole à ceux qui ont réussi, car pour le coup je suis pas l’exemple à suivre…

Pour ce « problème », il existe des options de démarrage des VM sur proxmox pour à la fois :

  • Configurer un ordre de lancement des VM
  • Démarrer les VM après un certains temps

L’ordre de lancement garanti que la séquence n ne démarre que lorsque toutes les séquences n-1 sont lancées.

Par exemple pour ma part, je lance :

  • Prio n°1 : la VM qui héberge le service NAS (OMV)
  • Prio n°2 : le LXC qui héberge le service mosquitto
  • Prio n°2 + 15sec : le LXC qui héberge zigbee2mqtt
  • Prio n°3 : la VM jeedom

Comme ça quand jeedom démarre, je suis sûr que mon réseau zigbee et les services associés sont déjà up & running.

Ces options sont dispo dans le menu « options » de chaque VM/LXC :
image

Order : ordre de lancement
up : délai de lancement en seconde

2 « J'aime »

Salut , je ne connaissais pas l’astuce. Je dois utiliser 20% des possibilités de jeedom. Je vais tester.
Sympa ce fil

1 « J'aime »

Merci pour ce point d’attention sur l’adresse IEEE. Pour infos un des commentaires précise qu’il n’y aurait pas besoin justement la modifier :slight_smile:

Concernant le réappairage : comment fais-tu pour t’y retrouver car dans mes scénarios le nom du module qui a disparu est remplacé par #un chiffre# et là c’est la grosse galère pour savoir lequel avait été utilisé :scream: et à la vue du nombre de scénarios ça m’inquiète !!