J’ai deux systèmes domotiques - Jeedom (depuis 4 ans) et HomeAssistant (dernièrement) - tous deux installés en VM sur mon NAS Synology. Jeedom est en production transféré récemment depuis ma box Smart (crashée), et HomeAssistant est quant à lui en test.
Je suis confronté à la problématique du montage de mes dongles USB Enocean et autres protocoles. Les appareils USB ne pouvant pas être partagé entre les VM, je me pose la question comment font ceux qui, tout comme moi, ont 2 systèmes, pour switcher de l’un à l’autre lorsqu’ils veulent simplement faire des test ou découvrir HomeAssistant ? Faut il démonter les dongles à chaque fois puis éteindre la VM avant de relancer l’autre VM et monter à nouveau les dongles USB ?
J’ai une installation qui fonctionne pas mal avec Jeedom et voudrait simplement découvrir un peu le monde HA sans risquer de casser quoique ce soit côté Jeedom.
Merci pour vos retours d’expérience
Le MQTT est La solution, tu partageras ton broker sur les deux systèmes.
Ensuite si pas de MQTT possible sur un protocole et bien soit tu définies qui portera l’information et il te faudra faire un transfert de commande vers un des deux systèmes je pense.
Merci Jerome pour cette solution et ta réactivité. Je n’avais aucune idée d’une telle possibilité et remarque maintenant qu’il y a des articles sur le sujet. Je vais étudier du coup la question.
Sans rentrer dans les détails, cela veut il dire qu’il faut configurer chaque équipement côté Jeedom pour qu’il envoie ses messages via MQTT et puisse ainsi les partager à toute autre système ?
Cela n’est il pas un peu laborieux pour chaque équipement de le configurer pour MQTT ?
Du côté de l’autre systèmes - par exemple VM avec HA - faut il configurer chaque équipement spécialement pour intercepter les messages de MQTT où bien cela est il transparent ?
En résumé, je me pose seulement la question si cela représente un gros investissement temps de pouvoir partager ses dongles USB entre deux systèmes
Sur ton Jeedom de prod avec les dongles, tu renvois les principales commandes en MQTT. Oui, ça peut long, j’avais tenté une solution « push global ». Voir ici
Puis conversion HTTP vers MQTT dans NodeRed. Dans le principe, c’était très efficace ! Mais il y avait trop de commandes dans Jeedom et j’avais des « timout » partout donc j’ai refait à la main les exports avec le plugin JMQTT en utilisant l’option « Auto publication » à chaque changement de valeurs (ça évite de faire des scénarios).
En récupérant ces infos MQTT, tu construis petit à petit les scénarios domotique dans HomeAssistant en parallèle, puis tu désactives ces mêmes scénarios dans Jeedom lorsqu’ils sont prêts dans HomeAssistant
euh je detere mais tu passes comment en docker ?
zwave ?
zigbee ?
et surtout homebridge ? (comme homebridge le plugin peut se connecter a du docker apres)
Alors je ne comprends pas bien ta question…
Pour « passer en docker », tu crées des containers avec les applications dont tu as besoin.
Perso j’ai Jeedom en VM, puis Mosquitto, zwave-js et zigbee2mqtt en docker
Salut Bad
Je fais le passage d’un raspberry vers proxmox. Et je me demande comment bien installer mes truc2mqtt. Je lis ta phrase et cela me pose des soucis de compréhension. où sont installés les docker de mosquitto, zwavejs et zigbee2mqtt? Dans la VM, une autre VM ou la partie container de proxmox (ou système équivalent)?
Merci
Alors perso je suis sous VMware ESXi.
Donc pas de « lxc », mais une VM linux avec docker (et portainer) installé dedans.
Mais la suggestion de Mips est tout à fait valide dans ton cas
Bonjour, et pardon s’il s’agit d’un hors sujet - quoique lié - mais ton propos m’interroge sur la possibilité d’avoir un jeedom et un HA qui cohabitent. On est d’accord qu’avec ta solution, l’intégration de zwave se ferait via des équipements « mqtt » et non des équipements « zwavejs » au sein de jeedom ? ou y a t-il une possibilité de paramétrer le plugin jeedom zwavejs pour utiliser un docker déporté avec zwavejs dessus (et qui pourrait être mutualisé avec une autre plateforme domotique) ?
oui, je crois que c’est ca
zwave-js qui tourne ailleurs; tout seul comme un grand ou sous HA ou sous un autre jeedom ou n’importe quoi, mais j’avais plutot en tête seul dans son container à lui, connecté à un broker dans un 2eme container et jeedom qui consomme ces données via mqtt (à gérer manuellement via plugin aux choix ou automatiquement via le discovery)
mais il existe une autre initiative sur base d’un fork de plugin-zwavejs mais je n’ai pas regardé exactement ce qu’elle permettait; je pense que c’est de brancher le plugin sur une instance zwave-js séparée
malheureusement non, mais l’autre sens est possible.
Tu peux faire en sorte que zwavejs de jeedom soit accessible par d’autre plateformes.
C’est comme cela actuellement que je partage mes équipements zwave entre Jeedom et Home Assistant.
Ca serait par contre super intéressant que le plugin zwavejs de Jeedom puisse pointer vers une installation personnalisée, pour réaliser la dépendance dans l’autre sens
Je suis développeur.
Mon installation repose sur un NUC sous Proxmox, avec :
Jeedom (VM + MariaDB)
Home Assistant (VM)
MariaDB en LXC pour HA
Oui, HA est en SQLite par défaut. Je n’ai rien contre, mais pour de nombreuses raisons (perf, maintenance, analyse), MariaDB/PostgreSQL reste préférable.
Quand on surveille un peu les ressources, on voit vite la différence entre Jeedom et HA.
Proxmox a été mis en place précisément pour tester HA.
Je suis passé d’une VM Jeedom sous VirtualBox (Windows) à une VM Jeedom sous Proxmox en 1h tout compris. Très bonne première impression, motivation maximale.
Mon installation Jeedom
Scénarios et logique
De nombreux scénarios complexes
Beaucoup de DANS xx FAIRE (fonctionnalité incroyable)
Environ 35 virtuels et 20 scripts
Protocoles et intégrations
EnOcean
MySensors (très pratique pour faire ses propres capteurs, malgré quelques incohérences de communication)
Z-Wave (≈ 50 modules piles/secteur, prix un peu élevé)
Gateway MyHome (1 capteur température + 3 capteurs de porte — migration prévue vers Zigbee)
RFXCom
Caméras
Netatmo
BLEA
SigFox
LoRa
Cozytouch / Overkiz
iRobot
ESPEasy
Enedis
MQTT
Jeedom Link
Communications
Mail
Mail listener
Telegram
Slack
Pushbullet
Plugins majeurs
Alarme
Thermostat
Suivi Conso (de loin le plus utilisé)
J’ai clairement testé beaucoup de technologies par curiosité.
Je suis ingénieur, j’aime bidouiller (ESP, Arduino) et modifier les plugins si nécessaire et qui me posent problème.
Pourquoi Home Assistant ?
Jeedom me convient globalement, mais :
Mauvaises surprises lors de certaines mises à jour
(notamment les migrations Z-Wave, parfois jusqu’à modifier la base à la main)
Application mobile trop limitée (Jeemate / Jeedom Connect peu testés)
Envie de repartir sur une installation plus propre
Influence des YouTubeurs (Abrège, Les Frères Poulain, etc.) → effet hype
UI Home Assistant très agréable et réactive
Application mobile excellente
Développement très rapide des nouvelles intégrations (Matter, Thread)
Intégration Overkiz séduisante
Activité GitHub impressionnante
Bref je suis à fond sur homeassistant, pas que jeedom ne me convienne pas mais plus la nouveauté.
J’ai l’impression qu’avec home assistant je vais pouvoir faire tout ce que je veux plus facilement, plus ouvert, plus configurable nativement (je ne sais pas trop expliquer ce préjugé)
Passage de Jeedom à Home Assistant
Premières impressions positives
Détection automatique de nombreux équipements réseau
Beaucoup d’add-ons non fonctionnels (ex : HA_enoceanmqtt)
Navigation et menus peu clairs
Concepts recorder, statistics, long-term statistics mal expliqués
YAML OK (je fais du Docker)
Configuration des entities assez fermée
Détails par intégration
Overkiz
Bug sur certains paramètres (Eco room temp = 3.5°C ?) ok cela pourrait correspondre à autre chose que la température eco de la piece ?
Paramètre peu clair mais UI correcte
En fil pilote externe, le mode réel (confort/eco) n’est pas affiché → toujours “Auto”
UI très réactive et propre
MySensors
Implémentation HA non conforme au standard MySensors
Je ne vais pas m’étendre sur le sujet. La doc concernant l’intégration sur HA ne correspond pas à la doc dans Mysensor
=> j’ai du refaire mes capteurs pour que cela respecte le « non-standad » HA
=> je n’ai pas de solutions simples pour faire pour historiser les VAR1
=> là j’avoue j’ai commencé à rager
Refonte complète de ma gateway en MQTT
Énergie
A ce moment là j’essaie l’onglet energie ( et oui j’ai un teleinfo sur mysensor) bon c’est pas mal mais très loin de plugin conso de jeedom (après je n’ai pas regardé s il existait autre chose dans HA, probablement)
Par contre la mysensor les données peuvent avoir des loupés (1 fois par mois) Impossible de gérer l’historique ou plus précisément gérer des valeurs aberrantes (HA propose soit filter soit NodeRed en amont )
/!\ Spoiler Alert - oui alors nodered vous allez comprendre c’est la réponse à tout. En fait, je pense que HA ne devrait pas être installer sans nodered au risque de prise de crane et de nuit sans fin. /!\
EnOcean
Intégration Enocean bancale - certain de mes devices ne sont pas reconnus
=> pas grave il y a un addon et je veux faire du mqtt de toute façon
Addon HA_enoceanmqtt mais non cela ne fonctionne pas => je rage quitte on va faire du Jeedom → MQTT → HA (il y a un dev en dehors de HA enocean2mqtt sur le net mais pas d’intégration comme zigbee2mqtt).
Le mélange entre l’integration mqtt et l’addons mqtt. On est un peu perdu mais bon je suis un tech et je ne peux pas trop comparer avec jeedom car j’en fait peu.
MQTT
Jeedom → MQTT → HA
1.Du côté jeedom c’est assez simple je configure mon devices j’ai tout qui remonte dans le mqqt (mqtt explorer)
2.je tatonne pour l’intégration du mon device mqtt dans HA (rien ne remonte tout seul (normal on n’est pas dans mysensor) et la doc est à l’image de HA cad pas intuitive)
3. je fais du mqqt discovery cela fonctionne. bon j’ai un deuxieme interrupteur à intégrer je cherche à copier coller
4. on peut exporter le message discovery ou la config yaml. Je suis joueur je prends la seconde option
5. je prend l’addon visual studio (cool outils que je connais bien). (attention je résume mais il s’est passé 4 heures entre la compréhension de la déclaration à faire et que cela fonctionne) j’organise mon repertoire mqtt pour faire un fichier par capteurs
6. ok c’est bon mais non! tu ne peux pas faire exactement la même chose entre le discovery et la config yaml. Impossible de regrouper proprement les devices MQTT en YAML
7. bon tant pis on verra plus tard j’aurais du faire mqtt discovery
8. Mais non ! c’est quoi ces valeurs unavailable dès qu on reboot HA il faut attendre que le device réémette une info pour que cela s’affiche correctement
(ou alors jouer sur le retain de l’émetteur mais comment faire qd tu n’as pas la main sur l’émetteur et bien j’image du nodered)
→ non mais dans jeedom cela garde le dernier état nativement c’est aberrant là fréro.
Intégration Foscam
L’intégration permet de récupérer correctement les flux et certaines informations.
En revanche, les contrôles PTZ ne sont pas exposés.
J’ai tenté d’ajouter les commandes manuellement (je connais les URLs Foscam).
Problème : je n’ai pas trouvé de méthode simple pour ajouter des entities personnalisées associées à cette intégration.
Je suis donc passé à autre chose.
Intégration Netatmo
Je n’utilise qu’une caméra.
L’intégration fournit le strict minimum.
Cela reste suffisant pour mon usage, même si l’ensemble est assez basique.
Intégration Xiaomi Home
La passerelle est bien détectée.
Les sondes de température remontent correctement.
En revanche, mes détecteurs d’ouverture ne sont pas reconnus.
Intégration Xiaomi Gateway
Les devices sont détectés.
Impossible cependant de piloter la gateway elle-même (alarme, LED, etc.).
De toute façon j’avais décidé de passer sur Zigbee2MQTT.
La gateway Xiaomi ne me servira plus que comme équipement Zigbee standard, l’intégration native étant abandonnée.
Récupération des données Linky
L’add-on nécessite de passer par un service tiers (Conso API).
Cela implique de faire transiter les données via une gateway/serveur externe.
Cela ne dérange personne de devoir passer par une gateway / serveur tierce donc Conso API en l’occurrence pour faire transiter vos données.
J’ai tout juste commencé à faire des automations
Impossible de faire des scénarios sans que cela devienne une usine a gaz ou alors installer nodered
a s’arracher les cheveux
J’en suis là, j’y passe mes soirée
Conclusion (à ce stade)
Je vais continuer Home Assistant pour me faire un avis complet
Je vais garder Jeedom
L’effet hype est clairement retombé
L’IHM est-elle vraiment si importante ?
Faut-il absolument être toujours à jour ?
Beaucoup de gens autour de moi ne montent plus les versions Jeedom, leur système est stable
Je reste convaincu que MQTT est la clé
→ probablement un mix Jeedom + HA avec MQTT
→ reste à décider qui est le maître et qui gère l’IHM
PS : je manipule aussi directement la base Home Assistant pour purger l’historique.
Ce dont je suis certain :
j’ai passé 5 fois plus de temps sur Home Assistant que sur Jeedom.
Etant sur Jeedom depuis plus de 8 ans (smart box puis maintenant VM proxmox sur NUC10i7 car l’installation a bien évolué), j’ai monté une VM HA déjà pour rendre compatible mon système Spa intex puis pour faire fonctionner mon Dreame x40.
Sur jeedom, impossible de le rendre compatible mais il l’est sur HA. Et pour le gérer sur Jeedom, j’ai fait des automations pour que HA envoi par MQTT toutes les informations du robot que jMQTT réceptionne. Et j’envoi par jMQTT des commandes que HA réceptionne pour piloter le robot.
HA envoi même l’image de l’habitation que je réceptionne avec Jeedom via un script et le plugin HTML Display.
Donc oui proxmox est hyper intéressant pour interfacer les différentes VM (j’ai aussi une VM unifi, Bitwarden et un pti serveur minecraft qui tourne dessus).
Je réfléchi à externaliser mon broker MQTT sous LXC histoire de déporter la charge de jeedom…
Par contre de mon point de vue, HA est tellement loin de jeedom côté user friendly ! Je ne passerai jamais mon installation sur HA. Mais faut dire que les choses avancent plus vite quand même sur HA que sur Jeedom…
pas besoin de IObroker pour déporter MQTT. Un simple container Docker avec Mosquitto MQTT suffit.
C’est l’installation que j’ai chez moi : Ni le broker MQTT, ni Zigebee2MQTT ne sont dépendant de l’un ou l’autre système : chacun dans son container.
Oui mais dans le cas de iobroker les protocoles sont totalement indépendant de Jeedom ou HA.
Et de la cas de Geoblack où Enocean ne fonctionne pas sur HA
Très bonne première impression, motivation maximale.