Jeedom sur VM, zigbee2mqtt, zwavejs2mqtt

Bonjour la communauté,

N’ayant pas trouvé de sujet similaire à ma situation, je me permets donc de vous solliciter pour des conseils avisés :face_with_monocle:.

Sur un mini pc Lenovo Thinkcentre je viens très laborieusement d’installer Jeedom sur une VM Debian 10 avec Proxmox (j’ai dû d’abord installer Debian 10 sur mon SSD, puis proxmox par dessus car l’install conseillée (avec la clé bootable de proxmox) ne fonctionnait pas (le SSD ne bootait pas après l’install)). De multiples soucis a priori réglés même si j’ai dû bidouiller le fichier /etc/network/interfaces dans Debian 10 : je n’avais pas de bridge vmbr0 de créé. Bref, j’ai réussi à installer une VM Debian et jeedom par dessus. Ok pour les connexions SSH.

Mon installation de base était sur un RPI3B+ avec zigbee2mqtt et le plugin zwave. Je n’ai pas peur du travail et vais refaire toute mon installation. Je repars sur Jeedom avec simplement JMQTT. L’idée serais d’installer zigbee2mqtt et zwavejs2mqtt sur le nouveau Jeedom. Le mini-PC n’a pas vraiment d’autre vocation que de faire tourner Jeedom.

Je n’ai pas de connaissance très poussées en informatique.

Questions :
Est-il plus intéressant d’installer zigbee2mqtt et zwavejs2mqtt sur Docker ? Sur le PI ou sur le mini-PC ? Est-ce que ça va être une galère sans nom pour faire communiquer tout ça ensemble ? Dois-je préférer une installation plus classique comme dans une VM pour les deux ou deux VM pour chacun ?

En fonction de vos réponses je pourrai migrer ma question vers une autre section.

D’avance un grand merci.

Salut,

Idéalement il faudrait :

  • Une VM avec Jeedom
  • Une VM avec zigbee2mqtt et zwavejs2mqtt en docker.

Mélanger Jeedom avec autre chose, c’est jamais la meilleure des idées
Une VM pour zigbee2mqtt et une autre pour zwavejs2mqtt, c’est trop gourmand et ça n’apporte pas grand chose en plus (surtout avec docker).

Maintenant ça c’est la théorie, parce que comme tu as a priori souffert pour installer proxmox (alors qu’en principe, on est presque sur du clic’n play), tu vas avoir quelques soucis à surmonter avec la gestion des USB (passthrough pour les rendre visible dans la VM et ensuite faire le montage avec docker).
Pour la gestion des IP, il faut penser à utiliser la reservation DHCP avec les adresses MAC de tes VM.

Pour finir, personnellement je referai une machine proxmox propre… Là très franchement, ça m’inspire pas confiance

Quelques docs :
Installation promox avec rufus : Prepare Installation Media - Proxmox VE
USB passthrough
USB Devices in Virtual Machines - Proxmox VE

1 « J'aime »

Merci beaucoup pour ta réponse.

Je suis tout à fait d’accord avec toi : je ne comprends pas pourquoi j’ai eu tant de soucis avec l’installation proxmox… Le hardware pourrait être mis en question ? Je vais retenter… De toutes façon je ne suis pas bien loin. Pis, c’est vrai que ça n’inspire pas confiance.
En tous cas, impossible d’installer proxmox depuis la clé bootable (même en testant des versions plus anciennes de proxmox). Donc je ne pense pas pouvoir m’affranchir du passage par debian avant d’installer proxmox… J’ai essayé d’installer VMware mais là la clé n’était même pas bootable (balena et rufus me l’avaient d’ailleurs signalé).

Donc je pourrais faire deux Vm : une jeedom et une debian avec docker dessus. C’est exactement ce que je souhaitais entendre ! Vaudrait mieux que je poste dans la section Docker pour la suite de l’aventure non ? Je n’y suis pas encore.

Quand faut y aller…

Encore merci pour tes conseils.

Pour la clé proxmox, il faut juste faire attention :

Rufus is a more lightweight alternative, but you need to use the DD mode to make it work. 

Et à mon avis partir sur la version la plus à jour de proxmox, c’est s’assurer le max de support materiel

Bref, bon courage

1 « J'aime »

J’ai toujours la même erreur, même en passant par Rufus. Je me tourne vers le forum Proxmox pour demander de l’aide en espérant qu’ils puissent dire ce qui cloche.

Tu as bien défini les partitions (en écrasant les anciennes) et déployé grub correctement ?

Oui. J’ai un SSD 120Go et j’ai mis 2/8/14 et 87 pour les partitions (via l’installeur proxmox). Pour Grub, je n’ai rien à sélectionner, il est censé le faire comme un grand non ? En tous cas je n’ai pas Grub qui apparait au lancement, il me dit qu’il n’y a pas d’OS sur le disque.

J’ai plus la processus d’installation en tête, mais je crois qu’à un moment donné, il propose un choix (comme débian d’ailleurs) pour confirmer qu’il se déploie

Non à aucun moment malheureusement.

Je viens de faire une VM proxmox dans proxmox…
Rien que l’installation par défaut (y compris pas toucher aux partitions)… et grub est là au reboot automatiquement


Donc soit une de tes modifs n’est pas bonne, soit un souci de compatibilité
image

C’est gentil d’avoir pris ce temps.
Je penche sincèrement pour un souci de compatibilité. J’ai beau chercher ce qui pourrait clocher, je ne trouve rien. Tout est OK dans le BIOS, je ne vois pas de secure boot ou quoi… Je vais relancer une installation debian et voir en installant proxmox les erreurs qu’il renvoit.

Si debian boote correctement, c’est pas le bios… Et comme proxmox c’est quasi pareil …
Tente une installation par défaut : aucune modif particulière en dehors des noms, login, password

Si je mets « rescue boot » (vu que normalement c’est installé).
J’obtiens la page sur laquelle je devrais atterrir (avec l’ip de la machine disant de me connecter sur mon navigateur).
J’ai :

Et je peux me connecter à proxmox depuis mon navigateur…

Bon ben, vieux cpu et faille hardware… Il y a plus qu’à suivre les indications et désactiver la partie smt.

Même en désactivant SMT, même problème. Pour le « crng init done » je ne vois pas quoi faire pour l’instant mais je cherche.

@naboleo , je comprend ton point de vue, et pour la règle générale tu n’a pas tord. Cependant, j’aimerai apporter certains points à prendre en considération.

Pour ma part, j’utilise une (grosse) stack avec du swarm / docker. Pour Jeedom, Zwave2mqtt etc.).
Et ca marche assez bien, et sans avoir une grosse conso de ressources. (4 odroids, 17 stacks, 28 services, 39 containers)

La séparation des tâches (Zigbee, Zwave et autre) n’est pas forcément nécessaire (pour 80%). Mais peux s’avérer utile si l’on veux réduire la complexité et les temps de latence sur des installations plus avancées, où certaines informations peuvent circuler vers d’autres systèmes que Jeedom (C’est mon cas => utilisation dans node-red, gcp, etc.)

Voici les scénarios :
1°) Jeedom + Plugin Zwave : Le trame arrive sur Jeedom - délai - Interprétée par Jeedom - délai - envoyée sur le plugin JMqtt (ou autre) - délai départ de la trame

2°) Zwave2mqtt → délai → mqtt <= tous les abonnées reçoivent la trame en même temps.

Réduction de la complexité : On sait que tous les informations sont centralisées sur 1 point d’entrée unique ; le master mq

Toléance de pannes : Si Jeedom + plugin Zwave plantent, et que d’autres systèmes ont besoins des trames => Coupure service. Si le conteneur Zwave2mqtt plante => Healthcheck actif => Kill et restart du conteneur => coupure de 2/3 secondes max.

Bien entendu. Comme je le disais, cela ne s’applique pas à tous le monde.
Par ailleurs, cela à un inconvenient majeur. La multiplication de config Mqtt, et de virtuels si besoin. Cela demande donc un effort supplémentaire ainsi qu’un risque d’erreur lié au facteur humain

Ce n’est qu’un avis personnel évidemment.

Salut.

On est bien d’accord que c’est une histoire de compromis. Et quand on dispose d’assez de ressources, de compétences et de temps la solution retenue change. Là je suis parti des choix simples :
Jeedom tout seul sur une vm parce que c’est vraiment pas fait pour cohabiter avec autre chose. Entre les installations de packages imposées (voir la suppression silencieuse de ceux déjà en place) et la manipulation des droits subjective), c’est pas forcément plus mal pour les néophytes. Quant à la version docker, c’est pas propre et ça complexifie la gestion quotidienne.
De l’autre du docker cette fois, mais sur une autre vm simplement par que ces deux services sont parfaitement pensés pour fonctionner de la sorte et qu’en plus on multiplie les emplacements usb : 5 disponibles restent accessibles côté jeedom et 3 ici. Il manque la précision d’y coller aussi mosquito pour être cohérent.
De plus dans l’hypothèse d’une évolution future, on garde zwave et zigbee, on y raccorde une nouvelle version de jeedom ou autre chose et zou : pas grand chose à changer.

C’est pas le sujet ici mais faire du swarm (et potentiellement du replica) avec zwave, je suis pas certain qu’on arrive à obtenir un truc qui marche facilement. Il faudrait cloner firmware les clés et les config à la volée… Personnellement j’ai jamais vu de soucis avec le container zwave même sans swarm. Le plugin est par contre parfois étrange.
Au final, on est très proche en terme de qos.
Donc ajouter la couche swarm, je vois pas beaucoup de gains versus complexité.

Après effectivement c’est un choix parmi tant d’autres. Bon ou mauvais, je ne sais pas mais en tout cas pas totalement pensé par hasard

1 « J'aime »

Tout a fait, tout dépend des besoins en effet.

le container Zwave fonctionne parfaitement bien. Pour du swarm ? tolérance de pannes. Si un de mes serveurs plante, l’autre prend le relais.

Le fait d’avoir un broker mq (sans parler de techno en particulier) sur une stacks (kube, swarm, etc.) c’est également pour permettre la scalabilité, l’élasticité et la tolérance de pannes.

Pour Jeedom, je comprends ton besoin. Il est vrai que la gestion est parfois lourde, et une VM ca aide bien. La solution Docker pour Jeedom implique des mises à jour de conteneur régulières à déposer dans un repo d’image, etc… si tu veux toujours être au top. La maintenance coute des efforts. Avec la VM tu as plus de tranquillité, c’est certain :slight_smile:

Docker pour les services annexes, je suis parfaitement de ton avis. C’est super simple à mettre en oeuvre, portable, ca fonctionne super,etc. Ne pas oublier le broker MQ également en conteneur pour les raisons évoquée plus haut.

Chaque choix à ces avantages et inconvénients. Et encore une fois, tout dépends des besoins :slight_smile:

Pour ma part, je ne juge pas :slight_smile: c’était simplement un avis personnel.
La partie swarm est simplement que j’ai tout un écosystème derrière qui ne se limite pas à Jeedom. Avec plusieurs serveurs. Et donc le balancement en cas de défaillance est aider avec Swarm (ou Kube). Depuis plusieurs années, je n’ai eu que quelques jours de coupure de service. Et pourtant, pas mal de problème matériel, mais tout a été géré et auto-réparer par le système. Maintenance proche de 1h/mois à des fins de contrôle et éventuellement tuning. Pour un installation simple, comme tu le souhaite, tu as raison, c’est totalement inutile et cela complexifie le tout.

1 « J'aime »

Merci à vous. Mon installation étant très simple, je vais rester basic :upside_down_face:.

Booon… J’ai réussi à faire installation propre de proxmox ! Update du BIOS en passant par Windows (que j’ai dû installer donc) puis réinstallation de proxmox, VM Debian, Jeedom.
Si je résume ;

  1. nouvelle VM Debian (quelles tailles pour le disque dur et la mémoire ? Pas grand chose de nécessaire non ? Serveur SSH et outils système suffisent donc ?)

  2. sur cette nouvelle VM, installation de :

Après, j’imagine qu’il faut configurer le bazar pour que tout communique correctement :thinking: (USB bien reconnu, communication entre les services).
Des liens à me conseiller ? Je trouve pas grand chose (après, je cherche surement mal).

EDIT : ou alors installer ça directement sur un RPI ?

Merci d’avance.

2 « J'aime »

Bonne nouvelle.

Pour la config, sachant que le jeedom tourne sur un pi3/1Go de ram/8Go de disque… Tu fais en fonction des ressources dont tu disposes. Le fait de faire tourner les autres services à part, ça devrait pas avoir besoin de beaucoup plus qu’un truc basique. En prenant 15go de disque (debian c’est poil plus lourd que raspio) si besoin est, il suffira juste de changer le nb de cpu/ram par la suite.

Pour le reste, rien à ajouter, tu as déjà une bonne liste des taches à faire.

1 « J'aime »