En bref
| Contexte | Migration Jeedom → Home Assistant, en cours depuis 2023 |
| État fin 2025 | Home Assistant opérationnel en production, Jeedom toujours actif en parallèle |
| Prochaine étape | Extinction de Jeedom, objectif été 2026 |
Le bilan complet
Une migration qui avance, mais pas terminée
Fin 2025, je n’ai pas éteint Jeedom. Ce n’est pas un échec — c’est une migration prudente. Home Assistant tourne en production depuis plusieurs mois, je bascule les fonctionnalités une par une, mais tant que certains blocs critiques ne sont pas en place côté HA, Jeedom reste allumé.
Ce qui me bloque encore : principalement la gestion d’alarme. Tant que je n’ai pas une alarme fiable et complète dans Home Assistant, il est hors de question d’éteindre Jeedom. C’est le dernier verrou.
Le matériel : une ZimaBoard 2
J’ai profité de cette migration pour upgrader le matériel. Home Assistant tourne maintenant sur une ZimaBoard 2, installée dans mon tableau électrique domotique aux côtés de l’ancienne plateforme Jeedom (une J2 qui tournait depuis des années).
La ZimaBoard 2, c’est compact, économe, silencieux, et largement suffisant pour tout ce que je lui demande — automatisations, caméras, intégrations, voice PE. Elle embarque des contrôleurs Z-Wave/Zigbee, une clé Bluetooth, et elle est connectée au réseau en filaire évidemment. Je rajouterai peut-être un SSD externe pour fiabiliser le stockage, mais pour le reste, c’est en place.
Les tableaux de bord : fonctionnels, pas figés
Je n’utilise pas vraiment les tableaux de bord comme interface principale — pas de tablette murale, pas d’écran permanent. Je pilote ma maison principalement depuis mon smartphone, avec des commandes murales et la voix.
Les dashboards que j’ai construits sont donc des outils de contrôle, pas des vitrines. Vue principale avec les infos essentielles (mode présence/absence, mode jour/nuit, lever/coucher du soleil, températures), puis des vues dédiées par thème : sécurité, énergie, chauffage, pièces.
J’ai opté pour une navigation par tuiles pièces avec des entrées cachées et un bouton retour — une technique assez connue qui donne un comportement d’application sans complexité inutile.
Le tableau de bord pièces natif de Home Assistant (encore en bêta) est prometteur mais pas assez flexible pour ce que je veux. Je ne l’utilise pas vraiment.
Les intégrations en place
Voici les principales intégrations actives sur mon installation :
- Arlo — gestion des caméras de sécurité, intégration Jeedom désactivée
- Netatmo — caméra extérieure et chauffage (Jeedom toujours en parallèle pour le chauffage)
- Alarmo — gestion d’alarme périmétrique/volumétrique (voir section dédiée)
- GCE IPX 800 V4 — remontée des consommations électriques en temps réel
- GRDF Gaspar — suivi de la consommation gaz
- Electricity Maps — indicateur de décarbonation du réseau électrique
- Free Mobile — envoi de SMS d’alerte
- Google Cast — audio sur les enceintes connectées
- Gemini + Google Translate TTS — intégration IA et synthèse vocale
- MQTT — protocole de messagerie (serveur externe pour l’instant, à rapatrier sur HA)
- Z-Wave JS — protocole Z-Wave (sans le serveur JS pour l’instant)
- Zigbee (ZHA) — protocole Zigbee
- Philips Hue — éclairage (à terme peut-être migré en Zigbee pur)
- Mammotion — robot tondeuse
- Spook — outil de diagnostic pour détecter les entités orphelines
- Studio Code Server — édition des fichiers de config directement depuis HA
- NGX Proxy Manager — reverse proxy et gestion des certificats
- Proton Drive — sauvegarde des données HA (quelques instabilités)
- Voice PE — assistant vocal local (ESPHome, Wyoming, Speech-to-Phrase, Piper)
L’alarme : le point bloquant
La gestion d’alarme native de Home Assistant est trop basique. Alarmo est une bien meilleure option — complet, flexible, bien maintenu. J’ai pu y reconfigurer mes scénarios d’alarme : présence, nuit, vacances, avec des exceptions.
Le problème : unifier dans Alarmo l’alarme périmétrique/volumétrique ET les détections d’incendie et d’inondation est extrêmement lourd à configurer. Il faudrait pouvoir créer plusieurs instances spécialisées (une alarme “événements critiques” toujours active, une alarme “intrusion” contextuelle), ce qui n’est pas possible aujourd’hui.
Ma solution : je sors les capteurs incendie et inondation d’Alarmo et je les gère via des automatisations simples. Moins élégant, mais plus pratique.
Le chauffage : Netatmo, pas encore Tado
J’avais tenté de migrer de Netatmo vers Tado pour le chauffage — j’ai fait marche arrière. L’intégration Tado dans Home Assistant n’expose pas les informations de consigne de température (nom du planning, durée), ce qui rend la logique d’automatisation très difficile à construire. Je reviens à Netatmo et j’attendrai la fin de la saison de chauffe pour retenter.
L’intégration Netatmo dans HA a aussi ses limites : la réactivité est mauvaise, même avec les webhooks. Un changement de mode peut mettre 1 à 2 minutes à se propager — là où Jeedom était quasi-instantané. C’est gênant.
Les scripts et automatisations : la vraie valeur ajoutée
Ce que je commence à avoir de bien dans Home Assistant, c’est la couche de scripts réutilisables.
Script de notification centralisé : un seul point d’entrée avec titre, message et sévérité. En fonction de la sévérité, le script choisit le canal — push smartphone, mail, SMS, ou tous à la fois pour les alertes critiques. Toutes mes automatisations appellent ce script sans avoir besoin de savoir “comment” notifier. Changer le canal de notification se fait à un seul endroit.
Gestion des volets avec bascule jour/nuit : plutôt que de coder les horaires dans chaque automatisation, j’ai une entité “mode jour/nuit” qui se met à jour au lever et coucher du soleil, et qui recalcule ses horaires chaque nuit à 1h du matin. Les automatisations volets réagissent à ce mode — propre et maintenable.
Notifications d’état anormal : porte restée ouverte, verrou déverrouillé, lumière allumée trop longtemps. Simples, utiles, et redondants (deux capteurs par porte pour fiabiliser).
Gestion du chauffage en mode absent : des boutons avec des horaires de retour prédéfinis (18h45, etc.) appellent un script qui calcule le timestamp précis et informe Netatmo. Si l’horaire change, il suffit de modifier la valeur du bouton — pas de réécriture de script.
Pourquoi Home Assistant et pas Jeedom ?
Je ne fais pas cette migration par plaisir. Je la fais parce que je n’ai plus confiance dans la gestion du projet Jeedom. Des régressions non annoncées, des changements fonctionnels qui cassent des automatisations sans communication préalable, une qualité de développement qui sent l’amateurisme.
Home Assistant, c’est l’inverse : les breaking changes sont annoncés longtemps à l’avance, la rétrocompatibilité est maintenue autant que possible, et ça se sent que c’est développé à grande échelle avec de vraies pratiques d’ingénierie.
Jeedom, je le considère comme un projet du passé. Pas pour tout le monde, peut-être encore utile pour certains usages — mais pour moi, c’est terminé. J’espère avoir éteint la plateforme d’ici l’été 2026.