Comment dimensionner un serveur domestique pour Home Assistant et les pannes d’Internet

Dimensionnez le chemin de contrôle local protégé, et pas seulement le processus Home Assistant, en fonction des coupures d’Internet et de courant précises auxquelles votre foyer doit résister.

Dans un logement où l’éclairage, la température, la détection des fuites ou les automatismes d’accès sont importants en cas de perturbation, le serveur n’est qu’un élément parmi d’autres. La commutation locale, le Wi-Fi ou les coordinateurs radio, le stockage persistant, l’alimentation par batterie et une configuration récupérable doivent rester coordonnés. La conception n’est plus prête à résister aux pannes dès qu’une API cloud requise, un routeur non protégé ou un comportement de redémarrage inconnu interrompt le flux de travail avant que la capacité de calcul ne devienne un problème.

Définissez le niveau de fonctionnement attendu en cas de panne

Distinguez une panne du fournisseur d’accès à Internet d’une coupure de courant. En cas de perte de la connexion Internet, le réseau local peut rester opérationnel et les appareils locaux peuvent continuer à communiquer. En cas de coupure de courant, l’hôte, le routeur, les commutateurs réseau, les points d’accès, les coordinateurs, le NAS et les actionneurs peuvent tomber en panne simultanément. Définissez pour chaque événement sa durée et le niveau de dégradation acceptable.

Une discussion communautaire sur la préparation aux coupures de courant distingue le contrôle local des appareils de la question plus large de ce qui reste alimenté. Cette incertitude constitue le bon point de départ : dressez la liste des actions critiques, de leurs dépendances réseau et cloud, ainsi que de la solution de secours manuelle. Une exigence générique consistant à « garder Home Assistant en ligne » est trop limitée pour dimensionner la topologie.

Classez chaque flux de travail selon qu’il doit continuer, peut fonctionner en mode dégradé ou peut s’arrêter sans risque. Une vanne anti-fuite et une protection du chauffage peuvent être prioritaires sur les graphiques d’historique, les notifications à distance et les requêtes vocales. La configuration protégée ne nécessite de la capacité que pour les fonctions qui doivent continuer, avec une marge de reprise ; les tâches facultatives peuvent être suspendues ou déplacées hors de l’hôte critique.

Dimensionnez la puissance de calcul en fonction de la charge de travail critique

Mesurez la charge de travail des automatismes essentiels, avec le WAN déconnecté et la séquence d’événements locaux la plus intense en cours d’exécution. Relevez l’utilisation soutenue et maximale du processeur, la pression sur la mémoire, le temps d’attente du stockage et la latence des réponses. Incluez la base de données et uniquement les modules complémentaires requis pour les actions protégées. Vous obtenez ainsi une référence serveur liée aux services, et non au nombre d’appareils.

Gardez les modèles vocaux locaux, l’inférence des caméras, le traitement multimédia et la compression des sauvegardes hors du chemin protégé, sauf si l’exigence de fonctionnement pendant une panne les inclut explicitement. S’ils partagent le même hôte, définissez des limites de ressources ou une planification et reproduisez leur chevauchement maximal. Ne séparez un service que si son pic de charge fait manquer à une action critique son objectif d’acceptation.

Prévoyez une marge pour les mises à jour, la maintenance de l’enregistreur et l’évolution, sans pour autant choisir une catégorie de processeur arbitrairement plus élevée. Un hôte est suffisamment puissant lorsque la séquence critique mesurée reste réactive et que le comportement au redémarrage est prévisible. Il est surdimensionné pour son rôle actuel si la capacité inutilisée augmente la consommation au repos et la charge de l’onduleur sans réduire un risque de panne identifié.

Construire un chemin d’alimentation et de réseau protégé

Tracez un seul parcours du capteur ou du tableau de bord jusqu’à l’actionneur, en passant par la radio ou le Wi-Fi, la commutation locale et Home Assistant. Raccordez chaque composant réseau indispensable et l’hôte à un circuit protégé par onduleur et dont la charge a été mesurée. Une batterie sur le seul serveur ne peut pas maintenir le contrôle si le routeur, le commutateur, le point d’accès ou le coordinateur perd son alimentation.

Un opérateur décrit la protection du matériel réseau, du stockage et du serveur Home Assistant à l’aide de petits onduleurs, avec arrêt des serveurs en quelques minutes et maintien plus long du matériel réseau. Les durées dépendent de l’installation, mais la répartition des rôles est judicieuse : les machines de calcul peuvent s’arrêter en toute sécurité tandis que le chemin de communication local reste opérationnel.

Mesurez la charge totale sur les prises, choisissez une autonomie cible et testez-la en conditions normales de pointe. Définissez si l’hôte doit rester alimenté, s’arrêter proprement ou redémarrer au retour du courant. Rejetez toute conception incapable de récupérer lorsque le courant revient alors que l’onduleur est encore chargé, car ce cas particulier peut laisser un service hors ligne malgré une batterie en bon état.

Featured

ZimaBoard 2 - Mini-serveur domestique pour vos grandes idées

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Séparer l’état actif des copies de récupération

Conservez la configuration et la base de données active de l’enregistreur sur un stockage persistant surveillé qui démarre avec l’hôte protégé. Placez les copies de récupération sur une destination distincte dont la perte n’empêche pas le démarrage de l’automatisation locale. Un NAS peut être une cible de sauvegarde efficace, mais il ne doit pas devenir par inadvertance un prérequis pour le service essentiel.

Un scénario de panne rapporté concernant Home Assistant et Synology montre que les deux systèmes s’arrêtent lors d’un événement de l’onduleur, mais ne se rallument pas automatiquement lorsque le courant revient avant que l’onduleur ne soit complètement déchargé. Ce cas montre pourquoi la reprise du stockage, de l’hôte et de l’alimentation doit être testée comme une séquence unique ; des composants individuellement fonctionnels peuvent malgré tout rendre le service indisponible.

Définissez la fréquence des sauvegardes en fonction de la perte de données acceptable, puis restaurez une copie récente sur un autre support ou une machine de rechange. Stockez les identifiants et les étapes à un endroit accessible à un autre administrateur du foyer. Le RAID, le stockage en miroir ou une deuxième partition ne remplacent pas la copie hors hôte, car ils conservent le même domaine de défaillance lié à l’opérateur et au système.

Valider la topologie et définir les seuils de mise à niveau

Effectuez quatre tests de validation : déconnectez le WAN, rendez la cible de sauvegarde indisponible, simulez l’action de l’onduleur en cas de batterie faible et restaurez les données sur un autre matériel. Chronométrez les automatisations critiques, l’arrêt, le redémarrage et la restauration. Consignez les défaillances par maillon du graphe afin que chaque mise à niveau corrige le rôle défaillant au lieu d’ajouter de la capacité partout.

Le guide de ZimaSpace sur la mesure des performances de Home Assistant au-delà du cache à chaud explique pourquoi des tests répétés à chaud peuvent masquer les limites au démarrage à froid ou en période de pointe. Appliquez cette méthode à la charge de travail protégée, puis comparez le résultat à la consommation de l’onduleur et au comportement de reprise, plutôt que d’agrandir l’hôte sur la base d’un test confortable effectué avec des données en cache.

Augmentez la puissance de calcul lorsque les mesures montrent que la latence critique dépasse le seuil, après exclusion des autres goulots d’étranglement. Augmentez la capacité de la batterie lorsque l’autonomie de l’ensemble du parcours n’atteint pas la cible. Séparez les services gourmands si l’isolation résout le problème. Cessez d’acheter du matériel serveur lorsqu’un appareil dépendant uniquement du cloud, un composant réseau non protégé ou une restauration non testée reste le premier maillon de défaillance.

Règle finale de configuration

La taille prête pour les pannes est la topologie protégée la plus réduite qui réussit les tests de perte de WAN, d’autonomie électrique, de redémarrage et de restauration du foyer. Augmentez la puissance de calcul, la capacité de la batterie ou l’isolation uniquement lorsque les mesures révèlent une défaillance à ce niveau. Si les dépendances au cloud ou les lacunes de commande manuelle restent les principaux problèmes, corrigez-les avant d’agrandir le serveur Home Assistant.