Mise à jour 2026.7 : Home Assistant corrige enfin l’un de ses plus gros défauts

Home Assistant 2026.7 est disponible, et cette mise à jour de juillet coche une case que beaucoup attendaient depuis un moment : rendre les automatisations plus simples à créer, sans sacrifier ce qui fait l’intérêt de Home Assistant.

Ce n’est pas un bouton déplacé ou une retouche cosmétique. La grande nouveauté, c’est la sortie des déclencheurs et conditions « orientés usage » (ceux qui étaient en Labs depuis un moment) qui deviennent le comportement par défaut dans l’éditeur d’automatisations. Concrètement : au lieu de raisonner en termes d’entités, d’états et d’attributs parfois obscurs, Home Assistant se rapproche enfin de la façon dont on pense ses scénarios.

Avant, pour créer une automatisation du type « quand un mouvement est détecté dehors, allumer les lumières extérieures », il fallait choisir le bon type de déclencheur, sélectionner une ou plusieurs entités, connaître leur état exact, puis vérifier que l’action visait bien les bons équipements. Pas impossible, mais ça demandait une certaine gymnastique mentale. Et quand on débute, cette gymnastique ressemble parfois à un grand écart.

Avec 2026.7, on part de ce qu’on veut faire. « Mouvement détecté dehors ». « Température trop basse dans la chambre ». « Batterie faible ». « Porte ouverte ». « Soleil couché ». Home Assistant se charge du reste.

C’est plus intuitif, et plus robuste. Les deux vont souvent ensemble.

Des automatisations qui parlent enfin le langage de la maison

Le changement le plus concret concerne donc l’éditeur d’automatisations. Les purpose-specific triggers and conditions (déclencheurs et conditions spécialisés, si on veut une traduction) deviennent accessibles à tous.

Le principe : au lieu de choisir une logique technique, vous choisissez une situation réelle.

Pour allumer le chauffage quand la température d’une pièce descend sous 18 °C, vous n’avez plus à penser « déclencheur numérique », « attribut temperature », « valeur inférieure à ». Vous sélectionnez un déclencheur lié à la température, vous indiquez votre seuil, c’est plié.

Même chose pour les capteurs de mouvement. Auparavant, il fallait parfois savoir si le capteur passait à l’état « on », « detected », « occupancy », « motion » ou autre joyeuseté du genre selon le fabricant. L’éditeur propose maintenant directement un déclencheur « mouvement détecté ».

Ce n’est pas anecdotique. La cohérence dans les noms, c’est ce qui rend une automatisation lisible six mois plus tard – pas seulement le soir où on la crée.

Home Assistant annonce plus de 200 nouveaux déclencheurs et plus de 200 nouvelles conditions. Mouvement, présence, batterie, température, humidité, ouverture, média, volume, état d’un appareil, position d’un volet, disponibilité d’une mise à jour, retour d’un aspirateur à sa base, tondeuse robot rentrée au dock : les cas courants sont couverts.

Pour quelqu’un d’expérimenté, ça fait gagner du temps. Pour un débutant, ça supprime une vraie barrière. Et pour un installateur qui doit laisser quelque chose de compréhensible à son client, c’est une très bonne nouvelle.

Les zones deviennent vraiment utiles dans les scénarios

Les nouveaux déclencheurs et conditions fonctionnent avec les cibles Home Assistant : pièce, zone, étage, appareil, entité ou étiquette. C’est là que ça devient intéressant.

Exemple concret. Vous avez trois capteurs de mouvement dans le jardin : un devant la porte d’entrée, un près du garage, un côté terrasse. Avant, vous auriez créé un déclencheur avec les trois entités, ou trois déclencheurs séparés. Si vous remplaciez un capteur, il fallait revenir modifier l’automatisation.

Maintenant, vous visez la zone « Extérieur » : quand un mouvement est détecté dehors, allumer les lumières extérieures. Si vous ajoutez un nouveau capteur dans cette zone dans six mois, l’automatisation continue de fonctionner sans toucher à rien.

Même logique pour les lumières. Vous dites « allumer les lumières de la zone Extérieur ». Si vous ajoutez une applique Zigbee, un projecteur Shelly ou une ampoule Hue dans cette zone plus tard, votre scénario reste valide.

C’est la différence entre figer une liste d’entités et décrire une intention. La deuxième approche vieillit beaucoup mieux.

Les étiquettes suivent la même logique. Créez une étiquette « Décoration Noël », appliquez-la à vos prises connectées et guirlandes, puis pointez dessus dans vos automatisations. Une seule automatisation allume tout le bazar au coucher du soleil, peu importe où les guirlandes se trouvent dans la maison.

Les nouveaux choix « first », « each » et « all » changent la donne

Quand une automatisation cible plusieurs appareils, Home Assistant doit savoir comment réagir. La version 2026.7 apporte trois comportements distincts : first, each et all.

Le mode first déclenche dès que le premier appareil correspond. Une fenêtre s’ouvre dans le salon → on coupe le chauffage. Pas besoin d’attendre que toutes les fenêtres soient ouvertes.

Le mode each déclenche à chaque occurrence. Chaque fois qu’une personne rentre à la maison, on envoie une notification ou on met à jour un journal de présence.

Le mode all attend que tous les éléments ciblés correspondent. Tous les volets du rez-de-chaussée sont fermés → on active le mode nuit.

Ce type de logique existait déjà, mais ça demandait des groupes, des templates ou des conditions bien ficelées à la main. Ici, c’est dans l’interface, lisible, et pensé pour être compris sans ouvrir la boîte à outils du parfait petit YAMListe.

Moins de pièges techniques dans les automatisations

Home Assistant est puissant, mais il a ses chausse-trappes. Les états « unknown » ou « unavailable », par exemple, ont fait perdre quelques cheveux à plus d’un.

Un capteur qui devient indisponible puis revient à son état normal peut déclencher une automatisation de façon inattendue si elle est mal construite. Même souci avec certains événements qui ne changent pas d’état de façon évidente.

Les nouveaux déclencheurs spécialisés gèrent une partie de cette complexité en interne. Home Assistant sait mieux ce qui doit être ignoré et ce qui correspond réellement à l’événement recherché.

Ça ne veut pas dire que les utilisateurs avancés perdent la main. Les déclencheurs classiques, les templates, les conditions complexes et le YAML restent disponibles. Mais pour les scénarios courants, le nouveau modèle réduit nettement les risques de se tromper.

Dans une maison réelle, ça compte. Une lumière qui ne s’allume pas au bon moment, c’est agaçant. Un chauffage qui se coupe mal ou une alarme qui réagit de travers, c’est une autre histoire.

Le YAML reste bien présent

Home Assistant le dit clairement : rien ne casse. Les automatisations existantes continuent de fonctionner. Pas de migration obligatoire, pas de conversion forcée.

Les anciens déclencheurs restent disponibles. Le YAML reste au cœur du fonctionnement : l’interface en génère toujours en arrière-plan.

Ces nouveaux déclencheurs sont d’ailleurs pensés pour être propres en YAML. Les noms sont plus lisibles, plus proches d’une phrase. On peut comprendre ce que fait une automatisation en lisant son code, sans se souvenir que tel état interne correspond à tel événement physique.

Un point d’attention toutefois : les utilisateurs qui avaient activé ces fonctions en Labs avant leur sortie officielle peuvent être concernés par quelques renommages de clés. 

• battery.low devient battery.became_low, 
• battery.not_low devient battery.no_longer_low, 
• vacuum.docked devient vacuum.returned_to_dock, 
• lawn_mower.docked devient lawn_mower.returned_to_dock.

Rien de dramatique, mais ça vaut le coup de vérifier les automatisations créées avec l’ancienne version expérimentale. Pour les autres, aucun souci.

Une documentation beaucoup plus complète

Home Assistant a revu sa documentation. Des pages dédiées existent maintenant pour les déclencheurs, les conditions et les actions, avec utilisation depuis l’interface, exemple YAML et détails pratiques pour chaque élément.

C’est un vrai progrès. Beaucoup d’utilisateurs tombent encore sur des exemples de 2021 trouvés sur un forum ou dans une vieille vidéo YouTube. Avec ces nouvelles pages de référence, Home Assistant pose une base plus solide et plus à jour.

Ça aidera aussi les assistants IA, qui s’appuient encore souvent sur d’anciens modèles YAML pour générer des automatisations. Une documentation plus structurée devrait améliorer la fiabilité de ces suggestions avec le temps. Pas magiquement (une IA peut toujours inventer une entité qui n’existe pas) mais la base sera meilleure.

Le soleil gagne de nouveaux déclencheurs beaucoup plus précis

Les automatisations liées au soleil font partie des grands classiques : ouvrir les volets au lever, allumer les lampes au coucher, fermer les stores quand la luminosité baisse. Simple et très utilisé.

Jusqu’ici, les déclencheurs solaires étaient assez limités : lever du soleil, coucher du soleil, avec éventuellement un décalage en minutes. Le problème, c’est que « 30 minutes avant le coucher du soleil » ne donne pas le même résultat en juin et en décembre, et encore moins selon la météo ou votre latitude.

Home Assistant 2026.7 ajoute des notions plus fines : aube civile, nautique et astronomique, crépuscule, élévation du soleil, soleil montant ou descendant. Pour les mordus du peaufinage, c’est un régal.

Exemple concret : au lieu d’allumer les lampes extérieures 20 minutes avant le coucher du soleil – un réglage fixe qui marche mal en hiver et arrive trop tôt en été – vous déclenchez à partir d’un niveau d’élévation solaire. Le résultat colle mieux à la lumière réelle disponible.

Pour les conditions, c’est pareil. « Si le soleil est couché » ou « si le soleil est en train de descendre » s’écrivent directement, sans bricoler un template.

La lumière s’allume au bon moment, les volets se ferment plus naturellement, et personne ne se demande pourquoi la maison vit encore à l’heure d’hiver alors que le soleil tape plein pot.

Le journal d’activité devient enfin lisible

Le Logbook adopte une nouvelle présentation sous forme de timeline. Et c’est une belle amélioration.

L’ancien format listait les événements ligne par ligne. Utile, mais dans une installation avec des dizaines de capteurs et d’automatisations, retrouver la cause d’un événement précis pouvait vite devenir pénible.

La nouvelle timeline regroupe les événements par jour, avec une ligne verticale, des icônes et des couleurs d’état. Surtout, Home Assistant affiche maintenant la cause quand elle est connue : l’avatar de l’utilisateur qui a allumé une lumière, le nom de l’automatisation responsable, l’icône de l’intégration à l’origine de l’action.

Une lampe s’allume toute seule à 23 h 12 ? On ouvre la timeline, on remonte, on voit en quelques secondes si c’est une automatisation, une personne ou une intégration externe qui a déclenché l’action.

La timeline apparaît à plusieurs endroits : page Activité, fiche d’entité, page d’appareil, page de zone. Lors de la présentation, l’équipe montrait une version compacte directement dans la fenêtre d’une lumière, avec les changements d’état et leur origine. C’est beaucoup plus utile qu’un simple « on/off ».

La page des mises à jour devient plus pratique

La page des mises à jour a été refaite. Franchement, il était temps.

Quand on utilise Home Assistant avec Core, Supervisor, OS, HACS, ESPHome, plusieurs modules, des firmwares et quelques add-ons, la page des updates ressemblait à une petite lessive du dimanche. On clique, on attend, on clique encore, on redémarre, on recommence.

La nouvelle page regroupe les mises à jour par catégories. Home Assistant Core, l’OS et le Supervisor restent à part : ce sont les composants centraux, ceux qu’on veut mettre à jour délibérément. Les autres mises à jour sont regroupées par type : intégrations, apps, ESPHome, HACS, firmwares, etc. Et un bouton « Tout mettre à jour » permet de lancer toutes les mises à jour d’un groupe en une fois.

L’OS n’est pas mélangé avec le reste, pour éviter un redémarrage en plein milieu d’autres mises à jour. Home Assistant garde la tête froide là-dessus.

Pour les installations avec beaucoup d’appareils ESPHome, c’est un soulagement. Plus besoin de tout sélectionner manuellement un par un.

Les Raspberry Pi peuvent mettre à jour leur firmware plus facilement

Avec Home Assistant OS 18 ou plus récent, Home Assistant peut afficher une entité de mise à jour pour le firmware du Raspberry Pi : l’EEPROM, aussi appelé bootloader firmware.

Ce firmware bas niveau gère le démarrage, le stockage USB ou NVMe, et certaines fonctions matérielles. Sur Raspberry Pi 4 et surtout Pi 5, le maintenir à jour améliore la compatibilité et la stabilité.

Avant, mettre à jour ce firmware n’était pas une partie de plaisir. Il fallait parfois passer par une carte SD dédiée, un écran, un clavier ou une ligne de commande. Maintenant, ça se fait depuis Paramètres > Mises à jour, comme le reste.

Quelques limites à connaître. Il faut Home Assistant OS 18 minimum. Le Raspberry Pi 4 qui démarre depuis un stockage USB ne peut pas toujours en profiter. Le Home Assistant Yellow avec Compute Module 4 n’est pas concerné. En revanche, les Pi 4, Pi 5 et le Yellow avec Compute Module 5 sont dans la cible.

Après application, Home Assistant demande un redémarrage : comme pour un BIOS de PC, la nouvelle version n’est pas active avant reboot.

ZHA profite d’une vraie page de gestion Zigbee

La gestion avancée des appareils Zigbee via ZHA quitte la petite fenêtre compacte pour une page dédiée.

Les outils étaient là, mais serrés : clusters, bindings, signature, voisins, détails techniques. Tout dans une interface qui manquait de place pour respirer.

La version 2026.7 réorganise tout ça avec des onglets. Les informations restent les mêmes, mais elles sont plus lisibles.

Pour l’usage quotidien basique, ça ne change pas grand-chose. On peut très bien utiliser ZHA sans jamais fouiller les clusters Zigbee. Mais pour comprendre son maillage, vérifier les voisins d’un appareil ou créer des bindings directs entre équipements, c’est beaucoup plus agréable. Et pour diagnostiquer un capteur qui répond mal, une ampoule capricieuse ou un réseau maillé bancal, une interface claire fait gagner du temps.

Infrarouge et radio fréquence ont désormais leurs panneaux dédiés

Après Zigbee, Z-Wave, Thread et Matter, Home Assistant 2026.7 ajoute des panneaux dédiés pour les appareils infrarouges et radio fréquence.

Ces panneaux n’apparaissent dans les paramètres que si vous avez des équipements concernés : émetteurs, proxys ou passerelles IR/RF configurés.

Ça concerne les solutions ESPHome, les blasters infrarouges, les ponts RF 433 MHz, ou les intégrations capables de piloter des équipements sans retour d’état : climatisation, ampli audio, ventilateur, vieux store radio, prise 433 MHz. Tout ce petit monde a maintenant son coin dans l’interface.

L’infrarouge et le 433 MHz ont un côté « ancienne école », mais ils restent très présents dans les vraies installations. Les trouver rangés proprement, c’est une bonne chose.

Matter.js devient le nouveau moteur Matter par défaut

Ce point avait fait l’objet d’une annonce séparée, mais la présentation officielle de cette mise à jour y revient : le serveur Matter de Home Assistant utilise désormais Matter.js comme backend par défaut.

L’ancien serveur reposait sur l’implémentation Matter officielle en C/C++, avec une couche Python qui n’était pas vraiment conçue pour la production. Matter.js, développé en JavaScript/TypeScript et porté par l’Open Home Foundation, est une implémentation propre et indépendante, plus facile à faire évoluer.

Pour l’utilisateur, la migration est censée être transparente. Les appareils Matter restent appairés. La première migration peut prendre un peu plus de temps (des données sont converties en arrière-plan) mais l’objectif est de ne rien casser.

L’intérêt est surtout à moyen terme : meilleure prise en charge des nouveautés Matter, comportements mieux maîtrisés, et une implémentation indépendante qui aide à repérer les ambiguïtés dans la spec elle-même. Matter est prometteur, mais encore jeune, et il reste des coins flous dans le standard.

Des performances en hausse dans l’interface et les templates

Quelques optimisations discrètes mais utiles.

Le frontend charge plus vite, notamment les graphiques. C’est sensible sur les tableaux de bord énergie ou les historiques longs.

Les pages des appareils et des zones s’adaptent mieux aux différentes tailles d’écran, avec une disposition en colonnes plus propre. Sur tablette murale, mini PC ou smartphone, ce genre de détail compte.

Surtout : les templates sont annoncés comme environ 40 % plus rapides. Les templates sont partout dans les installations avancées (capteurs calculés, conditions, messages personnalisés, tableaux de bord). Un gain à ce niveau a un impact réel sur les grosses configurations.

Des formats de temps plus faciles à personnaliser

Les cartes affichant des dates ou des durées gagnent une option de format directement dans l’interface.

Avant, modifier l’affichage d’un timestamp demandait du YAML ou un capteur template. Maintenant, l’éditeur propose plusieurs formats : date, date et heure, relatif, long ou court.

Pour l’uptime d’un serveur, la dernière mise à jour d’un capteur ou la date de dernière synchronisation d’un appareil, on obtient un rendu lisible sans bricolage.

De nouvelles intégrations pour l’eau, l’énergie, la ventilation et plus encore

Dix nouvelles intégrations pour cette version : Aqvify (niveau d’eau dans un puits ou une cuve), Chef iQ (sondes de cuisson Bluetooth), Dropbox (sauvegardes), Edifier Infrared, energieleser (compteurs énergie, eau, gaz, chaleur), Envertech EVT800 (micro-onduleurs solaires), Greencell (bornes de recharge via MQTT), Helty Flow (unités de ventilation décentralisée), KlikAanKlikUit (équipements radio 433 MHz) et MELCloud Home (systèmes Mitsubishi Electric).

Plusieurs méritent qu’on s’y arrête.

Dropbox comme destination de sauvegarde, c’est une option simple pour ceux qui veulent externaliser leurs backups sans infrastructure compliquée. Les sauvegardes Home Assistant sont précieuses : quand une carte SD lâche ou qu’un mini PC décide de partir en vacances définitives, une sauvegarde récente peut sauver la journée.

Côté énergie, Envertech EVT800, Greencell, energieleser et Hypontech Cloud renforcent encore la position de Home Assistant comme centrale de suivi énergétique. Solaire, recharge véhicule électrique, consommation, batterie, réseau : les briques s’accumulent.

Helty Flow est intéressant pour la ventilation décentralisée, un sujet récurrent dans les maisons bien isolées. Pouvoir contrôler ça localement, sans dépendance permanente au cloud, c’est le genre de détail qui compte.

Des intégrations existantes qui progressent aussi

Les nouveautés ne se limitent pas aux nouvelles intégrations.

Alexa Devices peut maintenant gérer des listes de tâches et de courses Alexa dans Home Assistant, et ajoute des interrupteurs pour contrôler les annonces et communications sur les appareils Echo.

SMTP gagne des entités de notification modernes pour envoyer des emails depuis Home Assistant – utile pour des alertes importantes : fuite d’eau, coupure secteur, alarme, batterie faible critique, dépassement de consommation.

Overkiz prend en charge Rexel Energeasy Connect via cloud et API locale, un point intéressant pour les installations françaises. Tesla Powerwall prend en charge le Powerwall 3 et ajoute des capteurs liés au mode de fonctionnement ainsi qu’aux puissances maximales de charge et décharge.

Yoto progresse fortement : navigateur média, nouveaux capteurs, capteurs binaires, entité temps, réglages de luminosité d’écran et de volume maximal. Les parents qui utilisent ces petits lecteurs audio pour enfants apprécieront.

Côté piscine, Vistapool gagne de nombreuses entités supplémentaires pour des scénarios plus précis autour du traitement, de l’éclairage et du pilotage. Et comme la piscine connectée est un terrain de jeu sympa en été, on ne va pas bouder.

Enfin, on notera l’ajout de la possibilité d’envoyer des images au tableau SwitchBot AI Art Frame que nous avions testé il y a quelques temps, ce qui va permettre des interactions beaucoup plus sympa avec ce superbe cadre :)

Un grand ménage dans les intégrations abandonnées

Home Assistant 2026.7 supprime aussi une série d’intégrations devenues inutilisables : cassées depuis des années, dépendantes de services fermés, de bibliothèques abandonnées ou de matériels disparus.

Acer Projector, Ampio Smog, Avi-on, BeeWi SmartClim, Clementine, Dovado, ELIQ Online, Microsoft Face, MS Teams, Mycroft, UniFi LED, Watson TTS et d’autres sont retirés.

Ce genre de nettoyage peut sembler abrupt. Mais une intégration cassée depuis 2019 n’aide personne. Elle complique la maintenance, alourdit le projet et donne de faux espoirs à ceux qui tentent de l’utiliser.

Faut-il installer Home Assistant 2026.7 ?

Oui. C’est une des mises à jour importantes de l’année.

Les nouvelles automatisations rendent Home Assistant plus accessible sans sacrifier la puissance qui plaît aux utilisateurs avancés. Le journal d’activité est enfin lisible. La page des mises à jour est moins pénible. ZHA s’améliore. Les Raspberry Pi gagnent une gestion de firmware directement dans l’interface. Les intégrations continuent de s’étoffer. Et les performances progressent par petites touches.

C’est une version qui améliore le fond plutôt que d’empiler des appareils compatibles.

Pour les débutants, c’est une meilleure porte d’entrée : créer une automatisation devient plus logique, plus proche de la façon dont on réfléchit. Pour les habitués, c’est l’occasion de revisiter certaines vieilles automatisations : pas une obligation, mais le nouveau modèle est plus propre et plus maintenable. Pour les installateurs, c’est un pas de plus vers des installations que le client peut comprendre, voire modifier lui-même sans appeler à l’aide.

La domotique n’a jamais été aussi puissante. Elle devient aussi un peu moins intimidante. Ce n’était pas le point le plus urgent il y a cinq ans. Aujourd’hui, c’est probablement ce qui compte le plus pour qu’elle s’installe vraiment dans les maisons.