15/02/2026, 11:46:31
Bonjour,
Si l’objectif est simplement d’héberger Home Assistant, la solution la plus fiable et la plus simple reste Home Assistant OS (HAOS) installé directement sur la machine.
Un cluster Proxmox en haute disponibilité est une bonne approche lorsqu’on veut mutualiser plusieurs services (NAS, VM diverses, conteneurs, lab, etc.) ou mettre en place une infrastructure complète. Mais pour un usage dédié uniquement à Home Assistant, cela ajoute de la complexité inutile : gestion du cluster, stockage partagé, supervision, mises à jour multiple. Chaque couche logicielle supplémentaire introduit de nouveaux points de défaillance potentiels.
Et en informatique, une règle simple s’applique souvent : plus il y a de logiciels, plus il y a de risques de bugs, de conflits ou de problèmes de maintenance.
Le NUC dédié exclusivement à Home Assistant avec une installation directe de HAOS reste la solution la plus simple, la plus lisible et souvent la plus fiable sur le long terme.
Il n’y a pas de couche d’hyperviseur, pas d’abstraction matérielle supplémentaire, pas de ressources consommées par un système hôte intermédiaire. À matériel équivalent, l’exécution sera donc plus directe, avec :
J’ai utilisé Proxmox pendant plusieurs années mais j’ai connu un plantage alors que j’étais absent. Le problème (clairement identifié à postériori) venait d’une incompatibilité entre Proxmox et la carte réseau Intel du NUC (driver / version kernel) avec pour conséquence plus d’accès distant et une intervention physique obligatoire.
Fait notable, l’incident ne s’est pas produit immédiatement après la mise à jour : le dysfonctionnement est apparu plusieurs heures plus tard, rendant le diagnostic initial moins évident. La conséquence a été une perte totale d’accès distant, nécessitant une intervention physique sur site.
Ce n’était pas un défaut de conception de Proxmox en soi, mais un exemple typique de ce que peut engendrer l’ajout de couches logicielles supplémentaires : dépendances matérielles, drivers, versions de noyau, mises à jour sensibles…
Avec le temps je suis revenu à une approche plus simple et plus pragmatique. Quand on investit plusieurs milliers d’euros dans une installation domotique KNX, sacrifier 200 € pour un NUC dédié n’est pas vraiment un sujet. D’autant plus qu’aujourd’hui, certains mini-PC ont des consommations très faibles (souvent entre 6 et 15 W en usage réel), ce qui rend l’impact énergétique quasi négligeable à l’échelle d’une installation complète.
Dans mon cas, la disponibilité et la surveillance à distance sont primordiales. Je dispose d’une source sous la maison avec des pompes de relevage : en cas de défaillance, c’est l’inondation assurée du sous-sol.
Même si l’installation est sécurisée par un onduleur (Victron) et des batteries (300 Ah) avec une gestion full KNX du pompage, j’ai besoin de garder une visibilité permanente sur l’état des équipements : niveau d’eau, fonctionnement des pompes, alertes.
En cas de coupure secteur générale (foudre, etc.) lors d'une absence prolongée, même si l’installation dispose de plusieurs heures d’autonomie, cela me laisse le temps de faire intervenir une personne sur place pour réarmer un disjoncteur si nécessaire.
Ceinture et bretelles !
Afin d’assurer la continuité de service, j’ai mis en place un second NUC de secours. Il reste normalement hors tension ; il est alimenté lors des absences prolongées. Cette architecture répond à deux objectifs principaux :
1) Prise de relais en cas de défaillance du NUC principal : Home Assistant effectue une requête vers le service StatusCake toutes les 5 minutes. Si le NUC principal ou Home Assistant cesse de répondre, StatusCake détecte l’absence et une alerte email est envoyée. J’ouvre à distance le port du routeur UniFi auquel est connecté le NUC de secours, qui peut alors prendre le relais. Cette activation manuelle est nécessaire, notamment parce que Nabu Casa impose qu’une seule instance Home Assistant soit active sur le réseau à un instant donné.
2) Sauvegarde matérielle complète et indépendante : Ce second NUC représente une véritable sauvegarde matérielle complète. Contrairement aux solutions de sauvegarde cloud ou NAS, qui restent dépendantes d’un matériel opérationnel pour pouvoir être restaurées, cette architecture permet une reprise rapide en cas de panne totale du NUC principal.
Par ailleurs, le NUC de secours est mis à jour tous les quinze jours (restauration d'une sauvegarde complète du NUC principal). Ce décalage volontaire par rapport au NUC principal constitue une sécurité supplémentaire : en cas de problème lié à une mise à jour récente sur l’équipement principal, le NUC secondaire reste sur une version antérieure stable et peut ainsi prendre le relais immédiatement.
Cette approche assure non seulement la continuité de service, mais apporte également une réelle résilience matérielle et logicielle.
Avec le recul et l'expérience, vouloir absolument intégrer Proxmox relevait peut-être davantage du défi technique que du réel besoin opérationnel. Dans un contexte où la priorité est la fiabilité et la simplicité, ajouter une couche d’hyperviseur a surtout introduit de la complexité supplémentaire.
Parfois, la solution la plus élégante… est simplement la plus simple.
Mais ce n’est que mon avis… et je le partage....en détails !
Si l’objectif est simplement d’héberger Home Assistant, la solution la plus fiable et la plus simple reste Home Assistant OS (HAOS) installé directement sur la machine.
Un cluster Proxmox en haute disponibilité est une bonne approche lorsqu’on veut mutualiser plusieurs services (NAS, VM diverses, conteneurs, lab, etc.) ou mettre en place une infrastructure complète. Mais pour un usage dédié uniquement à Home Assistant, cela ajoute de la complexité inutile : gestion du cluster, stockage partagé, supervision, mises à jour multiple. Chaque couche logicielle supplémentaire introduit de nouveaux points de défaillance potentiels.
Et en informatique, une règle simple s’applique souvent : plus il y a de logiciels, plus il y a de risques de bugs, de conflits ou de problèmes de maintenance.
Le NUC dédié exclusivement à Home Assistant avec une installation directe de HAOS reste la solution la plus simple, la plus lisible et souvent la plus fiable sur le long terme.
- une mise en œuvre rapide ;
- une maintenance simplifiée ;
- des mises à jour centralisées ;
- une stabilité éprouvée.
Il n’y a pas de couche d’hyperviseur, pas d’abstraction matérielle supplémentaire, pas de ressources consommées par un système hôte intermédiaire. À matériel équivalent, l’exécution sera donc plus directe, avec :
- moins d’overhead CPU
- moins de consommation mémoire
- des accès disque et réseau plus rapides
- une latence globale réduite
J’ai utilisé Proxmox pendant plusieurs années mais j’ai connu un plantage alors que j’étais absent. Le problème (clairement identifié à postériori) venait d’une incompatibilité entre Proxmox et la carte réseau Intel du NUC (driver / version kernel) avec pour conséquence plus d’accès distant et une intervention physique obligatoire.
Fait notable, l’incident ne s’est pas produit immédiatement après la mise à jour : le dysfonctionnement est apparu plusieurs heures plus tard, rendant le diagnostic initial moins évident. La conséquence a été une perte totale d’accès distant, nécessitant une intervention physique sur site.
Ce n’était pas un défaut de conception de Proxmox en soi, mais un exemple typique de ce que peut engendrer l’ajout de couches logicielles supplémentaires : dépendances matérielles, drivers, versions de noyau, mises à jour sensibles…
Avec le temps je suis revenu à une approche plus simple et plus pragmatique. Quand on investit plusieurs milliers d’euros dans une installation domotique KNX, sacrifier 200 € pour un NUC dédié n’est pas vraiment un sujet. D’autant plus qu’aujourd’hui, certains mini-PC ont des consommations très faibles (souvent entre 6 et 15 W en usage réel), ce qui rend l’impact énergétique quasi négligeable à l’échelle d’une installation complète.
Dans mon cas, la disponibilité et la surveillance à distance sont primordiales. Je dispose d’une source sous la maison avec des pompes de relevage : en cas de défaillance, c’est l’inondation assurée du sous-sol.
Même si l’installation est sécurisée par un onduleur (Victron) et des batteries (300 Ah) avec une gestion full KNX du pompage, j’ai besoin de garder une visibilité permanente sur l’état des équipements : niveau d’eau, fonctionnement des pompes, alertes.
En cas de coupure secteur générale (foudre, etc.) lors d'une absence prolongée, même si l’installation dispose de plusieurs heures d’autonomie, cela me laisse le temps de faire intervenir une personne sur place pour réarmer un disjoncteur si nécessaire.
Ceinture et bretelles !
Afin d’assurer la continuité de service, j’ai mis en place un second NUC de secours. Il reste normalement hors tension ; il est alimenté lors des absences prolongées. Cette architecture répond à deux objectifs principaux :
1) Prise de relais en cas de défaillance du NUC principal : Home Assistant effectue une requête vers le service StatusCake toutes les 5 minutes. Si le NUC principal ou Home Assistant cesse de répondre, StatusCake détecte l’absence et une alerte email est envoyée. J’ouvre à distance le port du routeur UniFi auquel est connecté le NUC de secours, qui peut alors prendre le relais. Cette activation manuelle est nécessaire, notamment parce que Nabu Casa impose qu’une seule instance Home Assistant soit active sur le réseau à un instant donné.
2) Sauvegarde matérielle complète et indépendante : Ce second NUC représente une véritable sauvegarde matérielle complète. Contrairement aux solutions de sauvegarde cloud ou NAS, qui restent dépendantes d’un matériel opérationnel pour pouvoir être restaurées, cette architecture permet une reprise rapide en cas de panne totale du NUC principal.
Par ailleurs, le NUC de secours est mis à jour tous les quinze jours (restauration d'une sauvegarde complète du NUC principal). Ce décalage volontaire par rapport au NUC principal constitue une sécurité supplémentaire : en cas de problème lié à une mise à jour récente sur l’équipement principal, le NUC secondaire reste sur une version antérieure stable et peut ainsi prendre le relais immédiatement.
Cette approche assure non seulement la continuité de service, mais apporte également une réelle résilience matérielle et logicielle.
Avec le recul et l'expérience, vouloir absolument intégrer Proxmox relevait peut-être davantage du défi technique que du réel besoin opérationnel. Dans un contexte où la priorité est la fiabilité et la simplicité, ajouter une couche d’hyperviseur a surtout introduit de la complexité supplémentaire.
Parfois, la solution la plus élégante… est simplement la plus simple.
Mais ce n’est que mon avis… et je le partage....en détails !