Présentation Meute

Bonjour à tous,

Comme de nombreux utilisateurs ici, je suis issu de l’univers Jeedom et mon système domotique y tourne depuis environ 7 à 8 ans. Au fil du temps, mon installation s’est bien sur considérablement développée.

J’ai expérimenté Home Assistant et continue à le faire par intermittence depuis plusieurs mois. Toutefois, cette expérimentation se fait toujours en parallèle avec Jeedom, qui reste pour l’instant l’unique moteur et véritable gestionnaire de ma domotique.

Mon HA a accès aux mêmes équipements que Jeedom, de manière totalement indépendante. La plupart de mes protocoles domotiques étant gérés indépendamment de Jeedom et fonctionnant sur des machines virtuelles (VM) et des dockers indépendants ils sont donc aussi accessibles pour HA.

Mes principaux protocoles domotiques sont :

  • zwavejs2mqtt
    ± 60 équipements en tous genre, aucun sur batterie hormis 5 vannes thermostatiques

  • Deconz
    ± 80 équipements, beaucoup de Hue et du xiaomi

  • ModbusTCP
    Plusieurs équipements qui sont gérés par un PLC bien avant que Jeedom n’arrive chez moi (Portail, Porte garage, phares extérieurs, VMC, … et auxquels Jeedom et HA ont un accès total en ModbusTCP.

  • Quelques sondes en 433Mhz
    Qui sont les seuls équipements qui sont encore uniquement accessibles à jeedom. (RFXCom)

A ça s’ajoute tout un tas de bazars :

  • Nuki
  • 2 Rings + Chimes
  • Quelques Netatmo
  • Une dizaine de Google Nest Audio et Hubs
  • Quelques Amazon Echo Dot 5e génération, bientôt beaucoup plus … Prime Days oblige …
  • Télécommande Harmony avec hub
  • Chaudière contrôlée en eBus/MQTT
  • Caméras de surveillance sur NAS Synology
  • Système d’alarme filaire, totalement indépendant mais armable (et non désarmable) depuis la domotique
  • Capteur Flipr pour la piscine
  • Aspirateur Roborock
  • Afficheurs Awtrix contrôlés par MQTT
  • Quelques bandeaux LED Yeelight en WiFi
  • ESP32 avec un programme personnalisé pour des cas très spécifiques, comme mon poêle à bois, piloté en MQTT

Et je suis certain d’en oublier quelques-uns…

Aujourd’hui, presque tous mes équipements et services sont disponibles sur mon HA, mais uniquement à des fins d’expérimentation. J’essaie peu à peu de reproduire ce que j’ai mis en place sur Jeedom au cours de ces années, ce qui se révèle être un sacré paquet de choses.

Pour être franc, je ne pense pas effectuer une réelle migration vers HA, sauf si j’y suis contraint, par exemple en cas d’arrêt du développement de Jeedom.
Ce n’est pas vraiment Jeedom lui-même qui me pousse à chercher ailleurs, mon Jeedom a toujours été très stable et je n’ai jamais rencontré de limites pour implémenter ce que je voulais.
Les risques liés aux développeurs de plugins externes qui pourraient abandonner leur développement du jour au lendemain ou à l’équipe Jeedom SAS qui pourrait également cesser leurs activités sans préavis, sont mes principales préoccupations.

Concernant mon expérience personnelle de HA :
Les premières heures sont assez excitantes avec la découverte automatique de nombreux équipements, l’accès à de nombreuses intégrations, la configuration via le yaml pour des éléments tels que TTS Google ou Modbus, etc.
On a l’impressions que tout va bien se structurer, on organise et découpe bien ses fichiers de config à grand coup d’Includes et tout ce qu’il faut pour que tout soit bien organisé et maintenable, les sensors avec les sensors, les lumières avec les lumières, on joue avec les templates et j’en passe … On met au point ses stratégies de nommages d’entités … tout ça a l’air bien cool.
Mais ensuite, on réalise que certains équipements sont configurés dans plusieurs fichiers ou rendus quasiment invisibles dans la configuration car ils sont maintenant gérés par l’UI.
De plus, certaines intégrations nécessitent d’être supprimées et réinstallées pour permettre leur reconfiguration à la suite de la moindre modification.
Ensuite, lorsque l’on commence à approfondir le sujet et à essayer de reproduire des automatisations ou des processus spécifiques, une certaine désillusion s’installe. J’ai une multitude de scénarios sur Jeedom, structurés et utiles, parfois codés en PHP, d’autres fois carrément en Python. J’ai l’impression que toutes ces tâches qui me semblaient simples à réaliser, à structurer et à organiser sous Jeedom deviennent rapidement extrêmement complexes sous Home Assistant, même avec l’aide de Node-RED et malgré mon expérience en développement.

Donc voilà, je suis surtout ici pour m’informer et pour expérimenter, mais il est fort peu probable que je saute un jour le pas de la migration … sauf peut-être contraint et forcé.

Au plaisir de discuter avec vous.

8 « J'aime »

Superbe présentation, teintée d’une grande expérience et de beaucoup de réalisme.
En effet, les années passées permettent de prendre du recul face aux nouveautés.
Plus de pragmatisme, c’est certain !
En effet la question que l’on se pose avec du recul, est-ce que le système sur lequel on a placé tous nos efforts (nos heures de travail) va être pérenne ? who knows.

Dans l’ensemble tout se passe très bien avec HA. Stabilité, réactivité, sauvegardes et surtout restaurations sont parfaitement fonctionnelles. Un point hyper important à mes yeux.

Dans la foulée, je suis en train du coup de basculer ma solution de gestion d’onduleur solaire hybride sur HA. Je profite de Nodered compagnon (node-red-contrib-home-assistant-websocket) qui nous facilite grandement la tâche. Un gros travail et un hobby agréable.

Bonne suite à toi et peut nous diras tu un jour que tu as tout basculé sous HA :+1:

1 « J'aime »

Salut et bienvenue.

Il n’y a effectivement pas d’obligation à migrer d’un coté ou de l’autre, et c’est vrai que c’est compliqué de tout refaire quand ça marche bien.
Ceci dit, il faut éviter de calquer le fonctionnement de HA sur celui de jeedom. Tu aura largement le temps de le découvrir à l’usage
ET personnellement je pense que si tu es concerné par les soucis potentiels de longévité des plugins tu devrai aussi prendre en compte le fait que jeedom est toujours en php7.4… Version qui est End Of Life depuis novembre 2022…

2 « J'aime »

Ce n’est pas ce que je fais, j’ai bien vite compris que les solutions sont à aborder totalement différemment, je cherche juste à reproduite la fonctionnalité finale même si le chemin pour y arriver est totalement différent.
Et pour des choses que je n’ai même pas encore tenté de reproduire je me pose quand-même un paquet de questions pour savoir comment je pourrais bien y parvenir.

J’ai par exemple codé dans un scénario en PHP (mais j’aurais aussi pu le faire en scénario standard, en PHP c’était juste plus compact) tout un système de queue fifo pour transmettre toutes mes notification tts vers mes différents groupes de Google Home et d’Echo et telegram, qui me permet très simplement de lancer une notif de façon très paramétrée (groupe à notifier, volume, avec ou sans restoration du volume,…) tout en m’assurant qu’elle n’écrasera pas la précédente qui serait encore en cours, et en HA j’ai bien quelques pistes pour reproduire cela, j’entrevois comment le faire, majoritairement en node-red, mais à la vision des tests que j’ai déjà effectués sur ce sujet ca me semble tellement plus complexe aussi bien à implémenter qu’à maintenir ensuite que cela me rebute un peu.

J’ai aussi par exemple tout un process qui me construit une phrase d’état de la maison a usage multiple pour TTS, soit je demande l’état de la maison et je reçois en tts ou en telegram l’intégralité des états (lumières allumées, porte ou fenêtre ouvertes, …) ou lorsqu’on quitte la maison je reçois instantanément des alertes TTS sur ce qui serait resté ouvert (portes, fenêtre) le tout avec une construction « smart » de la phrase dans un français correct, pas un truc « robotique », donc avec les bon pronoms, les virgules où il faut, le respect du singulier et du pluriel au cas par cas … Tout ça est géré par des scénarios qui automatiquement s’imbriquent les un aux autres pour construire un état complet ou peuvent être appelés a l’unité pour avoir un état particulier, en sortie je récupère une phrase parfaitement construite prête à êtres notifiée en fonction de ce qui est voulu, j’ai l’impression que faire pareil en node-red serait une soupe pas possible, et en yaml n’en parlons même pas …

J’ai aussi des interactions tts qui nécessitent une réponse vocale, je sais que HA peut aussi le faire mais sous jeedom le « ask » me parait tellement plus simple a utiliser. Mettre en place une nouvelle question avec une réponse me prends 30 secondes montre en mains sous jeedom, sans éditer le moindre fichier ni mettre les mains dans le cambouis ni devoir relancer quoique ce soit.

Donc je ne cherche pas simplement à calquer l’implémentation « comme on le fait en jeedom », mais simplement à obtenir les mêmes fonctionnalités en finale.

Après j’ai forcément accumulé certaines habitudes et certains automatismes après autant d’années de pratique de jeedom, mais je reste toujours ouvert aux autres façon de faire, à condition qu’elles soient meilleures … Et pour l’instant c’est pas trop mon ressenti.

1 « J'aime »

Et ben, il y a rarement autant à lire dans une présentation.
Mais c’est très interessant et critique (dans le bon sens du terme).
Sois le bienvenu sur HACF :wink:
@+ Guy

1 « J'aime »

Belle présentation et bienvenue dans la communauté.

1 « J'aime »

Nous sommes en phase.
Les solutions « complexes » que l’on a peaufinées au fils des années sont longues à retranscrire dans HA et c’est un frein à la migration.
Tes expérimentations et conclusions seront les bienvenues

Bienvenue sur HACF :slight_smile:

Bienvenue parmi nous :+1:

Belle configuration !! Bienvenue sur HACF et merci pour ton partage. On sent beaucoup d’expérience et ton retour est très interessant. Après je dis toujours que le meilleur système est celui que l’on connait et qui répond a son besoin. Après un tel investissement sur Jeedom, je comprends que ce soit compliqué de changer.

Comment arrives tu d’ailleurs a faire fonctionner des périphériques type zigbee, zwave ou RTS sur les 2 systèmes ?

Autrement, une utilisation avancée de HA (comme celle que tu as avec JEEDOM) passe par une maitrise de YAML et Jinja2. Il est aussi possible d’intégrer du python comme tu le fais avec PHp, mais moins courant. A mon sens, nodered doit se limiter a du très spécifique. Avec tout cela, peu de limites…

Ensuite, la force de HA tient dans sa communauté mondiale de développeurs, son modèle open source et l’orchestration intelligence de tout cela par Nabu Casa, et de fait son dynamisme. On le voit avec l’évolution récente du TTS et Assist.
ESPHome est également une application killer pour qui fait du DIY. Peut-être une raison de garder HA a côté de jeedom pour toi (?)

Après il manque avec HA bizarrement des choses élémentaire comme une exploitation propre des statistiques long terme, les planifications récurrentes, une surveillance propre de la dispo des devices, etc… aucun système n’est parfait. Mais le nombre d’intégration est tellement monstrueux qu’on est rarement bloqué.

Comme stipulé dans la présentation,

J’ai un gros serveur ESXI avec backup auto des VM vers 2 NAS en redondance et tout ce qu’il faut avec entre autre en VM :

  • Jeedom dans une VM avec un RFXCom en USB
  • HA dans une VM
  • Deconz dans une VM avec sa Conbee2 USB
  • Sous dockers/portainer le tout dans une VM tout ce qui concerne le MQTT :
    • mosquito
    • zwavejs2mqtt avec son dongle USB Aeotec Gen 5
    • ring-mqtt (pour exposer mes Rings à jeedom en MQTT, en HA c’est pas trop utile vu que l’intégration fait le job)
    • ebusd (Pour le pilotage de ma chaudière vaillant via « ebus » > MQTT)
    • awtrix (le serveur > MQTT)

Et donc comme je disais aussi bien Jeedom que HA sont capables d’accéder à tout ce qui est exposé via le MQTT et également à Deconz vu qu’il tourne en « standalone ».

Et hormis le RFXCom tout est dispo pour les deux. Et pour ce dernier je suis certain qu’une recherche me ferait tomber rapidement sur un truc du genre « rfxcom2mqtt » et que du coup je pourrais basculer le rfx dans un docker sur ma VM « MQTT » et le rendre dispo pour les deux aussi.

Le fait de tourner en VM me permet de pas trop m’inquiéter des sauvegardes « locales » de ce qui tourne dans les VM même si ils sont aussi fait en supplément.
Le backup incrémentiel journalier avec stratégie de rétention des VM et les snapshots en cas de grosse modif ou d’update permettent à eux seul de garantir de retomber sur ses pattes en cas de gros soucis.

Le troisième mode pour faire des automatisations est d’utiliser appdaemon: Getting started — AppDaemon 4.4.2 documentation

AppDaemon Tutorial for HASS Users AppDaemon is a subsystem to complement Home Assistant’s Automation and Scripting components. AppDaemon, is a Python daemon that consumes events from Home Assistant and feeds them to snippets of Python code called Apps. An App is a Python class that is instantiated possibly multiple times from AppDaemon and registers callbacks for various system events. It is also able to inspect and set state and call services. The API provides a rich environment suited to home automation tasks that can also leverage all the power of Python.

C’est, je pense, la méthode la plus avancée pour écrire des scenarios/automatisations avec HA.
Je n’ai jamais testé.NodeRed me va bien :slight_smile:

2 « J'aime »

Top, belle config VMWare avec MQTT qui fait le service.
Mais alors, une question bête : pourquoi Deconz et pas zigbee2mqtt ? Ce serait plus cohérent au regard de ta config.
Pour connaitre les 2, zigbee2mqtt est plus stable, plus polyvalent, indépendant de la clé et supporte plus de devices….

Pour RFXCom, je ne connais pas rfxcom2mqtt. J’ai comme toi une clé (une rfxtrx433) connectée au port série et avec une intégration, mais interessant, je vais creuser.

La question n’est pas bête, il y a en effet une bonne raison.

Deconz émule un pont hue et pas zigbee2mqtt.

Et comme j’ai beaucoup de lampes et de dimmer switch hue ça me permet de configurer tout ça beaucoup plus simplement via l’app « Hue essential » et de rendre les fonctions basiques indépendantes de jeedom ou ha.

J’ai du hue partout sauf dans des pièces comme la sale de bain, le WC, le bureau, le couloir, le grenier, … où là ce sont des éclairages « non smart » pilotés par modules fibaro zwave placés derrière les poussoirs encastrés.
Donc toutes les autres pièces ont des dimmer switch hue en lieu et place des interrupteurs muraux et les circuits elec ont été modifiés (de façon réversible) pour supprimer les interrupteurs et alimenter les ampoules hue en permanence.

J’aurais aimé être sous zigbee2mqtt pour plus de standardisation de mes protocoles domotique et plus de maîtrise sur mon réseau zigbee mais l’émulation du pont hue était le critère indispensable dans mon cas.

Avec zigbee2mqtt toute liaison dimmer switch/lampes ou scène d’éclairage aurait dû être faite manuellement sous jeedom ou ha et en serait totalement dépendant.

4 « J'aime »

Et pour être franc celui qui m’a relancé pour recommencer à tester plus en détail mon HA qui végétait depuis plusieurs mois c’est @Sigalou … mais il ne le sait même pas :sweat_smile:

En gros récemment j’ai décidé de basculer de google home vers alexa pour la partie commande domotique et tts, je conserve un peu de google home uniquement pour la musique (Spotify) et le Cast car de ce côté Alexa n’est vraiment pas à la hauteur pour un usage familial.

Mes raisons d’abandon de google pour la domotique sont :

  • Je ne supporte vraiment plus de dire « OK Google … », j’espère depuis des années que google ouvre la porte à une commande différente mais à mon avis c’est illusoire.

  • Le pilotage vocal depuis les Google Home/Nest/hub est devenu lent avec le temps, j’ai une latence de 3 ou 4 secondes sur toute commande faite vocalement vers une google home/nest/hub, depuis l’assistant sur mon smartphone ou l’app mobile c’est par contre toujours quasi instantané, ce qui met hors de cause mon infra réseau, mon Jeedom et les services du côté du cloud Jeedom.

  • Plus le temps passe plus j’ai l’impression que l’ensembles de mes périphériques google auraient besoin d’aller faire un tour chez Audi Caps, il comprennent de moins en moins bien et de plus semblent devenir chaque jour un peu plus idiot que la veille.

J’ai donc testé Alexa avec des échos dot 5e gen et j’ai été très surpris, les commandes sont instantanées, à peine on a terminé de prononcer la commande qu’elle est exécutée, il n’y a pas 500ms de latence.
Tout n’est pas rose non plus et il faut ruser sur certaines choses mais globalement c’est beaucoup mieux en commandes vocales pour la domotique.
De plus j’adore le prénom « Alexa » donc demander des choses à Alexa m’est beaucoup plus plaisant qu’à « Mr. OkGoogle ».

Donc ce passage à Alexa m’a forcément fait découvrir l’excellent plugin de @Sigalou sous jeedom qui est évidement un « must have » sui on s’équipe en Alexa, surtout pour le TTS et pour récupérer les réponses ASK dans mon cas car connaitre la dernière commande vocale prononcée et quelle echo l’a reçue est juste magnifique !

Donc en m’intéressent à @sigalou j’ai découvert qu’il avait plus ou moins un pied des deux côtés, Jeedom et HA, et qu’il risquait un jour de tomber avec les deux pieds du côté HA à la lecture de son blog, enfin c’est mon ressenti personnel.

Cela a fait renaitre mes craintes au sujet du support à « long terme » des plugins externes sous jeedom, car ça serait pas le premier à changer complètement de « moteur » domotique et du coup à délaisser ses développements sous jeedom, aussi bon et indispensables soient-ils !

C’est comme le dev Guirem qui a développé le plugin « Google Cast » tout aussi excellent et complet et qui a semble-t-il également abandonné Jeedom au point qu’il n’est plus en mesure de faire évoluer ou même de maintenir son plugin.

Donc voilà, tout ça c’est en partie sa faute :joy:

1 « J'aime »

:blush: :blush: :blush: :blush: :blush: :blush: :blush: :blush:
:blush: :blush: :blush: :blush: :blush: :blush: :blush: :blush:

1 « J'aime »

Il existe emulated_hue sur HA. Peut être que ça pourrait aider ?

Bon a savoir, je vais jeter un œil.

Mais malgré tout avoir deconz en stand alone et donc un pont hue émulé totalement indépendant de la solution domotique est un plus même si je dois m’assurer qu’un périphérique zigbee est supporté par deconz avant de le choisir.

Édit : ce n’est pas vraiment un pont hue donc ça ne peut remplacer l’émulation de Deconz

A physical Hue Bridge is required for Philips Hue lights to function - this virtual bridge will not replace a physical bridge. Instead, it allows Home Assistant to represent non-Philips Hue devices to Amazon Echo as Philips Hue devices, which Amazon Echo can control with built-in support.

Pfff … ça sent pas bon, je suis occupé de prendre gout :face_with_open_eyes_and_hand_over_mouth:

Je vais encore être amputé de nombreuses heures de sommeil …

2 « J'aime »

Hello,

C’est moche, mais le sommeil c’est très surfait :wink:

Le reste va venir :wink:

cdt