Migration Jeedom → Home Assistant : intégrations OK, mais grosse friction UX/maintenabilité (UI vs YAML)

[Dreaky]

Bonjour à tous,

Je viens de Jeedom et j’ai entrepris une migration progressive vers Home Assistant
Mon install jeedom tourne depuis plusieurs années et donc est assez imposante. J’y ai accumulé beaucoup de choses toutes ces années, du coup la migration vers Home Assistant va forcément être longue, et je la fais de manière progressive en laissant Jeedom tourner en parallèle pour l’instant.

Je précise aussi que je travaille dans l’informatique (dev senior / tech lead) : ce n’est pas la technicité qui me fait peur. Ce que je cherche surtout, c’est à bien comprendre la philosophie Home Assistant et les bonnes pratiques, afin de construire quelque chose de propre dès le début — plutôt que de devoir refaire la moitié quand je réalise plus tard que j’ai mal structuré ou qu’il existait une approche plus simple/maintenable.

Côté “socle”, ça avance bien : j’ai réussi à intégrer l’ensemble de mes devices / intégrations (Zigbee, MQTT, Tado, Nuki, Google Cast, Google Cloud TTS, caméras, etc.). J’ai aussi appliqué une convention de nommage cohérente sur mes devices/entités (pièce/zone + device + fonction), ce qui aide déjà beaucoup à y voir clair.

Là où j’ai commencé à vraiment buter, c’est sur la partie historiques / maintenance de la configuration :

• J’ai fini par configurer le recorder avec des include/exclude (et une DB MariaDB dédiée). Ça fonctionne, mais honnêtement l’expérience utilisateur m’a paru assez pénible / contre-intuitive comparée à Jeedom (où c’est très “pilotable” en UI, avec des notions de fréquence / durée de rétention / activation par commande).
• Et surtout : malgré l’interface très léchée de Home Assistant, dès qu’on veut faire des choses propres/complexes (robuste, factorisé, réutilisable), j’ai l’impression que le YAML devient vite incontournable (mais bon ça, je l’avais lu avant de démarrer).

Mon principal problème aujourd’hui, c’est la philosophie globale qui sépare strictement ce qui est créé/modifié via l’UI et ce qui est créé/modifié via YAML, sans passerelle claire entre les deux (non interchangeables). Résultat : niveau maintenabilité, je trouve ça compliqué à vivre.
Au bout d’un moment, on ne sait plus où tel objet a été créé : template UI vs template YAML, automation UI vs YAML, helpers, scripts, etc. Et quand on veut débugger/modifier “un template lambda”, on passe du temps à chercher “où est la source de vérité”.

J’ai du coup l’impression que l’intérêt de l’UI passe vite en second plan dès qu’on sort des cas simples : on finit par vivre dans l’éditeur YAML, et l’UI sert surtout pour les dashboards (ce qui est top), mais toute “l’intelligence” derrière redevient essentiellement textuelle si on veut faire ça proprement.

Du coup, je me demande si j’ai raté quelque chose dans la philosophie HA, ou si c’est un constat partagé.

Questions pour ceux qui ont déjà une install “gros volume”/long terme :

• Comment vous vous organisez pour ne pas vous perdre dans les objets (templates, automations, scripts, helpers, etc.) ?
• Vous avez des conventions/patterns (naming, préfixes, dossiers, blueprint, packages…) qui rendent la maintenance plus agréable ?
• Est-ce que vous essayez de rester 100% UI ou 100% YAML par “famille” (ex : énergie), ou vous mixez quand même, et comment vous gardez la cohérence ?

Pour donner un exemple concret : j’ai notamment buté sur la configuration du dashboard Énergie. Beaucoup de mes entités puissance/énergie ont des signes +/- à corriger (import/export, etc.), ce qui oblige à créer des template sensors “propres”. Et là, j’ai vite vu que si je voulais faire ça correctement (plusieurs capteurs normalisés, cohérents, regroupés, etc.), je partais sur du full YAML (ou alors je n’ai pas compris comment faire proprement via l’UI). À ce moment-là, je me suis fait la réflexion : “OK, j’ai déjà des helpers créés via l’UI… mais si je commence à en créer d’autres dans configuration.yaml, comment je m’y retrouve après coup ?”. J’ai un peu stoppé là, parce que j’ai l’impression de passer à côté de quelque chose dans l’organisation globale.

Je suis pourtant convaincu par Home Assistant : j’ai lu pas mal de retours d’anciens Jeedomiens qui disent ne jamais vouloir, pour rien au monde, revenir sur Jeedom. J’aimerais juste réussir à passer ce “gap” sur la maintenabilité et la séparation UI vs YAML.
Je suis donc preneur de bonnes pratiques, car pour l’instant du mal avec l’expérience “maintenabilité” dès qu’on veut construire quelque chose de sérieux et durable.

Merci d’avance pour vos retours !

[Pulpy-Luke]

Salut et bienvenu !

@Dreaky

J’ai fini par configurer le recorder avec des include/exclude (et une DB MariaDB dédiée).

De ce côté je pense que tu as raté un truc. De base mariadb n’a aucun intérêt et le fonctionnement de ha est plus simple à appréhender que jeedom : besoin d’historique = création d’un include.
Tout le reste sera exclu par défaut.
Il est possible qu’au début, on y mette un peu plus que le nécessaire (debug et observations du comportement) mais c’est tout.
La partie Mariadb ça me rends toujours plus circonspect. Une base sqlite contenue n’a pas de problématique de performances, bien au contraire.

@Dreaky

c’est la philosophie globale qui sépare strictement ce qui est créé/modifié via l’UI et ce qui est créé/modifié via YAML, sans passerelle claire entre les deux (non interchangeables). Résultat : niveau

Oui c’est parfaitement résumé. Et en tant qu’ancien utilisateur jeedom aussi, je comprends le souci. Il y a 5 ans la partie ui n’était pas aussi omniprésente.
Désormais ça apporte un peu de facilité pour les nouveaux.
De mon côté, je traite(rai) le souci de la sorte : en dehors des automatisations/scripts, rien dans l’ui.
Les automatisations, une fois classées dans les groupes et taggées avec les labels c’est très propre. On profite des filtres, de l’aide à l’édition et des outils de debug dans les traces et d’une vue yaml.
Pour le reste puisque sans pont, tout en yaml. C’est plus rustique mais c’est très lisible une fois pris en main et surtout ça s’exporte / importe et que ça permet les commentaires ! Ici sur le forum, partager un sensor fait via un helper ça me fait mal aux fondamentaux (pour ne pas dire autrement).
Reste que ça oblige à apprendre le yaml (et le jinja2), au même titre que le php est un peu indispensable à comprendre et manipuler au sein de jeedom.

Côtes organisation du yaml il y a deux pratiques :

• mettre tout en package, un package se basant sur une fonctionnalité globale (alarme, piscine etc)
• mettre tout en fichier, le fichier sensor, template, binary_input etc.

Les deux techniques se valent et j’ai plutôt une préférence pour la 2ème option. Je trouve plus ‹ logique › de charcher un template sensor dans le fichier sensor (pas le fichier template !) plutôt que de me poser la question : sensor.piscine c’est dans le fichier piscine, température ou jardin ?
J’ajoute à ça une règle de nommange simple des entités que j’applique partout (y compris côté ui) . Plus je rajoute un élément, plus je précise l’objet : sensor.sonde_jardin_temperature_moyenne_5min côtoie sensor.sonde_salon_luminosite dans mon fichier sensor.
A partir de la, c’est facile de retrouver et de factoriser le code des automatisations, des templates, ou des filtres par exemple : sensor.sonde_*_temperature me donne toutes les températures peu importe l’emplacement.

Avec tout ça j’ai l’impression que c’est assez efficace et je ne passe pas mon temps à chercher. Après j’ai bien conscience que nous avons tous une façon de penser et s’organiser qui différe, il faut aussi tenir compte de ça.

@Dreaky

Je suis pourtant convaincu par Home Assistant : j’ai lu pas mal de retours d’anciens Jeedomiens qui disent ne jamais vouloir, pour rien au monde, revenir sur Jeedom.

Je ne peux pas m’empêcher de sourire à la lecture de ça, Évidemment si la communauté jeedom ne faisait pas un peu de censure/bashing sur les transfuges, l’apriori vis à vis de ha ne perdurerai pas autant. Ici, comme tu le dit, tous les ex jeedomiens sont convaincus d’avoir fait la bonne bascule et regrettent de ne pas avoir entamé la démarche bien plus tôt.
Et de façon très honnête de vrais utilisateurs ha qui basculent chez jeedom ça n’existe pas. Il y a bien quelques utilisateurs ‹ de quelques jours › qui sont revenus à jeedom après avoir tenté de partir mais ça se compte sur les doigts de deux mains max. À l’inverse des jeedomiens qui basculent définitivement sur ha ça se compte en plusieurs centaines (voir milliers) sans aucun doute. Et quand je te te lis, j’ai le sentiment que toi aussi tu as déjà basculé.

Bref tout ça pour dire que finalement le yaml c’est comme le vélo, ça s’apprend et qu’avec le temps c’est pas si terrible, mais que de toutes façons la domotique (jeedom ou ha) c’est chronophage en plus d’être addictif. Donc une bonne démarche unique pour s’en sortir vainqueur ça n’existe pas vraiment et qu’il y a autant d’avis et de pratiques que d’individus.

[Dreaky]

Merci beaucoup pour avoir pris le temps de répondre de manière approfondie.

J’ai néanmoins toujours quelques interrogations.

@Pulpy-Luke

La partie Mariadb ça me rends toujours plus circonspect. Une base sqlite contenue n’a pas de problématique de performances, bien au contraire.

Alors là je suis étonné, car j’ai lu ici et là qu’une base mariadb (en lieu et place d’une sqlite) était plus efficace sur de grosses installation, plus scalable, plus robuste, meilleure gestion de la concurrence (IO et CPU moindre sur grosse base en comparaison). Et chez moi, j’ai quand beaucoup (beaucoup ?) de trucs, notamment certaines devices qui bombardent allègrement (tout ce qui touche à l’énergie, les puissances et conso, ça peut refresh plusieurs fois par seconde sur des dizaines et dizaines d’entités, donc ça m’a fait un peu peur…)

@Pulpy-Luke

le fonctionnement de ha est plus simple à appréhender que jeedom : besoin d’historique = création d’un include.
Tout le reste sera exclu par défaut.

Sur ce point, c’est un peu ce que j’avais compris.
Mais du coup, c’est quoi la bonne pratique ?
Sur mon installation, j’ai splitté les includes et les exludes sur leur propres fichiers yaml.
Ca ressemble à ça :

#INCLUDE
domains:
  - climate

entity_globs:
  #JK BMS
  - sensor.*jk_bms*total_voltage*
  - sensor.*jk_bms*current*
  - sensor.*jk_bms*power*
  - sensor.*jk_bms*soc*
  - sensor.*jk_bms*average_cell_voltage*
  - sensor.*jk_bms*diff_cell_voltage*
  - sensor.*jk_bms*max_cell_voltage*
  - sensor.*jk_bms*min_cell_voltage*
  - sensor.*jk_bms*temperature*
  - sensor.*jk_bms*cell_voltage_min
  - sensor.*jk_bms*cell_voltage_max
  - sensor.*jk_bms*cell_delta_voltage
  - sensor.*jk_bms*cell_average_voltage
  - sensor.*jk_bms*battery_voltage
  - sensor.*jk_bms*battery_capacity_remaining

  #HMS-2000
  - sensor.hms_2000_voltage
  - sensor.hms_2000_current
  - sensor.hms_2000_power
  - sensor.hms_2000_powerfactor
...

#Exlude
domains:
  - media_player
  - light

entity_globs:
  # MISC
  - sensor.*uptime*
  - sensor.*signal*
  - sensor.*wifi*
  - sensor.*status*

  #Camera
  - sensor.*camera*
  - binary_sensor.*camera*

  # Shelly volets
  - sensor.*_volet*_power
  - sensor.*_volet*_energy

  #Zigbee noise
  - sensor.*_battery*
  - sensor.*_linkquality
  - sensor.*_rssi
  - sensor.*_lqi
  - sensor.*_device_temperature
  - sensor.*_power_outage*

(j’ai pas mis les tous includes, c’est juste pour donner une idée de ce que j’ai fait)
Est-ce que j’ai bon, c’est overkill ? à côté de la plaque ? Exlude inutile ?

@Pulpy-Luke

Pour le reste puisque sans pont, tout en yaml

Ok, de toute façon, c’est ce que je m’étais imaginé. Et ton message dans sa globalité me « rassure » sur la compréhension que j’en avais, même si ma frustration (liée à la quasi-inutilité de l’UI) laisse quand même un goût assez prononcé d’amertume.

@Pulpy-Luke

J’ajoute à ça une règle de nommange simple des entités que j’applique partout (y compris côté ui) . Plus je rajoute un élément, plus je précise l’objet : sensor.sonde_jardin_temperature_moyenne_5min côtoie sensor.sonde_salon_luminosite dans mon fichier sensor.

Là j’avais clairement cerné l’importance capitale d’une convention de nommage sous HA. Du coup je vais quand même refaire une passe sur ce que j’ai déjà fait, car je suis encore pas certain que ce soit la meilleure façon.
Car pour ma part, j’ai procédé de la sorte pour le nommage :
<sensor_type>.<zone/piece>_<objet>_<fonction/unit>
Ce qui donne ça (quelques exemples dans mon HA pour le moment) :

sensor.bureau_sonde_humidity
binary_sensor.chambre_d_amis_fenetre_contact
sensor.exterieur_sonde_arriere_humidity
sensor.garage_onduleur_sofar_battery_soc
binary_sensor.salon_presence_occupancy
sensor.garage_batterie_jk_bms_cell_voltage_min
cover.bureau_volet
sensor.garage_shelly_em_pv_puissance

Ca vous parait cohérent ?
Du coup je me rend compte que je mélange anglais/français (j’ai laissé l’interface HA en anglais, plus facile de s’y retrouver sur la doc sur le net ou dans les forums), mais certains devices/entités remontent en anglais (genre « humidity ») et d’autre en FR (comme « puissance »). Me reste à faire une passe sur ce problème…

Pour l’instant je n’ai créé que quelques helpers via l’UI de type « Change device type of switch » pour passer des switch en type « light ». Du coup je fais quoi ? Je les vires et les « transforme » en full YAML ?
Et j’ai créé deux helpeurs (toujours via l’UI) de type « Groupe », pour regrouper mes volets pour le RDC et l’étage. Là encore, je vire et je passe en YAML ?

Merci d’avance pour vos retours

[Tochy]

Salut

Concernant les helpers, tu peux savoir facilement depuis l’interface si ils sont créés en yaml ou depuis l’ui

Le stylo barré sur la droite indique une entrée yaml.

De plus tu peux ajouter un/des label et une catégorie à chacun. Il est ainsi facile de retrouver les sensors pour un équipement/pièce/thème/… (selon les labels et catégorie définis)

Je pense (mais ce n’est que mon avis) qu’aujourd’hui il est plus simple, plus rapide et plus facile à maintenir pour les entrées de passer par l’ui, même si tout n’est pas encore réalisable depuis l’ui.

Il n’y a qu’a voir le changement récent sur les templates avec des personnes qui doivent revoir tous leurs sensors ecrit en yaml avec le prochain abandon de l’ancienne syntaxe.

[Pulpy-Luke]

@Dreaky

Alors là je suis étonné, car j’ai lu ici et là qu’une base mariadb (en lieu et place d’une sqlite) était plus efficace sur de grosses installation, plus scalable, plus robuste, meilleure gestion de la concurrence (IO et CPU moindre sur grosse base en comparaison). Et chez moi, j’ai quand beaucoup (beaucoup ?) de trucs, notamment certaines devices qui bombardent allègrement (tout ce qui touche à l’énergie, les puissances et conso, ça peut refresh plusieurs fois par seconde sur des dizaines et dizaines d’entités, donc ça m’a fait un peu peur…)

Dans l’absolu c’est vrai MAIS :

• depuis maintenant 2 ans la base de données SQLlite a été largement optimisée.
• mettre tout dans la base de données sans se poser de question est une mauvaise pratique, tu le vois sans doute au boulot aussi. Par exemple quel est l’intérêt de mettre le voltage et toutes ces déclinaisons ? Même si c’est un véritable besoin, le min/max/moy ça se calcule …
• Pour le climate, tout ne sert pas non plus…

Bref, sauf cas exceptionnel, la base HA est capable de rendre le même service avec peu de données, donc pas besoin d’un truc scalable etc … C’est largement overkill et ça participe à surdimensionner son infra à tous les niveaux. Il vaut mieux passer un peu de temps à regarder ce qui sert et comment ça marche, on est largement gagnant sur le long terme.
D’autant plus que plus la taille des backup augmente, plus c’est pénible à gérer en plus

@Dreaky

même si ma frustration (liée à la quasi-inutilité de l’UI) laisse quand même un goût assez prononcé d’amertume.

ça passe à l’usage, c’est la phase de transition

@Dreaky

<sensor_type>.<zone/piece><fonction/unit>

Zone/piece puis objet c’est pas forcement déconnant, question de point de vue. J’aime bien séparé les blocs également pour les retrouver dans les expressions régulières

@Dreaky

Du coup je me rend compte que je mélange anglais/français

Oui il faut fixer une norme. J’ai bien les termes en anglais aussi, pour les même raisons liées à la doc

En fait ce qu’il manque c’est de pouvoir importer un yaml dans l’UI (pour tout basculer) et de pouvoir l’exporter (pour le partage ou la relecture)… Un peu comme les automatisations

@Tochy

Il n’y a qu’a voir le changement récent sur les templates avec des personnes qui doivent revoir tous leurs sensors écrit en yaml avec le prochain abandon de l’ancienne syntaxe.

C’est pas faux, si la conversion est automatique, c’est un point intéressant. Mais d’un autre coté, lire le changelog ça laisse le temps de préparer le terrain, d’anticiper le changement et de ne pas être contraint de le faire dans la précipitation

[Patrick44fr]

Bonjour,
merci pour cet échange, très fructueux et clair. Je l’ai lu avec attention, et c’est abordable pour un grand nombre d’entre nous.
Merci à @Pulpy-Luke de ses réponses étoffées et toujours non polémique. Cela aidera sans doute les Ex jeedomiens et les autres a partir du bon pied.

En résumé, Merci Merci

[Dreaky]

Oyez oyez,

Je repasse faire un petit point “news” sur ma transition Jeedom → Home Assistant (parce que oui : je suis toujours dedans, et non : je n’ai pas lâché l’affaire, loin de là).

Où j’en suis à l’heure actuelle

• Infra système & réseau : 100% fonctionnel
  Mon HA est tunnelisé via Cloudflare et donc accessible depuis l’extérieur. Et pour les connaisseurs : c’est protégé à la fois par un WAF (filtré en géoloc, France only) et par Cloudflare Zero Trust / Cloudflare One.
  Résultat : c’est accessible depuis l’extérieur, y compris via l’app mobile, malgré la couche Cloudflare.
• Intégrations & données en entrée : je pense être à 100%
  En clair : j’ai récupéré toutes les données brutes dont j’ai besoin pour faire “tout ce que je veux” dans HA… et surtout pour retrouver l’équivalent de mon Jeedom.
• Automatisations : ~90/95%
  J’ai encore quelques scénarios actifs côté Jeedom, mais honnêtement, j’ai quasiment tout migré.
  Il me reste surtout à tester / éprouver certaines automations “qui servent pas souvent” (et donc qui adorent tomber en panne pile le jour où elles servent, évidemment).
• Dashboards : ~90/95% aussi
  Fonctionnellement, j’ai tout ce qu’il faut pour lire l’info et piloter mes devices (et avoir l’équivalent de ce que j’avais sur Jeedom).
  Il reste des petits détails, quelques évols esthétiques, des bidouilles… mais bon, les dashboards c’est comme une maison : c’est jamais fini. On veut toujours “juste améliorer deux trucs”… et 3 heures plus tard, on est en train de réaligner des pixels à 1px près.
  Gros sujet restant : me configurer un joli graph/histo de conso elec avec les différents tarifs Tempo, et me rapprocher de ce que fait Suivi Conso sur Jeedom (ceux qui connaissent savent que c’est un “petit morceau”).
• Google Home : ~60%
  J’ai réussi à connecter moi-même mon HA à un projet dev Google Home (donc sans abonnement Nabu Casa). Testé avec deux entités : ça fonctionne, je pilote depuis les Google Home sans souci. C’était quand même un gros morceau. Je tenais à le faire moi même, et je voulais pas dépendre d’un truc tier (comme j’avais l’habitude sur jeedom…) pour ça. Y’a pas mal de conf à se farcir, mais ça marche, je suis content.
  Il me reste “juste” à déclarer tous les devices/entités à exposer… mais j’attends de couper Jeedom définitivement, sinon je vais me retrouver avec tout en doublon (et mon Google Home va finir schizophrène).
• Historisation / recorder : là… c’est pas encore ça
  J’approche du bout, mais je ne suis pas encore serein. J’ai une BDD encore trop grosse à mon goût (genre 5M de lignes dans states, environ 1,5 Go avec une purge réglée à 10 jours).
  Je me suis rendu compte que j’historisais des trucs en double : l’entité brute + un template basé dessus, etc. Donc je suis en mode “nettoyage / fignolage / diète du recorder”.
• Et il reste plein de choses que je n’ai pas encore touchées
  Les blueprints, probablement des intégrations HACS must-have que j’ai loupées, des optimisations que je découvrirai “après coup”, bref : le rabbit hole habituel.

Donc globalement, je dirais que je suis à 80/90% sur l’avancement, en un peu plus d’un mois.
Par contre : c’est clairement du boulot. J’y passe facile 2 à 3h quasiment tous les soirs (sauf pendant les fêtes, où j’ai eu la décence morale de privilégier les cadeaux et le champagne plutôt que le YAML… même si le YAML revient toujours, tôt ou tard).

---

Vient la partie croustillante : mon ressenti sur HA (vs Jeedom)

Maintenant que j’ai vu une grosse partie de la bête, voilà ce que j’en retiens.

Ce que j’ai apprécié

• Les dashboards : franchement très puissants
  On peut faire un truc fonctionnel, propre et relativement joli vite. Et si on veut monter d’un cran : HACS propose plein de cards “prêtes à l’emploi”.
  Après, dès qu’on veut un truc très spécifique, il faut mettre les mains dans le cambouis… mais bon, sur Jeedom aussi, on finit souvent les mains noires.
• L’app mobile : vraiment bien fichue
  Ça marche vite, ça marche bien. On peut faire un dashboard commun desktop+mobile ou séparer les deux.
  Et mention spéciale au tracking intégré dans l’app : sur Jeedom, il faut passer par du plugin tier parce que ce n’est pas dans le core. Là, c’est natif et c’est cool.
• Les automatisations : grosse appréhension… et bonne surprise
  J’avais vraiment peur de quitter les scénarios Jeedom (mes petits chouchous). Au final, j’ai été surpris de la vitesse à laquelle j’ai pris le pli.
  Il y a deux-trois concepts à capter tôt qui débloquent beaucoup de choses (typiquement les trigger id). Et il y a des mécanismes à “désapprendre” (par ex. l’impossibilité de lancer un bloc “dans X minutes” comme dans Jeedom).
  Mais globalement, j’ai très vite réussi à refaire ce que je voulais de manière assez intuitive, sans devoir harceler ChatGPT toutes les 30 secondes (j’ai dit “sans devoir”, pas “sans jamais”, faut pas abuser).
• HACS : la complétude est impressionnante
  En gros : ce qui n’est pas dans HA Core est souvent dans HACS. Il y a forcément quelqu’un qui a eu la même idée avant toi et qui l’a codée.
  Et on trouve des intégrations vraiment haut niveau, bien suivies, bien documentées, maintenues correctement.
  Gros point positif comparé à Jeedom où, soyons honnêtes, la maintenance des plugins est un vrai point noir.

Ce que j’ai moins apprécié (voire pas du tout)

• Le YAML/Jinja quasi obligatoire
  Je le savais, mais ça reste un point pénible : dès que tu veux faire un truc un peu “hors UI”, tu replonges dans le YAML (templates, sensors, scripts, filtres, scraping API, etc.).
  Oui, on s’y fait… mais surtout parce qu’on n’a pas le choix. Le YAML, c’est un peu la coriandre : certains adorent, d’autres subissent.
• La séparation UI / YAML
  Pour moi, c’est une ineptie. Le jour où ils arrivent à vraiment unifier les deux mondes (pouvoir passer de l’un à l’autre de façon fluide partout, comme sur certaines cards), ce sera un énorme step.
• Les restart/reload trop fréquents
  Devoir restart HA (ou recharger la conf YAML) dès qu’on touche à certains trucs (nouvelle intégration, nouveau template, entrée recorder, etc.), franchement c’est lourd.
  C’est le moment où tu te dis : “ok, je vais juste changer un petit détail”… et 2 minutes plus tard tu fais un reload en soufflant comme un vieux routeur ADSL.
• Le recorder / l’historisation : l’enfer
  Là, je regrette beaucoup Jeedom. Et quitte à en froisser certains : comparé à Jeedom, j’ai l’impression qu’on est à l’âge de pierre sur la gestion d’historique.
  Je suis même étonné que ce ne soit pas déjà intégré proprement à l’UI (un include/exclude par entité, basique, avec du wildcard en YAML pour les cas avancés, ce serait déjà royal).
  Sur Jeedom, la partie historique est hautement personnalisable et full UI. En arrivant sur HA, ça fait un manque.
• Card-mod : quand tu veux juste bouger un texte de 3 pixels…
  Dès qu’on veut fine-tuner (taille d’un texte, couleur, alignement, padding, etc.), c’est “OSKOUR”.
  Même en étant dev full-stack, je m’en sors difficilement sans forums + ChatGPT. Et même ChatGPT galère, parce que les cards évoluent souvent (mushroom notamment) : il sort de l’ancienne syntax ou des classes CSS devenues obsolètes.
  Bref, on finit par y arriver… mais ça se mérite.

---

Bilan

Au final, je suis quand même satisfait de ma migration (toujours en cours). Si c’était à refaire, je le referais.
Mais je le referais surtout parce que Jeedom est en train de couler (évolutivité, maintenabilité, qualité des releases…), pas parce que j’avais un besoin spécifique que HA couvre et que Jeedom ne couvre pas.

J’étais content de mon install Jeedom, mais lassé par la lenteur des évolutions et par les bourdes récurrentes dans les mises à jour. La dernière en date : un bug qui a fait planter des installs à jour le 1er janvier 2026 à minuit… on peut difficilement faire plus symbolique.

Sur HA, il y a la force d’une communauté immense : ça n’a rien à voir. Tout va plus vite, les solutions existent souvent déjà, et ça bouge en continu.
Et puis l’ambiance sur le forum Jeedom, c’est plus possible… Des modos qui sont là que pour tacler, ça se crêpe le chignon sans arrêt, aller salut…

À noter aussi : j’ai un profil technique en informatique, donc ça m’a clairement aidé à migrer rapidement. Ce ne sera pas forcément aussi fluide pour tout le monde.

Je suis encore au tout début de ma vie “HA”, donc mon point de vue évoluera sûrement avec le temps. Je repasserai mettre à jour ma pérégrination, surtout dans l’idée d’informer ceux qui hésitent à migrer.

Merci de m’avoir lu.

[Dreaky]

Quelques screen de mes dashboards (c’est du basique, ne vous moquez pas trop )

[chrisdelt]

Bonjour,

Franchement, c’est un très bopnne synthèse dans laquelle je me retrouve beaucoup. J’ai mis plus d’un an à migrer (sans aucun regret au final) et c’est le thermostat qui m’a demandé le plus d’efforts.
Sinon totalement d’accord sur l’ensemble des points négatifs que tu soulèves dans le bilan. Espérons que ça vienne un jour sur HA, tes suggestions sont excellentes de mon point de vue.

[Dreaky]

@chrisdelt

et c’est le thermostat qui m’a demandé le plus d’efforts.

Alors c’est vrai que pour ma part, ça été rapide car je dispose de thermostats Tado, sur lequel je configure les températures/heures de chauffe directement sur l’appli. Sur ma domotique, je n’ai rien à gérer à part ajouter les « commandes » (dashboard pour afficher les températures et les commandes de chauffe).

Mais pour ceux qui utilisent le fameux plugin « Thermostat » sur Jeedom (qui permet de gérer de zéro toute la partie chauffage/clim de la maison, avec des algos assez chiadés), clairement oui là y’a du boulot pour migrer ça sur home assistant. Surtout que le chauffage, c’est assez critique. Il s’agit pas juste d’afficher une info « bateau » sur un dashboard. Quand ça plante, tout le monde se caille et madame est clairement pas contente (à juste titre).

[Dreaky]

Un petit (et dernier ?) état des lieux de ma migration Jeedom → Home Assistant.

Ça y est : ma VM Jeedom est coupée depuis 3 semaines. Je suis donc officiellement plus Jeedomien ! (et un peu content quand même )

Depuis mon dernier post, voilà ce qui a bougé

Automatisations : terminé et validé “en condition réelle”

J’ai fini de migrer / recréer toutes mes automatisations. Et surtout, j’ai pu les tester en vrai (pas juste “ça a l’air bon sur le papier”). Notamment la (grosse) partie gestion automatique de la charge batterie en fonction des jours rouges tempo. Non seulement ça a marché direct, mais je me suis même permis d’améliorer l’algo.
Bref : sur ce point, c’est carré.

Dashboards : fonctionnels, efficaces… et pas (encore) très jolis

J’ai terminé ce dont j’avais besoin côté dashboard. C’est clairement plus orienté fonctionnel qu’esthétique, mais ça me convient très bien pour le moment.

Quand je serai motivé, je passerai peut-être du temps à améliorer l’aspect visuel en m’inspirant de ce qu’on voit chez certains (y’en a qui font des trucs magnifiques).
Mais comme je le disais déjà : un dashboard, c’est comme une maison… c’est jamais vraiment fini. Ça évolue au fil des envies, des besoins, et des “tiens, et si je refaisais tout ce week-end ?”

Gros morceau : Google Home, 100% migré

C’était un gros besoin (et un passage obligé pour que la migration soit “vraie”). Et bonne nouvelle : j’ai tout migré sans souci.

Le plus dur a été la configuration initiale de mon projet Google Console pour faire ça moi-même (et ne pas dépendre de l’abonnement Nabu Casa).
Mais une fois cette étape passée, l’intégration des entités a été rapide, propre, sans bavure.

Je reste sur du basique (ce que je veux piloter à la voix) :

• thermostats
• capteurs température / humidité
• lumières
• volets
• porte de garage

Donc sur ce point : très content.

Historisation / Recorder : toujours le boss final (mais j’en suis venu à bout)

Sans surprise… c’est encore la partie qui m’a pris le plus de temps.

Après pas mal de conf et de tâtonnements, j’ai enfin une situation stable : ma BDD (MariaDB) se stabilise autour de 900 Mo (contre 2,5 Go au début). Donc ça, c’est une vraie victoire.

Les entités les plus “consommatrices” chez moi restent celles liées au monitoring énergie/électrique : les Shelly qui suivent puissance / conso (maison + solaire) envoient du lourd, donc forcément ça remplit vite.

Il reste encore 2–3 trucs “bonus”

Il me manque encore quelques dashboards “confort”, comme le coût et la répartition de ma conso (Tempo) dans de jolis graphs.

Mais ce n’est pas primordial : j’ai déjà l’info via HelloWatt / Enedis, et surtout ce n’est pas nécessaire pour « piloter » la maison. Donc c’est dans la pile “quand j’aurai envie”.

---

Mon ressenti (par rapport au post précédent)

Pas vraiment d’évolution : je suis toujours d’accord avec… moi-même

• Gros + : dashboards, appli mobile, automations
• (Très) gros - : historisation / recorder

Et deux points que je n’avais pas mentionné :

Avec Home Assistant — en tout cas avec HAOS — je me rends compte d’un énorme avantage : je n’ai plus à faire la maintenance de l’OS comme c’était le cas avec Jeedom.
Les upgrades système sont gérés par les équipes Home Assistant, et ça, franchement, c’est un énorme plus. Il suffit de voir le nombre de posts sur le forum Jeedom à propos des migrations Debian (le classique Debian 10 → 11, notamment) : c’est souvent un enfer, entre les galères de montée de version, les dépendances, etc.
Sans compter les incompatibilités côté plugins Jeedom liées à la version de l’OS… bref : un gros morceau en moins à gérer, et ça fait vraiment du bien.

Autre point non pas des moindre : « validation côté madame ».
La transition vers HA s’est très bien passée avec ma femme : elle a bien pris en main la nouvelle appli, et comme je n’ai pas eu de gros soucis pendant la migration, en dehors du changement d’app… ça a été quasi transparent pour elle.

Donc si ça peut rassurer ceux qui hésitent : c’est possible de migrer sans déclencher une révolution à la maison

Merci à ceux qui ont aidé (ici ou ailleurs) un ex-Jeedomien à faire la transition.
Je suis fier et très content d’avoir fait le pas.