Utilisateur de Jeedom avec Zigbee2mqtt et mosquitto, je découvre HA et teste pour savoir si je migre ou non vers ce système.
J’ai installé HA dans une VM sous proxmax et Z2M et mosquitto dans 2 containers LXC.
J’ai intégré des équipements zigbee (non utilisé sous jeedom) via Z2M et ils apparaissent bien dans le dashboard HA.
Maintenant, je voudrais récupérer dans HA tous les équipements zigbee vus dans le mosquitto de Jeedom.
J’ai découvert (déception) que le client MQTT de HA ne peut pas se connecter à 2 brokers.
J’ai vu qu’il existe une notion de bridge mais je n’arrive pas à faire fonctionner ce principe.
Par construction c’est pas nécessaire. En générale le broker est commun (celui de jeedom ou celui ha peu importe)
Séparer les brokers c’est valable si tu veux isoler mais là techniquement tu fais l’inverse en regroupant jeedom et HA
Tu n’as pas besoin de 2 Z2M, ni 2 Broker MQTT.
Si tu avais configuré le MQTT existant sur HA, tu aurais eu accès à tout ton réseau Zigbee depuis les 2 plateformes en même temps.
Sans doute, mais ça soulève une autre question. Pourquoi estimes-tu nécessaire d’avoir 2 infras différentes (et donc 2 clients/moyen de se connecter au 2 infras)?
Avec Jeedom, j’utilise des protocoles (purement français) qui n’existent pas sous HA comme DataDore avec le dongle RFPlayer. De même je n’ai pas vu la possibilité d’utiliser le dongle RFXCom. J’ai commencé la domotique il y a bien longtemps avant la généralisation de zigbee et j’ai du DeltaDore depuis plus de 15 ans.
Donc j’ai besoin de conserver Jeedom.
Je vais essayer d’installer Jeedom dans un container LXC et de faire un restore de mon backup mais cela suppose bcq de taff, j’imagine.
De plus les plugins thermostat, agenda, delestage et mode fonctionnent très bien et je ne sais pas si l’équivalent existe sous HA.
Ce qui me gène avec Jeedom, c’est l’UI non responsive, le manque de stabilité (plantage fréquent de la base mySQL), les plugins officiels parfois moins bons que ceux de développeurs indépendants mais dont on ne connait pas la pérénité dans le temps.
RFplayer e(non testé perso) t rfxcom (testé) fonctionnent sous HA
A voir si DataDore est dispo ensuite, mais RFplayer étant opensource, ça doit exister
C’est pas un souci, mais c’est pas ça qui t’oblige à avoir 2 installations distinctes.
Tu peux mutualiser le brocker MQTT entre HA et Jeedom (celui de ton choix, donc tu peux utiliser celui de jeedom pour HA !)
MQTT c’est juste une plateforme d’echnages de messages. Donc tout le monde lit/écrit dedans et ça n’a pas d’impact à partir du moment ou les topics sont utilisés correctement.
pas vraiment d’intérêt à mon avis… En tout cas, je ne vois pas ce que ça te donnerai comme avantage…
Nous sommes plusieurs à avoir abandonné jeedom, il y a des équivalents thermostats et agenda (largement mieux), delestage je sais pas
oui c’est souvent ce genre de trucs qui fait basculer les utilisateurs
En tout cas, je vois que la communauté HA est bien plus réactive que celle de Jeedom.
Peux-tu me conseiller des tutos pour installer et configurer un thermostat (avec Jeedom j’en ai un par pièce avec destection des ouvrants).
Par ailleurs sais-tu si un add-on enedis existe ?
Salut, tout comme toi, j’arrive de jeedom également et nous ne sommes pas les seuls.
J’utilise tydom2mqtt qui permet de faire fonctionner deltadore sur H.A tout comme sur jeedom.
Via mon Rflink je ferme/ouvre mes volets en fonction de l’état de l’alarme.
Sur H.A, comme sur jeedom, on applique les mêmes règles. A savoir, on utilise une vielle appli (sur portable) afin de conserver un mdp sans caractère spéciaux.
Tu peux t’en sortir en utilisant un flow nodered.
Un noeud va aller lire les topics que tu as besoin dans ton jeedom et une fois récupéré tu le publies dans le mosquitto intégré dans HA.
Simple il me semble.
Installer jeedom dans un container LXC c’est faisable c’est ce que j’ai fait, mais pour moi, c’était en fin de migration parce que je n’ai gardé que le plugin ENEDIS et que j’envoie les données enedis via MQTT sur HA.
C’est un peu plus compliqué de gérer l’USB passthrough dans un container LXC (mais faisable) et il y a une limitation au niveau du Bluetooth (ça ne marche pas)
Bref pour moi ça ne se justifie que si tu veux garder jeedom après pour un plugin que tu veux garder (j’ai tous mes historiques enedis et je me suis gardé ça pour la fin)
moi non plus, d’autant que si j’ai bien compris mosquitto est installé dans un container LXC, il suffit d’envoyer tout sur ce broker et ça facilite bien les choses pour migrer les services tranquillement
dédoubler en effet n’est pas utile.
Il faut vraiment que tu en sois obligé par une solution logicielle existante qui comporte sont propre broker et que tu n’as pas d’autre choix de ne l’utiliser.
Par contre, la question de la Haute Disponibilité (HA) reste posée.
Je trouve que ce composant qui est souvent la pièce maitresse d’une infrastructure devrait être doublé (mais avec une seule adresse IP vue depuis l’extérieur). Ca reste léger de n’en avoir qu’un seul. Il vient a tomber et plus de domotique.
Il y a des solutions pour contourner ceci avec par exemple un « load balancer » mais c’est déjà du lourd à implémenter.
Je n’ai pas étudié les spec de la mouture 5 de MQTT, mais j’imagine qu’ils ont dû adresser cette lacune. Enfin j’espère.
Admettons pour la haute disponibilité.
Comme tu l’indique à condition d’avoir tous les mécanismes de résilience (d’ailleurs la seule fonction de load balancing n’est pas suffisante, mqtt c’est de l’asynchrone donc le message produit à 12h00 est potentiellement lu 2 heures plus tard, donc il faut de la réplication juste pour le cas où ça plante à 13h)
Dans le cas de @krissam44, par construction les 2 systèmes sont étanches et il envisage de faire un pont entre les deux… Quant l’un des côté du pont n’est pas accessible, ni jeedom ni ha ne fait pas fonctionnera pleinement
il te faut 2 VM load balancées par un appareil haut de gamme et en prix. Style Netscaler ou Juniper.
Ce n’est pas dans le scope d’une domotique maison, mais dans le professionnel ou c’est juste essentiel.
Le coup du bridge, je trouve que ce n’est pas une bonne solution. Mais temporaire pourquoi pas, le temps qu’il migre tout vers HA.
Par contre la solution Nodered MQTT est vraiment simple, non ?
Même nodered ça semble compliqué par rapport à une solution simpliste. Il y a toujours plus d’étapes techniques que de la solution à brocker unique.
Avec 1 brocker jeedom, on branche HA dessus = 1 config mqtt à écrire
Avec un brocker côté HA, on REbranche jeedom dessus = 1 config mqtt à REécrire
Brancher NR = 2 configs mqtt à écrire (plus le flow à réutiliser)
Je suis un gros flemmard, je ne m’amuse pas à faire des trucs longs ou complexes si j’ai pas un gain à la fin. Alors si c’est pour que j’ai encore plus de boulot (maintenance) à la fin, c’est mort pour moi
