Mon Test Home Assistant (Hass.io)

[jojo]

@sebcbien un revenant ? 

j'y pense, voudrais-tu  un second Gen 8, (celui sur leque tu as installé un super processeur) ?

[MAM78]

Bonjour la communauté.

 

Tout d'abord commençons par l'essentiel, tous mes voeux pour cette nouvelle année 2026.

 

Comme indiqué, l'année dernière, j'ai 2 domiciles (maison et appartement) à intégrer sur Home Assistant et je me pose des question sur l'architecture de ma solution.

• Soit je crée 2 instances HA, une sur chaque domicile et j'utilise remote_homeassistant pour remonter les Devices de l'instance HA Appartement dans l'instance HA Maison.
• Soit je crée un cluster des mes 2 VMs HA et y intégrer tous les Devices afin de manager qu'une instance HA. 

L'objectif serait de pouvoir contrôler les 2 domiciles depuis une seule instance.

 

Sachant que pour la deuxième solution je garderais une gestion des scénarios en local sur chaque instance pour limiter les échanges entre les instances.

 

Qu'est ce que vous en pensez ?

 

[MAM78]

J'ai posé la question à mon IA GitHub Copilot. Voici-ci sa réponse qui me semble plutôt pertinente. Vous en pensez quoi ?
 

Je te conseille de rester sur deux instances HA séparées (une par site) et de consommer l’appartement via remote_homeassistant depuis l’instance “Maison”. HA n’a pas de vrai cluster multi-site actif/actif ; forcer une “instance unique” répartie sur deux sites apporte plus de fragilité et de latence.

Pourquoi 2 instances + remote_homeassistant :

• Résilience locale : les automatismes critiques (chauffage, sécurité, éclairage) restent opérationnels si le lien inter-sites tombe.
• Latence maîtrisée : chaque site parle à ses devices en LAN ; les commandes distantes peuvent être un peu plus lentes mais ne bloquent pas le local.
• Isolement pannes / mises à jour : tu peux redémarrer/mise à jour un site sans impacter l’autre.
• Simplicité Alexa/voix : deux comptes Alexa séparés, exposition filtrée par site, pas de collisions de pièces (“Salon”).
• Vue unifiée : remote_homeassistant t’apporte les entités distantes préfixées (apt_…) dans l’instance “Maison” pour superviser/piloter.

Ce que donnerait la voie “instance unique/cluster” :

• HA ne supporte pas nativement un cluster multi-site synchrone. Tu te retrouverais à bricoler du partage d’état, avec risques de doublons, latence sur les commandes, et une dépendance forte au réseau inter-sites.
• Les automatismes locaux deviendraient dépendants du lien WAN/VPN, ce qui est risqué pour chauffage/sécurité.
• La charge de maintenance et de debug augmenterait (entités dupliquées, préfixage, cohérence des états).

Bonnes pratiques si tu pars sur 2 instances + remote_homeassistant :

• Garder les automatismes critiques sur chaque site.
• Préfixer les entités importées (ex. apt_) et filtrer ce que tu importes (domains/entités utiles).
• VPN entre sites pour la sécurité et la stabilité (sinon HTTPS + IP filtrées).
• Dashboards : deux vues (Maison local, Appartement préfixé) + barre de nav ; ou deux dashboards distincts.
• Alexa : un compte par site, n’expose que les entités du site ; n’expose pas les entités importées pour éviter les interférences.

[MAM78]

Ca pourrait donner cette archi.

Vous en pensez quoi, notamment en matière de sécurité ?

 

 

Modifié vendredi à 22:44 par MAM78

[Nico]

Quel intérêt de mettre le tout dans la même instance ?

On ne peut pas switcher d'un local à un autre sur HA au niveau appli, et du coup mettre 2 HAs, un par site ?

[MAM78]

C'est bien le principe de l'archi présentée ci-dessus. 2 instances distinctes mais avec quelques éléments mis en commun pour piloter les 2 habitations depuis des Dashboard commun depuis l'application HA et pouvoir recevoir par exemple des notifications via l'application.

Si l'on prend l'exemple de l'application Fibaro Yubii Home, une fois connecté sur une HC3, je ne suis pas certain que tu puisses recevoir des notifications d'une autres HC3.

Modifié samedi à 10:38 par MAM78