Après onze articles sur mon setup Home Assistant, place au bêtisier technique : les bugs, pièges et comportements contre-intuitifs qui m’ont fait perdre du temps, et comment je les ai résolus.
Cette série a suivi la construction de mon installation Home Assistant, pièce par pièce. Ce dernier article change de format : plutôt qu’un système complet, ce sont sept retours d’expérience concrets, chacun avec le symptôme rencontré, la cause réelle (souvent différente de ce qu’on imagine au premier abord) et la solution qui a tenu dans la durée. Si tu débutes avec Home Assistant, ces pièges te guettent probablement aussi tôt ou tard.
1. Modifier la configuration interne sans API disponible
Sur certaines installations (accès terminal restreint, pas d’API Core exposée), il n’existe aucun moyen d’appeler les services de mise à jour du registre d’entités par la voie officielle. La seule option restante est l’édition directe des fichiers de configuration interne au format JSON (registre des appareils, registre des entités, tableaux de bord).
J’ai découvert le piège en renommant les entités d’un appareil fraîchement ajouté. Modifier le fichier du registre des appareils puis simplement redémarrer Home Assistant a très bien fonctionné : le changement de nom a persisté. Mais la même méthode sur le registre des entités (changer un entity_id) s’est annulée toute seule après le redémarrage.
La cause : ce fichier est réécrit en permanence par le processus encore actif (device polling, changements de disponibilité…). Un simple redémarrage flushe une copie en mémoire potentiellement périmée qui écrase l’édition manuelle avant même que le nouveau processus démarre.
La solution qui fonctionne à tous les coups pour ce type de fichier fréquemment réécrit : 1. Arrêter le service Home Assistant et attendre confirmation qu’il est totalement injoignable (pas juste redémarré). 2. Éditer le fichier JSON, valider sa syntaxe avant d’écraser l’original. 3. Redémarrer et attendre le retour à 200 sur l’interface.
Toujours faire une copie de sauvegarde horodatée du fichier avant toute édition manuelle de ce type.
2. Le scalaire YAML plié qui bouffe les sauts de ligne Telegram
Un rapport Telegram multi-lignes (plusieurs sections, des puces) qui arrive en un seul pavé de texte illisible, alors que le template Jinja contenait bien des retours à la ligne : classique piège YAML.
La cause est le style de scalaire utilisé pour la clé message. Le style plié (>) convertit chaque saut de ligne simple en espace, c’est son comportement documenté, pas un bug. Résultat : le contenu structuré devient un mur de texte, et les balises {% for %} / {% endfor %} placées sur leurs propres lignes se retrouvent collées au texte qui les entoure.
# Mauvais pour un message structuré
message: >
{% for item in items %}
- {{ item.name }}
{% endfor %}
# Correct : scalaire littéral
message: |
{%- for item in items -%}
- {{ item.name }}
{% endfor -%}
Le style littéral (|) préserve les sauts de ligne tels quels. Pour les tags Jinja de structure, ajouter -%} en fin de balise absorbe leur propre saut de ligne pour éviter les lignes vides parasites. Le style plié > reste parfaitement adapté à un message d’une seule phrase.
3. Un capteur template avec condition qui refuse de charger
Erreur au démarrage : 'condition' is an invalid option for 'template', alors que la syntaxe semblait conforme à la documentation. Le coupable : plusieurs capteurs déclarés dans la même liste, partageant un seul bloc trigger: au niveau supérieur, avec une clé condition: propre à un seul de ces capteurs à l’intérieur.
Sur les versions récentes de Home Assistant, cette combinaison n’est pas supportée : une condition individuelle imbriquée dans un item de liste sensor: alors que plusieurs capteurs partagent un même trigger: fait planter le chargement de l’intégration template.
# Ne fonctionne pas si un item a sa propre condition
template:
- trigger:
- platform: state
entity_id: sensor.source
sensor:
- name: "Capteur A"
- name: "Capteur B"
condition: "{{ trigger.to_state.state not in ['unknown','unavailable'] }}"
# Fonctionne : un bloc template par capteur, chacun avec son trigger + condition
template:
- trigger:
- platform: state
entity_id: sensor.source
condition: "{{ trigger.to_state.state not in ['unknown','unavailable'] }}"
sensor:
- name: "Capteur B"
La solution : sortir chaque capteur conditionné dans son propre item template:, avec son trigger: et sa condition: à lui, même si cela duplique le déclencheur.
4. Une intégration tierce qui remet tout à zéro à chaque redémarrage
Un capteur d’intégration tierce (dans mon cas, un véhicule connecté) qui repasse systématiquement à unknown après chaque redémarrage complet de Home Assistant, ou dès que l’appareil source est en veille. Frustrant pour un tableau de bord ou un rapport automatisé qui s’appuie dessus.
La cause : certaines intégrations personnalisées n’implémentent pas la restauration d’état (restore_state) pour leurs capteurs. Contrairement aux capteurs template classiques, rien n’est mémorisé entre deux démarrages, et si l’appareil source ne répond pas immédiatement au redémarrage, l’entité reste à unknown jusqu’au prochain poll réussi.
La solution durable n’est pas un simple garde-fou dans un template, mais des capteurs « cache » basés sur trigger : ils ne se mettent à jour que lorsque le capteur source renvoie une vraie valeur, et conservent sinon leur dernier état, restore_state inclus.
Avant de blâmer une intégration tierce pour un état « unknown » persistant, vérifie d’abord si elle expose restore_state : un capteur template en façade avec la bonne condition règle 90% de ces cas en dix minutes.
5. Les helpers avec initial: qui oublient tout à chaque démarrage
Certains helpers (input_boolean, input_number) définis directement dans la configuration YAML avec une valeur initial: reviennent systématiquement à cette valeur par défaut à chaque redémarrage de Home Assistant, même s’ils avaient été modifiés manuellement juste avant.
C’est un comportement documenté mais facile à oublier : la clé initial: sert justement à forcer une valeur de départ, elle prime sur l’état restauré. Pour un helper qui doit vraiment persister dans le temps (un mode saisonnier, un compteur), il ne faut simplement pas la définir : sans initial:, l’état restauré au redémarrage est utilisé par défaut.
# Se réinitialise à chaque redémarrage
input_boolean:
mode_absence:
name: Mode absence
initial: false
# Persiste correctement entre les redémarrages
input_boolean:
mode_absence:
name: Mode absence
6. Une base de données qui explose le disque en silence
Le disque système passe progressivement à 98% de remplissage sans alerte visible, jusqu’à ce que les sauvegardes automatiques ou les mises à jour échouent faute d’espace. La base de données de l’historique (recorder) est le suspect numéro un.
La cause typique : une rétention (purge_keep_days) réglée trop haut par rapport au volume réel de capteurs, combinée à des statistiques court terme conservées bien plus longtemps que nécessaire. Quelques capteurs très bavards (uptime, métriques système, minuteurs internes) génèrent des dizaines de milliers d’écritures par jour à eux seuls et gonflent la base sans apporter de valeur historique.
recorder:
purge_keep_days: 10
exclude:
domains:
- automation
- script
entities:
- sensor.uptime_systeme
- sensor.cpu_utilisation
Piège associé : exclure automation et script du recorder signifie que la base ne peut plus dire si une automatisation s’est déclenchée, il faut alors se rabattre sur l’attribut last_triggered de l’entité. Avant toute purge massive, libère d’abord de l’espace disque (vieilles sauvegardes) : compacter une base volumineuse est souvent impossible sans marge disponible.
7. Le piège que la 2026.7 a enfin réglé
Ça m’est arrivé sur un capteur binaire remonté par une intégration tierce peu causante : une automatisation censée se déclencher dès que la porte du garage passait à on restait obstinément silencieuse une fois sur trois. Autre variante rencontrée sur une entité de type « event » liée à un bouton connecté : le premier appui déclenchait bien l’automatisation, mais un deuxième appui juste après, sans changement de valeur entre les deux, ne redéclenchait rien du tout.
La cause : un state trigger brut ne sait gérer ni les passages par unknown/unavailable (l’automatisation se déclenche au mauvais moment, ou pas du tout, selon que la valeur intermédiaire compte comme un changement), ni le cas d’une entité « event » dont l’état ne change pas de valeur d’un événement à l’autre alors qu’un nouvel événement s’est bien produit. Avant, la seule parade tenait dans des conditions manuelles ajoutées à la main pour filtrer ces états parasites :
trigger:
- platform: state
entity_id: binary_sensor.porte_garage
condition:
- condition: template
value_template: >
{{ trigger.to_state.state not in ['unknown', 'unavailable'] }}
Depuis la mise à jour Home Assistant 2026.7, ce garde-fou n’est plus nécessaire dans l’éditeur graphique : les triggers et conditions orientés intention, introduits en Labs fin 2025 et devenus le comportement par défaut de l’éditeur d’automatisation avec cette version, gèrent eux-mêmes ces cas particuliers. Chaque trigger décide de la bonne façon de traiter unknown/unavailable selon son objectif, et un trigger d’événement direct redéclenche correctement même sans changement de valeur entre deux événements. Le YAML existant continue de fonctionner tel quel, sans migration obligatoire : c’est une option en plus dans l’éditeur graphique, pas un remplacement forcé.
Bilan : tester après redémarrage, pas juste après reload
Le point commun à ces sept gotchas, c’est qu’aucun ne se voit en rechargeant simplement la configuration. Ils n’apparaissent qu’au redémarrage complet, à la mise en veille d’un appareil, ou après plusieurs jours d’accumulation silencieuse. La leçon générale : après un changement qui touche la persistance d’état (registre, helper, capteur template, base de données), toujours valider avec un vrai redémarrage complet du système, pas uniquement un reload à chaud. C’est ce qui distingue une configuration qui marche en test d’une configuration qui tient réellement dans la durée.
FAQ
Faut-il éditer les fichiers de configuration internes de Home Assistant à la main ?
Seulement en dernier recours, quand aucune API ou interface officielle ne permet le changement, et toujours avec une sauvegarde préalable du fichier.
Pourquoi mon message Telegram multi-lignes arrive-t-il tout collé ?
Le scalaire YAML plié (>) transforme les sauts de ligne en espaces. Utilise le scalaire littéral (|) pour préserver la mise en forme.
Comment éviter qu’un helper se réinitialise à chaque redémarrage ?
Ne pas définir de clé initial: dans sa configuration YAML : sans elle, le dernier état connu est restauré automatiquement.
Ma base de données Home Assistant grossit trop vite, que faire en premier ?
Réduis purge_keep_days dans le recorder et exclus les capteurs les plus bavards (uptime, métriques système) avant d’envisager une purge manuelle.
Comment savoir si une automatisation exclue du recorder s’est bien déclenchée ?
Consulte l’attribut last_triggered de l’entité automatisation elle-même, la base de données ne conserve plus cet historique une fois le domaine exclu.
Stack utilisée : Home Assistant (Core + recorder), YAML, Jinja2, intégration Telegram, capteurs template trigger-based, intégration véhicule connecté tierce.
