Blog

Transparence : Cet article raconte une migration réelle de mon installation Jeedom vers Home Assistant avec Claude Code. Les outils utilisés ont été financés intégralement par mes soins, pour un coût total d’environ 40 €. Aucun éditeur, fabricant ou plateforme n’a participé à cet article. Les réussites comme les erreurs décrites viennent de mon installation, avec des causes souvent humaines et parfois liées à de mauvaises interprétations de l’intelligence artificielle.

Tags : Jeedom Home Assistant Claude migration domotique intelligence artificielle

0. Contexte

0.1 Début dans la domotique

Mon histoire avec Jeedom a commencé il y a environ six ans, avec un Raspberry Pi et une passerelle Xiaomi.

Comme beaucoup d’installations domotiques, la mienne a ensuite grandi progressivement. Quelques capteurs sont devenus des dizaines d’équipements, les premiers scénarios se sont multipliés et le Raspberry Pi a finalement laissé sa place à un NUC équipé d’un processeur Intel Core i7.

Jeedom m’a beaucoup apporté. Sa manière de construire les scénarios et son plugin Thermostat font d’ailleurs partie des raisons pour lesquelles je suis resté aussi longtemps sur cette solution.

Je n’ai donc pas décidé de migrer parce que mon installation ne fonctionnait plus.

Depuis plusieurs années, je testais déjà Home Assistant en parallèle, principalement pour découvrir ses intégrations et réaliser quelques essais. Je constatais également une évolution rapide de son écosystème, tandis que j’avais personnellement le sentiment que Jeedom évoluait moins vite, avec moins de développeurs visibles et une orientation davantage tournée vers les usages professionnels.

C’est mon ressenti d’utilisateur, pas une vérité universelle.

0.2 Besoin de migration

Je pensais toutefois qu’une migration complète était pratiquement impossible.

Une installation plus locale, plus réactive et plus simple à maintenir. Je voulais également réduire ma dépendance aux plugins, aux API distantes et aux services cloud.

Il ne s’agissait pas de déplacer quelques ampoules et trois capteurs. Il fallait reconstruire six années d’habitudes, de scénarios, de virtuels, de contournements et parfois d’erreurs que j’avais moi-même oubliées.

C’est dans ce contexte que j’ai décidé d’essayer Claude Code.

Non pas en lui demandant immédiatement de migrer toute la maison, mais en lui confiant d’abord quelques fonctions peu sensibles pour voir s’il était capable de comprendre ma manière de construire une installation domotique.

Quatorze jours plus tard, Jeedom était éteint et Home Assistant pilotait la maison.

Ce n’est pourtant pas l’histoire d’une intelligence artificielle qui aurait travaillé seule pendant que je la regardais faire. C’est le récit de sept journées de travail humain effectif, réparties sur quatorze jours calendaires, avec des validations, des erreurs, des corrections et une famille de quatre personnes vivant dans la maison pendant toute la migration.

J’ai essayé de tout détailler pour vous aider a y voir plus clair

1. Une installation Jeedom devenue difficile à lire

1.1 Les chiffres avant la migration

Avant de commencer, Claude a réalisé un état des lieux directement depuis la base de données de Jeedom.

Les chiffres n’étaient pas estimés :

Élément	Nombre
Scénarios	158, dont 24 actifs
Équipements Jeedom	1 222, dont 802 actifs
Commandes	12 627
Objets et pièces	76

L’installation mélangeait de nombreux écosystèmes : Zigbee, Z-Wave, Wi-Fi, Bluetooth Low Energy, MQTT, EnOcean, RF 433 MHz, Somfy RTS, io-homecontrol, Matter, Thread, HomeKit et plusieurs services cloud.

On retrouvait notamment Zigbee2MQTT, Somfy, Shelly, Xiaomi, Frigate, Tuya, SwitchBot, Alexa et différentes intégrations MQTT.

(Capture de l’ancien tableau de bord Jeedom.)

Ces chiffres peuvent donner l’impression d’une installation démesurée. Il faut néanmoins préciser que tout n’était pas réellement utilisé en permanence. Six années de tests laissent des équipements désactivés, des anciennes commandes, des scénarios abandonnés et des intégrations qui ne servent plus.

C’est justement là que se trouvait le premier problème : il ne suffisait pas de copier ce qui existait. Il fallait comprendre ce qui était encore utile.

1.2 Le véritable travail était un travail d’archéologie

Avant cette migration, je pensais que la difficulté principale serait d’écrire les automatisations de Home Assistant.

Ce n’était pas le cas.

Écrire une automatisation en YAML peut prendre quelques minutes. Comprendre ce que faisait réellement un scénario Jeedom construit plusieurs années auparavant peut demander beaucoup plus de temps.

Dans la base Jeedom, la logique d’un scénario est répartie entre plusieurs tables. Il faut parcourir les scénarios, leurs éléments, leurs sous-éléments et leurs expressions, puis résoudre les références telles que #12345# dans la table des commandes.

Il n’existe pas un fichier simple contenant l’ensemble de la logique.

Claude devait donc effectuer des requêtes successives, retrouver les commandes correspondantes et reconstruire le raisonnement de chaque scénario avant de pouvoir le traduire.

Le vrai coût de cette migration n’a pas été l’écriture. Il a été l’archéologie nécessaire pour comprendre ce que j’avais réellement construit.

1.3 Une occasion de revoir mes propres erreurs

Cette analyse m’a aussi obligé à regarder mon installation avec davantage de recul.

Au fil des années, j’avais créé beaucoup d’erreurs classiques de débutant :

• des virtuels qui dépendaient d’autres virtuels, eux-mêmes liés à d’autres virtuels ;
• des scénarios pour presque tout et n’importe quoi ;
• des fonctions domotisées simplement parce que je pouvais le faire ;
• des logiques devenues inutilement compliquées ;
• des noms qui ne correspondaient plus toujours à la fonction réelle de l’équipement.

Une installation peut fonctionner tout en étant devenue difficile à comprendre.

La migration vers Home Assistant n’a donc pas seulement consisté à reconstruire Jeedom ailleurs. Elle m’a donné l’occasion de supprimer certaines couches et de me demander, pour chaque automatisation :

Est-ce que cette fonction répond encore à un besoin réel ?

2. Pourquoi avoir choisi Claude Code ?

2.1 Un outil capable d’agir, mais sous surveillance

Je n’avais encore jamais utilisé Claude Code pour un projet de cette ampleur.

Mon choix venait principalement de sa capacité à interagir directement avec les serveurs sous ma supervision. Un assistant conversationnel classique aurait pu me fournir des pistes ou écrire un exemple de YAML, mais il aurait été beaucoup plus difficile de lui faire analyser l’ensemble de l’installation, suivre les relations entre les scénarios et vérifier les fichiers réellement déployés.

Claude disposait d’un accès temporaire en SSH aux environnements concernés. Il pouvait consulter la base MySQL de Jeedom, analyser les configurations et travailler sur Home Assistant, Zigbee2MQTT et Proxmox.

Ces accès ont été supprimés ou renouvelés dès la fin du travail.

Je consacrerai volontairement une partie de cet article à la sécurité : donner accès à son infrastructure à une intelligence artificielle n’est pas un geste anodin.

Il faut utiliser des accès temporaires, limiter les permissions, sauvegarder les systèmes et révoquer les identifiants une fois le travail terminé.

Surtout, l’IA ne doit pas disposer d’une liberté totale sur une maison habitée.

2.2 Je ne lui ai jamais fait pleinement confiance

Claude devait me présenter un état des lieux avant toute décision importante.

Il ne pouvait pas modifier profondément un scénario sensible sans mon accord. Lorsqu’une décision concernait la présence, l’alarme, les ouvrants ou une fonction importante de la maison, nous la validions ensemble.

Claude avait le droit de redémarrer certains services, mais pas de prendre seul toutes les décisions d’architecture.

Ce fonctionnement a limité son autonomie, notamment pendant la nuit.

Je préparais parfois une liste de tâches avant d’aller me coucher, mais les sessions nocturnes ont finalement été moins productives que je l’imaginais. Claude préférait régulièrement s’arrêter et poser une question plutôt que de prendre le risque de modifier une fonction sensible.

Avec le recul, c’était probablement préférable.

L’installation n’était pas un laboratoire. Une erreur pouvait ouvrir un Velux sous la pluie, allumer la lumière dans la chambre d’un enfant ou modifier le mode de la maison au milieu de la nuit.

2.3 Une collaboration très différente d’un travail classique

La migration représente environ 42 heures de travail humain : six heures par jour pendant sept journées effectives, réparties sur quatorze jours calendaires.

Les sessions étaient très variables.

Certains jours, nous avons travaillé pendant plusieurs heures sans interruption. À d’autres moments, je suivais l’avancement à distance et répondais rapidement à une question depuis mon téléphone, parfois pendant mes déplacements ou en allant simplement à la boulangerie.

Je devais néanmoins intervenir très régulièrement, parfois une vingtaine de fois dans la journée.

Claude pouvait analyser, écrire et vérifier beaucoup plus rapidement que moi. En revanche, il ne pouvait pas deviner pourquoi un interrupteur portait un certain nom, pourquoi un virtuel avait été placé entre deux équipements ou pourquoi une logique apparemment inutile était importante pour notre quotidien.

Je ne suis pas développeur professionnel. Je suis infirmier.

Mais je connais profondément ma maison et mon installation. C’est cette connaissance qui a rendu la collaboration possible.

3. Commencer par ce qui ne pouvait pas faire de dégâts

3.1 Le réveil de ma fille comme premier véritable test

Je n’ai pas commencé par l’alarme, le chauffage ou les ouvrants.

Le premier essai important concernait le réveil de ma fille, qui était absente pendant les vacances. En cas d’erreur, personne ne serait réveillé en pleine nuit et aucune fonction vitale de la maison ne serait affectée.

J’ai ensuite confié à Claude quelques automatismes d’arrosage et d’autres scénarios peu sensibles.

L’objectif n’était pas encore de migrer la maison. Je voulais vérifier s’il était capable de comprendre ma manière de raisonner à partir de quelques exemples Jeedom.

(Capture du scénario de réveil des filles.)

C’est pendant ces premiers essais que j’ai commencé à croire que la migration était possible.

Claude ne se contentait pas de traduire les scénarios. Il repérait aussi certaines erreurs, des éléments incomplets ou des choix que j’avais volontairement laissés de côté parce qu’ils avaient peu d’impact et que je n’avais jamais pris le temps de les corriger.

3.2 Une progression du plus important au moins important

Après l’état des lieux, nous avons identifié les relations entre :

• les scénarios ;
• les équipements virtuels ;
• les commandes génériques ;
• les modes de la maison ;
• les équipements physiques.

Nous avons ensuite établi une feuille de route.

Les lumières ont été relativement simples à migrer. La présence et les modes de la maison ont été beaucoup plus complexes, car ils influencent presque toutes les autres fonctions.

L’alarme a fait partie des dernières grandes fonctions basculées.

Jeedom et Home Assistant ont fonctionné en parallèle pendant quatorze jours. Au fur et à mesure que les fonctions étaient validées dans Home Assistant, je retirais Jeedom de la boucle correspondante afin d’éviter que les deux systèmes ne pilotent simultanément les mêmes équipements.

Une sauvegarde complète de Jeedom a été conservée. J’aurais donc pu revenir en arrière si nécessaire.

Étrangement, je n’ai jamais réellement envisagé d’abandonner.

4. La méthode qui a réellement fonctionné

4.1 Conserver le lien avec chaque scénario Jeedom

Chaque automatisation migrée a reçu un identifiant permettant de remonter à son origine :

jeedom_<numéro_du_scénario>_<description>

Cette convention peut sembler secondaire, mais elle est essentielle sur une installation de cette taille.

Six mois plus tard, si une lumière ou un volet adopte un comportement étrange, je peux retrouver le scénario Jeedom dont vient l’automatisation et comprendre les choix réalisés pendant la migration.

Sur les 199 automatisations finales, 171 sont reliées à un scénario Jeedom clairement identifié.

4.2 Placer la documentation dans le code

Chaque automatisation contient dans sa description :

• son origine ;
• les simplifications effectuées ;
• les correctifs appliqués ;
• les décisions importantes ;
• parfois une citation exacte de ma demande lorsqu’elle permet de comprendre le choix effectué.

Au total, environ 275 000 caractères de documentation ont été intégrés directement aux automatisations et aux fichiers.

Cette décision a été validée par un incident survenu pendant la migration.

Le répertoire de travail utilisé par Claude a été entièrement vidé par l’environnement. Les fichiers temporaires et les accès présents dans ce répertoire ont disparu.

Claude a néanmoins récupéré le projet en environ trois minutes.

Tout le travail réellement utile était déjà déployé sur le serveur et la documentation voyageait avec le code. Le seul élément réellement perdu a été le journal de bord, car il vivait uniquement dans le répertoire temporaire.

La leçon est simple :

La documentation d’une migration ne doit pas vivre uniquement dans l’espace de travail temporaire de l’assistant.

4.3 Toujours vérifier l’état réel

Nous avons adopté un cycle de déploiement pratiquement invariant :

Sauvegarde horodatée→ copie des modifications→ validation de la configuration→ rechargement ciblé→ vérification de l’état réel

La dernière étape est la plus importante.

Une configuration valide signifie uniquement que Home Assistant parvient à la lire. Elle ne garantit pas que l’automatisation répond au bon déclencheur, utilise la bonne entité ou produit le résultat attendu.

Plusieurs bugs importants n’ont pas généré la moindre erreur de configuration.

Ils ont été détectés uniquement parce que nous avons regardé ce qui se passait réellement dans la maison.

4.4 Une revue finale par grandes fonctions

À la fin de la migration, nous avons repris l’installation par catégories :

• présence et réveils ;
• aspirateur ;
• ventilation et qualité de l’air ;
• jardin ;
• chauffage ;
• multimédia ;
• électroménager ;
• capteurs.

Je validais les catégories une par une et écartais rapidement celles que je savais déjà fonctionnelles.

Cette revue a révélé des anomalies que nous n’avions pas vues pendant la migration.

Elle a également confirmé une chose : le nombre d’automatisations créées ne suffit pas à mesurer la qualité du travail. Une automatisation peut exister, être valide et ne jamais fonctionner.

5. Repenser la présence plutôt que la recopier

5.1 Les équipements ne doivent pas commander directement la maison

La gestion de la présence a été la partie la plus difficile.

Elle reposait déjà sous Jeedom sur un principe auquel je tenais :

Ce ne sont pas les appareils qui activent les modes, ce sont les virtuels.

Un téléphone, une clé, un badge, le Wi-Fi ou un autre capteur physique ne doit pas décider directement que la maison est présente ou absente.

Ces équipements mettent à jour un état virtuel. C’est ensuite ce virtuel qui agit sur le mode central de la maison.

Capteurs physiques        ↓Présence virtuelle        ↓Mode de la maison

Cette indirection évite de répéter les mêmes conditions dans chaque automatisation et permet de conserver un contrôle manuel.

Par exemple, si nous partons sans nos clés et que la maison nous considère encore présents, je peux forcer le virtuel sur « absent ». Comme toutes les fonctions passent par ce même état, l’ensemble de la maison adopte immédiatement le bon mode.

Les modes utilisés comprennent notamment Présent, Absent, Famille, Famille nuit et Vacances.

5.2 Une architecture incomprise devient rapidement dangereuse

Claude a parfois voulu simplifier cette logique en commandant directement une lampe ou un équipement depuis un interrupteur.

Techniquement, cela pouvait fonctionner.

Mais contourner le virtuel aurait créé deux chemins différents pour piloter la même fonction. Une partie de la maison aurait alors ignoré le forçage manuel ou les modes centraux. Parfois les virtuels sont utiles autant que j en avais dans jeedom clairement pas !

C’est l’une des limites que j’ai le plus souvent rencontrées : une intelligence artificielle peut produire une solution techniquement correcte tout en détruisant la cohérence globale d’une installation.

Écrire du YAML n’est pas la même chose que comprendre une maison.

5.3 Un changement de moins d’une seconde suffit

Cette complexité s’est manifestée pendant la migration.

Un capteur de présence était en état Nuit. Pendant moins d’une seconde, il est passé en Présent.

Ce changement très bref a suffi à faire sortir la maison de son mode nocturne et à réactiver le mode Présent.

L’automatisation n’était pas en erreur. Elle avait simplement réagi à l’information qu’elle recevait.

Cet épisode montre l’importance d’ajouter des temporisations, des confirmations ou des conditions supplémentaires avant de modifier un mode global à partir d’un changement instantané.

6. L’architecture Home Assistant retenue

Je suis reparti d’une installation Home Assistant vide.

Home Assistant fonctionnait auparavant uniquement comme plateforme de test. La production restait entièrement sous Jeedom.

7. Les solutions techniques nées pendant la migration

7.1 Intégrer la VMI Ventilairsec Purevent

Ma VMI Ventilairsec Purevent utilisait un protocole EnOcean propriétaire pour lequel je ne disposais pas d’une intégration viable dans Home Assistant.

Sous Jeedom, elle reposait sur un ancien plugin qui n’était plus réellement maintenu.

Nous avons étudié ce qui existait déjà dans Jeedom, analysé les échanges du protocole et construit un pont MQTT adapté à Home Assistant.

Il permet notamment de récupérer :

• la température de soufflage ;
• la température extérieure ;
• l’humidité ;
• la concentration mesurée en ppm.

Le pont fonctionne aujourd’hui de manière très stable.

La VMI a d’ailleurs été l’un des premiers équipements importants à devenir totalement autonome sous Home Assistant.

7.2 Utiliser le cloud uniquement là où il manque quelque chose

L’intégration locale de ma passerelle Somfy Tahoma V2 ne remontait pas tous les appareils visibles depuis le cloud.

Deux radiateurs Thermor manquaient notamment à l’appel.

Plutôt que de déplacer l’ensemble de l’installation Somfy vers une intégration cloud, nous avons créé un petit pont Somfy Atlantic uniquement pour ces équipements.

Le reste continue de fonctionner localement.

Cette approche correspond à ma philosophie :

Utiliser le cloud pour combler un manque précis, jamais par défaut.

Moins d’API signifie moins de dépendance extérieure, moins de risques liés à la fermeture d’un service et généralement une meilleure réactivité.

Depuis la migration, je suis passé d’une trentaine d’équipements dépendant du cloud, voire davantage, à environ une dizaine.

7.3 Accepter les limites du Somfy RTS

Les volets Somfy RTS fonctionnent de manière unidirectionnelle.

Le système peut envoyer un ordre, mais il ne reçoit pas un véritable retour de position. Si un volet est commandé avec une télécommande physique, Home Assistant peut ne pas connaître son état réel.

Un contrôle effectué avec un capteur Zigbee a mis en évidence cette limite : la mémoire des derniers ordres envoyés ne suffit pas à prouver la position physique d’un ouvrant.

Une fois encore, l’état affiché par le logiciel ne doit pas être considéré comme une vérité absolue.

7.4 Un réveil musical sans répétition

Le réveil de ma fille a également évolué pendant la migration.

Il doit choisir parmi environ 120 titres sans répéter constamment les mêmes morceaux.

Plutôt que de stocker un historique complet, la nouvelle logique conserve une seule position. Elle avance ensuite selon un pas calculé pour parcourir tous les titres avant de revenir au début.

Chaque morceau est ainsi joué une fois pendant le cycle, sans avoir besoin de mémoriser les 120 choix précédents.

Le réveil utilise un appareil Lenovo que j’avais initialement acheté pour créer une sorte d’Awtrix, mais dont je n’étais pas entièrement satisfait pour cet usage.

Cette nouvelle fonction est un bon exemple de ce que Claude m’a apporté : une autre manière d’aborder un problème que j’aurais probablement résolu avec davantage de variables et de scénarios.

voici le yaml :

alias: Réveil - Marylou
description: >-
Réveil - Marylou (scénario custom de Loïc, réintégré nativement). Objectif
d'origine (Loïc) : réveiller Marylou en musique, sans publicité, la musique
Loïc n'a que
Deezer, pas Spotify/YouTube) : add-on Music Assistant installé, Deezer
connecté par Loïc lui-même (identifiants jamais vus/saisis côté HA), playlist
Deezer de Loïc "Réveil Star 11 ans" utilisée (120 titres, bibliothèque Music
Assistant library://playlist/61). Règles données par Loïc : jamais le même
titre, 1 chanson par matin puis stop, cycle complet avant de recommencer,
laisser le morceau finir entièrement plutôt qu'un timer fixe. si la
famille dort dans la chambre de Marylou, je ne veux pas de notification vocale
du réveil… le réveil du matin qui allume les lumières dans la chambre, il faut
l'empêcher ») : ne s'exécute plus pour la chambre actuellement occupée par des
invités (input_select.invites_chambre_occupee, posé par le flow Invités
Q1/Q2/Q3). Le réveil de l'AUTRE fille continue normalement — la garde est par
personne, pas globale. Ici la garde est simple (automation dédiée à Marylou) :
bloquée si des invités dorment dans SA chambre.
triggers:

trigger: state entity_id:

input_boolean.reveil_maryloiu
from:

'off'
to:

'on'
conditions:

condition: not conditions:

condition: state
entity_id: input_select.invites_chambre_occupee
state: Marylou
actions:

action: media_player.volume_set
metadata: {}
data:
volume_level: 0.8
target:
entity_id: media_player.reveil

action: input_boolean.turn_off
metadata: {}
target:
entity_id: input_boolean.reveil_maryloiu
data: {}

action: tts.speak
metadata: {}
data:
cache: true
media_player_entity_id: media_player.reveil
message: >-
Debout Marylou ! Le soleil est levé et une super journée t'attend.
Allez, on file à l'aventure, c'est l'heure de l'école !
language: fr
target:
device_id: 2b1766d8d53d1cc2617fd1866be1a7d5
enabled: true

action: media_player.volume_set
metadata: {}
target:
entity_id: media_player.reveil
data:
volume_level: 0.12

variables:
playlist:
- deezer--itHL8ASw://track/586892122
- deezer--itHL8ASw://track/69962764
- deezer--itHL8ASw://track/2036448917
- deezer--itHL8ASw://track/124062452
- deezer--itHL8ASw://track/2093656677
- deezer--itHL8ASw://track/38875131
- deezer--itHL8ASw://track/67780327
- deezer--itHL8ASw://track/506372202
- deezer--itHL8ASw://track/107991928
- deezer--itHL8ASw://track/14477828
- deezer--itHL8ASw://track/107991910
- deezer--itHL8ASw://track/15813704
- deezer--itHL8ASw://track/1280544082
- deezer--itHL8ASw://track/600455
- deezer--itHL8ASw://track/1144396852
- deezer--itHL8ASw://track/765865642
- deezer--itHL8ASw://track/112685314
- deezer--itHL8ASw://track/870088
- deezer--itHL8ASw://track/4096018
- deezer--itHL8ASw://track/6970162
- deezer--itHL8ASw://track/983238
- deezer--itHL8ASw://track/614693
- deezer--itHL8ASw://track/984398
- deezer--itHL8ASw://track/74427067
- deezer--itHL8ASw://track/870090
- deezer--itHL8ASw://track/613093802
- deezer--itHL8ASw://track/132629130
- deezer--itHL8ASw://track/4762941
- deezer--itHL8ASw://track/714554
- deezer--itHL8ASw://track/1132150
- deezer--itHL8ASw://track/1180675
- deezer--itHL8ASw://track/1619126272
- deezer--itHL8ASw://track/1096654652
- deezer--itHL8ASw://track/98356864
- deezer--itHL8ASw://track/76395840
- deezer--itHL8ASw://track/5104476
- deezer--itHL8ASw://track/576857882
- deezer--itHL8ASw://track/2150228
- deezer--itHL8ASw://track/79587580
- deezer--itHL8ASw://track/17143858
- deezer--itHL8ASw://track/7120489
- deezer--itHL8ASw://track/3133738
- deezer--itHL8ASw://track/46251471
- deezer--itHL8ASw://track/591160032
- deezer--itHL8ASw://track/46307001
- deezer--itHL8ASw://track/581222452
- deezer--itHL8ASw://track/2425807
- deezer--itHL8ASw://track/561836
- deezer--itHL8ASw://track/993913
- deezer--itHL8ASw://track/6297555
- deezer--itHL8ASw://track/701326562
- deezer--itHL8ASw://track/72717420
- deezer--itHL8ASw://track/540175
- deezer--itHL8ASw://track/2434861
- deezer--itHL8ASw://track/884041
- deezer--itHL8ASw://track/730166752
- deezer--itHL8ASw://track/3256397
- deezer--itHL8ASw://track/4762933
- deezer--itHL8ASw://track/624630922
- deezer--itHL8ASw://track/6907156
- deezer--itHL8ASw://track/886347
- deezer--itHL8ASw://track/429944902
- deezer--itHL8ASw://track/983242
- deezer--itHL8ASw://track/355774881
- deezer--itHL8ASw://track/1366461822
- deezer--itHL8ASw://track/730187022
- deezer--itHL8ASw://track/3135726
- deezer--itHL8ASw://track/1048898
- deezer--itHL8ASw://track/921379
- deezer--itHL8ASw://track/2308590
- deezer--itHL8ASw://track/596537
- deezer--itHL8ASw://track/561685
- deezer--itHL8ASw://track/552425
- deezer--itHL8ASw://track/2277531
- deezer--itHL8ASw://track/72064735
- deezer--itHL8ASw://track/371636731
- deezer--itHL8ASw://track/85986323
- deezer--itHL8ASw://track/14338038
- deezer--itHL8ASw://track/13791930
- deezer--itHL8ASw://track/4603408
- deezer--itHL8ASw://track/46280411
- deezer--itHL8ASw://track/3664988
- deezer--itHL8ASw://track/636405
- deezer--itHL8ASw://track/81263834
- deezer--itHL8ASw://track/422283402
- deezer--itHL8ASw://track/1794017797
- deezer--itHL8ASw://track/3068802281
- deezer--itHL8ASw://track/92719914
- deezer--itHL8ASw://track/676590
- deezer--itHL8ASw://track/137233986
- deezer--itHL8ASw://track/4138933031
- deezer--itHL8ASw://track/3438162031
- deezer--itHL8ASw://track/4089650111
- deezer--itHL8ASw://track/4107993361
- deezer--itHL8ASw://track/2754899851
- deezer--itHL8ASw://track/2576083
- deezer--itHL8ASw://track/3278913111
- deezer--itHL8ASw://track/136216916
- deezer--itHL8ASw://track/1570993672
- deezer--itHL8ASw://track/92719900
- deezer--itHL8ASw://track/378310131
- deezer--itHL8ASw://track/3909034131
- deezer--itHL8ASw://track/2967025141
- deezer--itHL8ASw://track/705016602
- deezer--itHL8ASw://track/561410802
- deezer--itHL8ASw://track/1927622257
- deezer--itHL8ASw://track/1518524382
- deezer--itHL8ASw://track/3412534581
- deezer--itHL8ASw://track/3509269611
- deezer--itHL8ASw://track/12209331
- deezer--itHL8ASw://track/422280432
- deezer--itHL8ASw://track/71323824
- deezer--itHL8ASw://track/116348464
- deezer--itHL8ASw://track/4288235
- deezer--itHL8ASw://track/15194531
- deezer--itHL8ASw://track/3104484
- deezer--itHL8ASw://track/725620
- deezer--itHL8ASw://track/12809317
- deezer--itHL8ASw://track/72194071
- deezer--itHL8ASw://track/3116046
position: '{{ states(''input_number.reveil_marylou_position_playlist'') | int(0) }}'

action: music_assistant.play_media
target:
entity_id: media_player.marylou_reveil_ma2
data:
media_id: '{{ playlist[position] }}'
media_type: track
enqueue: replace

action: input_number.set_value
target:
entity_id: input_number.reveil_marylou_position_playlist
data:
value: '{{ (position + 53) % 120 }}'

delay:
hours: 0
minutes: 0
seconds: 30
milliseconds: 0
enabled: true

action: media_player.volume_set
target:
entity_id: media_player.reveil
data:
volume_level: 0.62
mode: single

8. Quand une automatisation valide trempe une salle de bain

8.1 Le Velux qui devait se fermer s’est ouvert

L’erreur la plus concrète de cette migration concernait le Velux de la salle de bain.

Le scénario devait fermer le Velux lorsqu’il commençait à pleuvoir.

À cause d’une mauvaise construction de ma part, l’automatisation a produit le résultat inverse : elle l’a ouvert.

La salle de bain s’est retrouvée trempée.

Cette erreur n’était pas liée à une décision de Claude. J’avais construit ce scénario sans lui faire valider la logique avant de l’activer.

J’ai immédiatement stoppé l’automatisation dans Home Assistant, puis repris directement la commande du Velux depuis Zigbee2MQTT.

Après la correction, j’ai vérifié deux fois le fonctionnement, y compris dans des conditions réelles.

Ce passage est important parce qu’il montre que les erreurs n’ont pas toutes été commises par l’intelligence artificielle.

L’humain reste parfaitement capable d’aller trop vite.

8.2 Une lampe allumée à 23 heures

Une autre nuit, la lampe de la chambre de ma fille s’est allumée vers 23 heures.

C’est elle qui nous a alertés en criant depuis sa chambre.

Dans un fichier de configuration, un mauvais changement de mode peut sembler abstrait. Dans une maison habitée, le résultat est immédiatement concret.

Ma femme a fait preuve d’une patience remarquable pendant ces deux semaines. Entre les lumières qui réagissaient mal, les modes en cours de reconstruction et les essais nécessaires, toute la famille a réellement participé à la migration.

8.3 Une maison doit toujours rester utilisable manuellement

Ces incidents confirment une règle que j’applique depuis longtemps :

La domotique est utile, mais tout doit rester utilisable manuellement.

Cela demande parfois davantage de matériel, de câblage ou de logique.

Mais lorsqu’un serveur tombe en panne, qu’une automatisation se trompe ou qu’une migration est en cours, on est toujours heureux de pouvoir ouvrir, fermer, chauffer ou éclairer sans dépendre du système central.

9. Les bugs silencieux sont les plus dangereux

9.1 Une condition peut être fausse sans générer d’erreur

Une expression conditionnelle mal parenthésée peut produire un fichier parfaitement valide.

Home Assistant ne signale aucune erreur, car la syntaxe est correcte. La condition reste simplement toujours fausse.

C’est ce qui est arrivé au nettoyage automatique de l’aspirateur. Il n’a pas démarré pendant environ une semaine avant que nous nous en apercevions.

Ce problème n’était pas prioritaire pendant la migration, mais il illustre parfaitement le danger des erreurs silencieuses.

9.2 Comparer le mauvais contenu MQTT

Une automatisation comparait un message MQTT complet, contenant du JSON, à la simple chaîne de caractères "ON".

La comparaison ne pouvait jamais être vraie.

Quatre automatisations partageaient cette erreur.

Ici encore, aucun message évident n’indiquait que la logique était incorrecte.

9.3 Un champ inconnu peut être ignoré

Une restriction d’accès à un tableau de bord utilisait un nom de propriété inexistant.

La configuration était acceptée, mais la restriction n’avait aucun effet.

Le problème a été découvert en comparant le fichier avec une page construite manuellement depuis l’interface, qui utilisait le bon nom de champ.

9.4 Le capteur de sel disait exactement le contraire de la réalité

Le capteur ME201WZ placé sur l’adoucisseur mesure la distance entre le capteur et la surface du sel.

Plus le bac se vide, plus cette distance augmente.

La valeur avait été interprétée à l’envers. Le système annonçait donc un niveau élevé alors que le bac était pratiquement vide.

Je l’ai découvert en regardant moi-même dans le bac.

La domotique et l’intelligence artificielle sont des outils. Elles ne doivent jamais nous faire perdre notre bon sens.

9.5 Deux automatisations peuvent se battre pour la même lampe

Dans ma chambre, un choix manuel pouvait être écrasé peu après par une automatisation utilisant le détecteur de mouvement.

Le bouton semblait ne pas fonctionner, alors qu’il fonctionnait très bien. Une autre logique reprenait simplement la main quelques secondes plus tard.

J’avais déjà connu ce type de comportement sous Jeedom, ce qui m’a permis de l’identifier rapidement.

Lorsqu’un appareil adopte un comportement incompréhensible, il faut rechercher toutes les automatisations capables de le commander, et pas uniquement celle que l’on vient de modifier.

9.6 Une routine sans paramètres ne fait rien

Une routine a également été appelée sans les paramètres obligatoires.

Elle démarrait, atteignait immédiatement sa première ligne puis s’arrêtait avant toute action utile.

Le démarrage et l’arrêt se produisaient en environ 13 millisecondes.

L’automatisation avait donc bien été déclenchée, mais elle n’avait rien accompli.

9.7 Un identifiant n’est pas toujours celui que l’on croit

Une condition utilisait l’identifiant interne d’une automatisation en pensant viser son entité Home Assistant.

Or le nom de cette entité était dérivé de son nom affiché.

La condition pointait donc vers une entité inexistante et récupérait un état indéfini.

C etait dur ces maudits identity car vite fait de se tromper en yaml

9.8 Les noms historiques ne prouvent rien

Un interrupteur nommé « salle de bain » commandait en réalité celle des enfants.

Deux relais de chauffage de la véranda utilisaient une logique inversée.

Ce type de vérité ne peut pas être déduit depuis un nom dans une base de données.

Il faut demander à la personne qui connaît l’installation ou effectuer un test physique.

J’ai volontairement réalisé cette migration hors période de chauffe. Habitant au pied du Jura, je n’aurais certainement pas entrepris la même opération au mois de décembre.

10. Les erreurs commises par Claude

10.1 Trois automatisations créées en double

Claude a recréé à trois reprises une automatisation qui existait déjà.

Sur un parc de 199 automatisations construit en plusieurs jours, il n’a pas toujours retrouvé ce qui avait été déployé précédemment avant de proposer une nouvelle version.

Les doublons ont été vus immédiatement pendant les tests post-déploiement.

Ils n’ont pas été détectés parce que Claude aurait soudainement compris son erreur, mais parce que nous contrôlions systématiquement le résultat.

10.2 Une tendance à croire les données plutôt que l’humain

À plusieurs reprises, Claude a accordé davantage de crédit aux états informatiques qu’à mes observations.

Lorsque je disais qu’un volet était fermé ou que le bac de sel était vide, il pouvait continuer à raisonner à partir de la valeur affichée.

Il fallait lui rappeler que j’étais physiquement dans la maison et que je voyais ce qui se passait au-delà de sa connexion SSH.

J’avais intégré cette règle dans les consignes :

Un fait physique observé sur place prime toujours sur l’état remonté par le système.

Claude a ensuite mieux respecté cette hiérarchie, sans pour autant devenir infaillible.

10.3 Tester par un autre chemin ne valide pas le vrai fonctionnement

À deux reprises, une notification a été vérifiée par un moyen différent de celui réellement utilisé dans l’automatisation.

La notification arrivait, mais cela ne prouvait pas que le déclencheur, le contenu et le chemin réel fonctionnaient ensemble.

Un test n’est valable que s’il reproduit le parcours complet.

10.4 Déclarer trop rapidement qu’une fonction n’existe pas

Claude a parfois conclu qu’une fonction était absente ou inutilisée sans avoir déroulé toutes les couches de virtuels et de scénarios.

Cela s’est notamment produit autour de l’alarme et de la pompe à chaleur.

Le problème venait souvent de la profondeur de l’architecture Jeedom : une action pouvait passer par plusieurs virtuels avant d’atteindre l’équipement final.

10.5 Des diagnostics affirmés avec trop de certitude

Une lampe décrite de manière ambiguë a été considérée comme injoignable. Claude a rapidement évoqué un problème de cloud.

Je lui ai fait remarquer qu’elle répondait parfaitement à son interrupteur.

Dans ce cas, le problème venait avant tout d’une mauvaise interprétation de la description, pas d’une panne réelle.

Claude a également proposé à plusieurs reprises de changer une lampe ou d’acheter un nouvel équipement alors que je voulais d’abord comprendre l’existant.

C’est une tendance qu’il faut surveiller : remplacer un appareil peut être une solution rapide, mais ce n’est pas toujours la bonne réponse.

10.6 Les performances dépendaient du modèle utilisé

Tous les modèles testés n’avaient pas la même qualité de raisonnement.

Certains géraient mieux les longues chaînes de dépendances et la compréhension du code existant. D’autres oubliaient plus facilement ce qui avait déjà été construit ou affirmaient trop rapidement qu’une fonction ne pouvait pas marcher.

Je ne souhaite pas transformer cet article en comparaison de modèles. Le point important est ailleurs :

Aucun modèle ne remplace une méthode de vérification.

Les erreurs de l’intelligence artificielle ont été corrigées soit par mes observations, soit par les contrôles effectués après le déploiement. Elles ne se sont pas toutes corrigées seules.

11. Ce que nous avons choisi de ne pas faire

11.1 La localisation des AirTags

Nous avons étudié plusieurs méthodes permettant de récupérer la localisation des AirTags.

Les solutions disponibles impliquaient soit des automatisations iOS que je ne souhaitais pas utiliser, soit une extraction de clés présentant un risque pour mon compte Apple.

Nous avons donc abandonné cette partie.

Mais j y arriverais il faut juste que je revoie comment faire… stay alert …

11.2 Refaire ce que Home Assistant sait déjà gérer

Le suivi de la production solaire et des heures creuses n’a pas été migré depuis Jeedom.

Home Assistant propose déjà les fonctions nécessaires. Reconstruire les anciennes logiques aurait ajouté du travail sans apporter de valeur.

11.3 Les zones de l’aspirateur

L’aspirateur avait été déplacé physiquement, ce qui invalidait sa cartographie.

Le nettoyage global quotidien a été remis en service, mais le découpage par pièce a été reporté en attendant une nouvelle cartographie.

La migration ne devait pas devenir une excuse pour reconstruire immédiatement chaque détail. Depuis j’ai pu le refaire en manuel avec une carte et en partant de la base …Sacrée galère !!!

12. Le résultat au quatorzième jour

Au terme de la migration, Home Assistant comptait :

Élément	Nombre
Entités	2 990
Automatisations	199
Automatisations traçables vers Jeedom	171
Scripts	51
Intégrations distinctes	65
Entrées de configuration	121
Documentation intégrée	Environ 275 000 caractères

Les automatisations couvrent notamment l’éclairage, la présence, les volets, la sécurité, le chauffage, le jardin, les chambres des enfants, la cuisine, les réveils, le jacuzzi, le multimédia, l’aspirateur, l’énergie, les notifications et la VMI.

(Capture des statistiques finales de Home Assistant.)

Le quatorzième jour, Jeedom a été éteint.

Les caméras fonctionnent avec Frigate, les passerelles ont été basculées et Jeedom n’est plus un système de secours.

Je le conserve toutefois comme environnement de test, exactement comme Home Assistant me servait auparavant de plateforme d’expérimentation.

La domotique n’est jamais réellement terminée. Je considère néanmoins que la migration est réussie parce que Home Assistant est aujourd’hui plus complet et plus réactif que ne l’était mon installation Jeedom.

13. Quatre jours de recul sur Home Assistant

13.1 Une réactivité immédiatement perceptible

Au moment d’écrire cet article, la maison fonctionne principalement sous Home Assistant depuis seulement quatre jours.

Ce n’est pas suffisant pour tirer des conclusions sur plusieurs mois de stabilité.

La différence de réactivité est néanmoins très visible, notamment pour la présence et les actions locales.

Le Bluetooth est également devenu réellement exploitable et fiable dans mon installation.

13.2 Beaucoup moins de cloud

La majorité des équipements communiquent maintenant localement.

Je suis passé d’une trentaine d’équipements dépendant du cloud, peut-être davantage, à environ une dizaine.

Cette réduction améliore la rapidité et l’autonomie de la maison, tout en diminuant ma dépendance à des API susceptibles de changer ou de disparaître.

13.3 Une consommation informatique réduite

Home Assistant Green consomme très peu.

La migration m’a permis de réduire les ressources informatiques consacrées au cœur de la domotique et de simplifier son accès à distance.

Le NUC i7 était largement dimensionné pour Jeedom. La nouvelle répartition des services me semble aujourd’hui plus cohérente.

13.4 Tout n’est pas meilleur

Après autant d’années sous Jeedom, je dois encore réapprendre beaucoup de choses.

La conception des scénarios Jeedom reste un élément qui me manque. Je la connaissais parfaitement et pouvais construire rapidement des logiques complexes.

Le système de notifications proposé avec Jeedom Connect me paraissait également plus agréable.

Mes tableaux de bord Home Assistant ne sont pas encore forcément meilleurs. Ils sont simplement nouveaux et devront évoluer avec le temps.

Changer de plateforme ne transforme pas instantanément chaque partie de l’installation.

14. Faut-il quitter Jeedom pour Home Assistant ?

Je ne conseillerais pas cette migration à tous les utilisateurs Jeedom.

J’ai d’ailleurs conservé Jeedom dans la maison de mes parents.

Leur installation est plus simple, elle fonctionne correctement et Jeedom reste plus facile à maintenir pour eux comme pour moi. Il n’y aurait aucun intérêt à leur imposer un changement de plateforme uniquement parce que Home Assistant évolue rapidement.

Jeedom reste également pertinent pour une personne qui maîtrise parfaitement ses scénarios et ne dispose pas du temps nécessaire pour apprendre une nouvelle logique.

Home Assistant devient particulièrement intéressant lorsque l’on recherche :

• davantage d’intégrations locales ;
• une forte réactivité ;
• un écosystème très actif ;
• une meilleure prise en charge de certaines technologies ;
• une grande liberté d’architecture.

Mais cette liberté demande du temps.

Il faut accepter de repartir de zéro, de remettre en question ses habitudes et de ne pas considérer une traduction automatique comme une migration terminée.

15. Mon avis

15.1 Ce que Claude m’a réellement apporté

Claude ne m’a pas uniquement fait gagner du temps.

Il m’a permis de regarder mon installation avec davantage de recul, de découvrir d’autres approches et d’avancer sur des parties que je ne savais pas réaliser seul.

Sans lui, cette migration aurait probablement demandé plusieurs mois.

Je pense que je l’aurais tout de même entreprise un jour, mais certainement à l’occasion d’une panne ou d’une obligation. Je n’aurais probablement pas décidé spontanément de reconstruire six années de domotique tout en conservant la maison en production.

Le coût total d’environ 40 €, incluant une seconde vérification des scénarios les plus critiques, me semble faible par rapport à la quantité de travail réalisée.

15.2 Ce qu’une intelligence artificielle ne peut pas faire

Pour moi, on ne peut pas laisser une intelligence artificielle entièrement autonome sur une maison.

Cette expérience me le confirme.

Je ne lui confierais seul ni l’alarme, ni le chauffage, ni les ouvrants, ni la présence, ni même une simple lampe dans une chambre.

Ce n’est pas parce que toutes ces fonctions présentent le même niveau de risque. C’est parce qu’une erreur minuscule peut provoquer un comportement que l’IA ne verra jamais depuis son terminal.

Elle ne sent pas la pluie entrer dans la salle de bain.

L’ia n’entend pas un enfant crier parce que sa lampe vient de s’allumer.

Elle ne voit pas que le bac de sel est vide alors que le capteur annonce 100 %.

L’intelligence artificielle apporte de l’endurance, de la vitesse et de nouvelles idées. Le jugement reste humain.

15.3 Les conseils que je retiens

La première règle est de prendre son temps.

Une migration aussi importante doit être réalisée hors période de chauffage, loin des périodes de stress et lorsque l’on peut rester disponible pour surveiller la maison.

La deuxième règle est de ne jamais faire aveuglément confiance à l’outil.

Il faut sauvegarder, tester, observer et recommencer.

La troisième est de ne pas copier toute l’ancienne installation sans réfléchir.

La migration m’a permis de voir mes propres erreurs : trop de virtuels imbriqués, trop de scénarios et des fonctions domotisées sans besoin réel.

Enfin, il n’est pas nécessaire d’être développeur professionnel pour travailler avec une intelligence artificielle.

Il faut en revanche comprendre son installation, connaître les conséquences d’une action et être capable de reconnaître quand le résultat affiché ne correspond pas à la réalité.

15.4 Mon verdict

Je suis très enthousiaste devant le résultat.

En quatorze jours, nous avons reconstruit une installation issue de six années de Jeedom, analysé 12 627 commandes, créé 199 automatisations et intégré des équipements pour lesquels aucune solution simple n’existait.

Mais ces quatorze jours n’ont rien eu de magique.

Ils ont demandé environ 42 heures de travail humain, de nombreux échanges, des arrêts volontaires, des contrôles en conditions réelles et une famille particulièrement patiente.

Claude n’a pas remplacé ma connaissance de la maison.

Il l’a démultipliée.

C’est probablement la meilleure manière de résumer cette expérience : l’intelligence artificielle peut nous aider à aller beaucoup plus loin, à condition que nous restions responsables de la direction et du résultat.

Tout est possible, tout est réalisable, c’est le jeu de la vie.

J’espère que cet article vous aura plu.

N’oubliez pas que la vie est une fête.

Loïc