Salut,
Je suis retombé sur ce post
pour la partie mqtt de rfxcom
Je me pose alors la question de savoir comment vous avez dispatché vos partie mqtt ?!
Tout tourne sur la machine Jeedom ou alors vous avez une machine Jeedom et une autre avec tout ce qui est mqtt ?
Je crois que Mips qui tourne sous proxmox a un ou des containers lxc et cela m’interesse de savoir.
En effet je suis sous esxi et je pense deja a la suite vu que depuis le rachat, je ne compte plus tropsur les évolutions
Salut
Depuis mon passage sur min pc en début d’années, j’ai une vm pour jeedom et mosquitto, zwave-js et zigbee2mqtt sont chacun sur leur lxc dédiée.
C’est plus simple poir la maintenance pour un néophyte comme moi.
Antoine
Tu es donc sous proxmox et tu as des lxc dédié OK, merci Tonio16 
Coté Jeedom tu utilises encore les plugins de ces protocoles ou tu interceptes tout via un plugin type jMQTT ?
Salut,
Effectivement je suis sous proxmox (plusieurs noeuds en fait) avec entre autres pour ce qui concerne jeedom et les protocoles domotiques:
Je pense passer ma clé zwave en déporté avec ser2net et zwavejsui qui l’utilise via socket tcp (leur config recommandée si on veut l’avoir en déporté) du coup probablement via mqtt discovery exclusivement; c’est à l’étude.
L’avantage que je cherche c’est pouvoir basculer plus facilement ma vm jeedom entre les noeuds proxmox
L’inconvénient c’est que ma machine hébergeant la clé reste un « maillon faible » (ni plus ni moins que jeedom actuellement)
J’aimerais aussi une solution pour rfxcom que j’ai encore ou alors j’élimine les derniers devices rfxcom que j’ai: sondes de températures extérieures (celles qui m’ennuient) , capteur de porte annexe (ca c’est facile à remplacer en zwave ou zigbee)
Très intéressant.
Oui on est bien d’accord que le point faible sera toujours la machine avec les clés usb et autres contrôleurs.
Cela signifie donc moins de plugins Jeedom.
Protocole et contrôleur sur un container dédié
Quid de la maintenance et des updates pour tout ça ?
Pour zwave-js-ui, j’utilise jmqtt.
Pour zigbee2mqtt, j’utilise zigbeelinker. J’ai trop de modules zigbee pour faire le changement 
Antoine
Bonjour,
Attention tu ne peux pas passer une clé BT sur un LXC.
Je n’ai pas testé mais si c’est en mode privilégié ca devrait être ok non? (Comme autre cle usb en fait non?)
Bonjour,
J’y vais aussi de ma petite configuration :
Sous proxmox, 1 vm jeedom, 1 lxc avec le broker mqtt et une vm avec les containers (via podman) zigbee2mqtt et zwavejs-ui.
Pour les mises à jour, de zigbee2mqtt et zwavejs-ui, je m’appuie sur les mécanismes de podman (podman auto-update)
Sur un autre proxmox, j’ai une vm avec frigate (toujours en container avec podman)
Et sur jeedom, l’excellent plugin jmqtt pour lier tout ça
( plus un serveur externe avec un broker externe pour partager des infos entre 2 jeedoms, un reverse proxy et le endpoint pour alexa mais c’est un autre sujet)
Salut,
Et dans le blog il y a la citation du développeur de Proxmox (et j’avais retrouvé le topic sur le forum Proxmox) :
This was extensively discussed in our german forum (link), here’s the gist of it:Bluetooth devices register themselves as a network interface, so passing through the USB /dev node is useless. Sadly, the BT network adapter is not namespaceable, meaning it can’t be assigned to a container the way regular network interfaces can.
Perso j’avais essayé dans tous les sens : impossible.
Après si quelqu’un trouve tout de même une solution je prends 
Bonjour,
Je ne sais pas comment marchent les LXC et la mise à jour d’un container.
Je suis parti pour ma part sur du full Docker, sur une VM Proxmox pour faciliter la sauvegarde toutefois.
Les clefs sont déportées sur la VM de Docker et utilisé par les containers zwaveJs, Zigbee2Mqtt, Theengs Gateway et Mosquitto au milieu.
Tout cela mis à jour par WatchTower.
Ensuite, Jeedom est sous docker aussi pour tester, mais pas vraiment d’avantage… à part la RAM utilisé qui est faible ?
Plugins :
Inconvénients :
Pour le maintien de l’os des lxc, soit tu utilises les scripts de tteck, soit des unattended-upgrades.