Home Assistant et HomeKit sans doublons ni scènes cassées

Home Assistant et HomeKit cohabitent très bien quand vous décidez d’abord qui commande quoi. Le problème vient rarement de la compatibilité pure. Il vient plutôt d’une architecture bricolée trop vite : un accessoire appairé au mauvais endroit, une entité exposée deux fois, une automatisation Apple qui double une automatisation Home Assistant, puis une maison qui répond de façon imprévisible.

Mon verdict est simple : gardez Home Assistant comme cerveau dès que l’installation dépasse quelques accessoires Apple, puis exposez seulement ce qui doit rester confortable dans l’app Maison. À l’inverse, importez un accessoire HomeKit dans HA uniquement si vous avez besoin de ses capteurs, de ses états ou de ses actions dans vos automatisations avancées. Le reste, c’est de la dette de configuration qui revient au premier redémarrage, au premier changement de routeur ou au premier membre du foyer qui déclenche la mauvaise scène.

Le point de départ : choisir le sens du flux

Le mot “HomeKit” est piégeux dans Home Assistant parce qu’il recouvre deux mouvements opposés. Dans un sens, vous prenez un accessoire prévu pour Apple Home et vous le faites entrer dans Home Assistant. Dans l’autre, vous prenez des entités déjà gérées par Home Assistant et vous les rendez visibles dans Apple Home.

Ces deux mouvements peuvent exister dans la même maison. Ils ne doivent pas être appliqués au même objet sans raison. Si une lampe Zigbee remonte déjà dans Home Assistant via ZHA ou Zigbee2MQTT, l’exposer ensuite à Apple Home via Bridge est logique. Essayer de la récupérer aussi comme accessoire HomeKit direct est une bonne façon de créer un doublon inutile.

Décidez donc le flux avant le pairing. C’est le seul moment où le choix reste simple et réversible.

Architecture

Les deux chemins à ne pas mélanger

Même vocabulaire HomeKit, mais conséquences différentes sur le contrôle, les scènes et le dépannage.

HomeKit Device

Un accessoire HomeKit est appairé à Home Assistant. HA devient le contrôleur utile pour l’automatisation.

HomeKit Bridge

Home Assistant publie une sélection d’entités vers Apple Home pour Siri et l’app Maison.

HomeKit Device : quand faire entrer l’accessoire dans Home Assistant

HomeKit Device, ancien réflexe souvent appelé HomeKit Controller dans les discussions, sert à contrôler depuis Home Assistant un appareil compatible HomeKit. Le cas typique : un capteur, une prise, une serrure ou un pont d’origine Apple Home que vous voulez exploiter dans vos automatisations HA, avec ses états disponibles dans les déclencheurs et conditions.

Ce choix a du sens si vous voulez croiser cet accessoire avec du Zigbee, du Z-Wave, du MQTT, une présence réseau, une météo locale ou un script plus fin que ce que l’app Maison permet. Dans ce cas, l’accessoire ne doit pas seulement “apparaître” dans une interface. Il doit devenir une vraie source d’état dans Home Assistant.

La contrainte, c’est le pairing. Beaucoup d’accessoires HomeKit n’aiment pas être contrôlés partout à la fois. Il faut parfois les retirer proprement de l’app Maison, réinitialiser l’appairage, puis les associer à Home Assistant. Ne faites pas ça un dimanche soir si l’accessoire pilote un accès, du chauffage ou un volet critique.

Testez d’abord sur un objet sans enjeu. Une prise de bureau vaut mieux qu’un volet ou une serrure.

HomeKit Bridge : quand exposer Home Assistant vers Apple Home

HomeKit Bridge fait l’inverse. Home Assistant reste le système qui connaît vos entités, vos automatisations et vos intégrations. Il publie ensuite une sélection vers Apple Home pour que le foyer puisse piloter facilement les lumières, volets, prises, thermostats ou capteurs simples depuis l’iPhone, Siri ou un HomePod.

C’est souvent l’architecture la plus saine. Elle garde la logique avancée côté HA et la convivialité côté Apple. Dans mon installation, je ne publierais pas tous les capteurs, tous les helpers et toutes les scènes. Je publierais seulement ce que quelqu’un peut légitimement vouloir actionner ou consulter sans ouvrir le dashboard HA.

Le filtrage est obligatoire. Un bridge qui expose 180 entités devient vite illisible dans Maison. Pire, il peut pousser des objets techniques que personne ne doit manipuler, comme des helpers, des switches internes, des modes de scripts ou des capteurs de diagnostic.

Moins d’entités, moins d’ambiguïté. C’est rarement le nombre qui rend Apple Home utile.

Ce que je filtre systématiquement dans HomeKit Bridge

Je commence toujours par une liste courte. Les lumières principales, les volets, quelques prises pilotées et deux ou trois capteurs vraiment consultés par le foyer suffisent souvent. Les entités qui existent seulement pour faire fonctionner une automation Home Assistant restent dans Home Assistant. Un helper, un input boolean de mode absence ou un switch de script n’a rien à faire dans l’app Maison si personne ne comprend son effet réel.

Le bon filtre ne cherche pas à montrer que l’installation est riche. Il cherche à rendre les commandes utiles disponibles en deux secondes. Si votre conjoint, vos enfants ou vos invités voient vingt objets incompréhensibles dans une pièce, le bridge a raté son rôle. Apple Home doit rester une télécommande lisible, pas une copie miniature de votre registre d’entités HA.

Mon seuil personnel est brutal : si une entité ne peut pas être expliquée en une phrase simple, je ne l’expose pas.

• à exposer : lampes, volets, prises visibles, scènes très simples, température lisible ;
• à garder dans HA : helpers, capteurs de batterie, switches internes, diagnostics, scripts techniques ;
• à discuter au cas par cas : serrures, alarmes, thermostats, portails et commandes irréversibles ;
• à éviter : doublons d’un même appareil déjà présent nativement dans Apple Home.

Ma règle de câblage logique

Si l’objet est piloté par une intégration native Home Assistant stable, laissez-le dans Home Assistant et exposez-le via Bridge si nécessaire. Si l’objet n’existe que comme accessoire HomeKit et que vous avez besoin de ses états dans HA, utilisez HomeKit Device. Si vous n’avez besoin que d’un contrôle familial simple, gardez-le dans Apple Home. Ce raisonnement évite de juger par marque et force à juger par responsabilité technique.

Cette règle évite 80 % des configurations absurdes. Elle empêche aussi de confondre interface et autorité. Apple Home peut être très agréable au quotidien sans devenir le système qui décide de tout. Home Assistant peut rester puissant sans imposer son dashboard à toute la famille.

Le compromis le plus robuste ressemble à ça : HA orchestre, Apple Home présente, les accessoires critiques ont un seul maître logique.

Les erreurs qui cassent vraiment la cohabitation

La première erreur consiste à exposer toute l’instance Home Assistant vers Apple Home. C’est tentant, parce que le bridge sait publier beaucoup de domaines. En pratique, c’est du bruit. Vous vous retrouvez avec des capteurs de batterie, des entités de diagnostic et des switches internes dans une app censée rester familiale.

La deuxième erreur est de garder deux scènes concurrentes. Exemple classique : une scène “soirée” dans Apple Home et une automation “soirée” dans HA qui touchent les mêmes lampes. Quand le résultat diverge, vous ne savez plus quelle couche a gagné. Un système domotique stable a besoin d’une source de vérité, pas de deux chefs qui parlent en même temps. Si vous tenez absolument à garder une scène Apple pour Siri, faites-la déclencher une action simple et laissez HA gérer la logique détaillée.

La troisième erreur est de migrer un accessoire HomeKit sans noter son état initial. Avant de retirer un accessoire de Maison, capturez son code, son nom, sa pièce, ses automatisations dépendantes et son rôle. Cinq minutes de notes valent mieux qu’une heure à reconstruire des scènes à l’aveugle.

Le code d’appairage est une sauvegarde, pas un détail. Sans lui, le rollback devient inutilement pénible.

La quatrième erreur est plus sournoise : changer trois couches en même temps. Vous mettez à jour Home Assistant, vous bougez un VLAN, puis vous réappairez un accessoire HomeKit. Si quelque chose casse, le diagnostic devient flou. Sur ce type de pile, je préfère une seule variable à la fois : d’abord le réseau, ensuite le bridge, ensuite l’accessoire.

Le réseau : mDNS, VLAN et Wi-Fi invité avant les incantations

Quand Home Assistant ne voit pas un accessoire HomeKit ou quand Apple Home ne retrouve pas le bridge, commencez par le réseau. HomeKit et la découverte locale reposent beaucoup sur la visibilité entre appareils. Si votre serveur HA est sur un VLAN, votre iPhone sur un autre, et vos objets sur un Wi-Fi invité, la découverte mDNS peut être cassée même si Internet fonctionne.

Vérifiez aussi les évidences : même réseau local, pas d’isolation client, pare-feu qui laisse passer le multicast local, IPv6 cohérent si votre réseau l’utilise, redémarrage propre du bridge après modification. Sur une installation UniFi, Omada, pfSense ou OpenWrt, le problème vient souvent d’un réglage de multicast ou d’un filtrage trop ambitieux.

Ne réinitialisez pas l’accessoire tant que le réseau n’est pas propre. Vous risqueriez de supprimer la mauvaise preuve.

Le test propre avant de toucher aux accessoires critiques

Un test utile doit être reproductible. Créez d’abord un bridge HomeKit limité à une seule lumière ou une prise sans enjeu. Ajoutez-le dans Apple Home, testez la commande depuis l’app Maison, puis depuis Siri si vous l’utilisez. Ensuite, modifiez l’état depuis Home Assistant et vérifiez que le retour d’état arrive correctement côté Apple. Ce petit protocole isole le bridge avant de mélanger scènes, droits du foyer et accessoires plus sensibles.

Si ce mini-scenario fonctionne, votre base Bridge est saine. Si ce mini-scenario échoue, inutile d’ajouter vingt entités de plus. Vous avez un problème de découverte, de réseau, de configuration ou de droits côté foyer Apple. Cette approche lente paraît moins brillante qu’une migration complète, mais elle évite de casser les objets critiques avant même d’avoir validé le chemin technique.

Je fais la même chose pour HomeKit Device. Un accessoire peu risqué d’abord, puis observation pendant une journée. La stabilité sur cinq minutes ne suffit pas. Il faut voir le retour d’état, la latence, le comportement après redémarrage de HA et la réaction quand le Wi-Fi ou le routeur redémarre.

Fin de migration

Deux contrôles avant de valider

La réussite ne se mesure pas seulement au premier appairage.

Rollback prêt

Codes, scènes, noms et dépendances doivent être notés avant migration.

Réseau validé

Le bridge et les accessoires doivent rester visibles après redémarrage du routeur et de Home Assistant.

Plan de migration sans se piéger

Pour une migration propre, commencez petit. Prenez une lampe ou un capteur non critique. Faites entrer ou sortir cette entité selon le flux choisi. Testez l’état, la commande, le délai de réaction et l’exposition dans Apple Home. Ensuite seulement, appliquez la méthode aux volets, serrures, thermostats ou scènes qui ont un vrai impact quotidien.

Je garde toujours un plan de rollback. Il contient le code d’appairage, les captures de scènes Apple, la liste des automatisations HA qui dépendent de l’entité et le nom exact utilisé avant migration. Ce n’est pas excessif. C’est ce qui évite de transformer une amélioration de confort en session de réparation.

Le rollback doit aussi préciser ce qui ne sera pas migré. Dans une maison réelle, tout ne mérite pas d’être repris. Certains anciens accessoires peuvent rester dans Apple Home jusqu’à leur remplacement, surtout s’ils sont stables et peu utilisés dans les scénarios HA. Une architecture propre n’est pas forcément une architecture puriste ; c’est une architecture dont vous pouvez expliquer le fonctionnement sans ouvrir trois forums, sans fouiller un ancien fil Reddit et sans espérer que la prochaine mise à jour ne révèle pas une dépendance oubliée.

Faut-il exposer les serrures, alarmes et thermostats ?

Je serais plus strict avec les entités sensibles. Une lumière exposée deux fois est pénible. Une serrure, une alarme ou un thermostat exposé trop largement peut devenir un vrai problème d’usage. Pour ces objets, je limite les commandes, je teste les droits dans le foyer Apple, et je garde les automatismes critiques dans la couche que je maîtrise le mieux. Le confort vocal ne justifie pas de rendre flou le contrôle d’un accès ou d’un chauffage.

Le thermostat mérite une attention particulière. Si Apple Home applique une consigne, Home Assistant une autre, et l’intégration fabricant une troisième, vous allez déboguer du confort avec trois horloges différentes. Dans ce cas, définissez le contrôleur prioritaire et laissez les autres interfaces demander, pas décider.

Mon verdict

Pour une maison un peu avancée, je recommande Home Assistant comme base technique et Apple Home comme interface de confort. Utilisez HomeKit Bridge pour publier une sélection courte et lisible. Utilisez HomeKit Device seulement quand un accessoire HomeKit doit vraiment rejoindre vos automatisations HA.

Ce n’est pas le montage le plus spectaculaire. C’est le plus maintenable, et c’est exactement ce qu’on demande à une maison connectée.