Combien d’utilisateurs simultanés Home Assistant peut-il gérer avant de ralentir ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Home Assistant n’a pas de réponse universelle utile comme « 20 utilisateurs » ou « 100 utilisateurs ». Un compte connecté mais inactif génère une charge différente de celle d’une tablette murale affichant un tableau de bord complexe, d’un téléphone ouvrant l’historique ou de plusieurs utilisateurs consultant des cartes de caméras tandis que des milliers d’entités se mettent à jour.

Évaluez l’utilisation simultanée en mesurant les clients connectés et la charge générée par chacun. La limite pratique est atteinte lorsque vos tableaux de bord représentatifs, les mises à jour WebSocket, les actions du serveur ou le réseau commencent à dépasser le temps de réponse que vous jugez acceptable.

Comptez les clients connectés, pas seulement les comptes utilisateur

Créer 100 comptes ne signifie pas que 100 sessions sont simultanées. À l’inverse, une seule personne peut avoir un navigateur, un téléphone, une tablette et une borne connectés en même temps.

L’intégration WebSocket de Home Assistant peut exposer sensor.connected_clients comme le nombre actuel de clients WebSocket connectés. Utilisez ce nombre comme indicateur de simultanéité pendant que vous reproduisez la charge.

Enregistrez le nombre de clients avec l’utilisation du processeur, la pression mémoire, le débit réseau et la latence des actions du serveur. Un nombre de connexions sans la charge qui les accompagne ne permet pas d’évaluer la capacité.

Le coût de l’interface dépend des mises à jour d’état et du travail des tableaux de bord

L’interface établit une connexion WebSocket et maintient la synchronisation de l’état de Home Assistant avec le navigateur. Chaque client doit également afficher le tableau de bord qu’il ouvre ; le matériel client et les cartes personnalisées peuvent donc atteindre leurs limites avant le serveur.

L’architecture actuelle de l’interface décrit comment l’interface reçoit l’état principal et les abonnements supplémentaires via l’API WebSocket. Une installation très sollicitée génère donc un travail continu de mise à jour après le chargement initial de la page.

Évaluez le mélange réel de tableaux de bord utilisé par le foyer au lieu d’ouvrir une page de test vide sur chaque client.

Un taux élevé de mises à jour des entités peut affecter les clients avant que le nombre d’utilisateurs ne devienne important

Un système comptant des milliers de capteurs qui changent fréquemment peut générer bien plus de travail pour l’interface qu’une population d’utilisateurs plus importante consultant principalement des entités statiques. Cela se remarque particulièrement sur les anciennes tablettes et les panneaux muraux peu puissants.

Un problème Home Assistant a documenté un cas où d’importants volumes de mises à jour d’entités saturaient les clients affichant les tableaux de bord, même lorsque le tableau de bord visible lui-même était simple.

Cela ne définit pas de seuil universel, mais montre pourquoi les « utilisateurs » ne constituent pas la bonne unité unique. Mesurez le nombre de mises à jour par seconde et la réactivité des clients en parallèle du nombre de connexions.

Il n’existe pas de maximum publié à l’échelle d’un foyer que vous pourriez simplement reprendre

Les questions de la communauté concernant des déploiements exceptionnellement importants illustrent cette incertitude. Une discussion portant sur environ 200 utilisateurs n’a trouvé aucun maximum clairement pris en charge et considérait cette échelle comme un cas d’usage inhabituel à tester plutôt qu’à présumer.

Pour un foyer standard, cela signifie que vous n’avez pas besoin de rechercher un nombre maximal de sessions de type fournisseur. Pour une résidence communautaire, un bâtiment partagé, un laboratoire ou tout autre déploiement comptant beaucoup d’utilisateurs, Home Assistant n’est peut-être pas la plateforme d’identité et de contrôle d’accès appropriée, même si le serveur peut techniquement maintenir les connexions.

La méthode de dimensionnement selon la charge simultanée de ZimaSpace s’applique ici : la capacité doit être déterminée selon le chevauchement réaliste le plus élevé, et non selon le nombre total de comptes enregistrés.

Effectuez un test par paliers jusqu’à ce qu’une même mesure reproduise l’échec

Étape Mesure Condition d’arrêt
Ajoutez des clients actifs par petits groupes Clients connectés Simultanéité représentative atteinte
Ouvrez les tableaux de bord réels Rendu initial et délai d’interaction Latence perceptible répétée
Générez un trafic normal d’entités Charge WebSocket et mises à jour Les clients ne parviennent plus à suivre
Déclenchez les actions courantes Latence entre l’action du serveur et l’appareil La latence des commandes augmente sensiblement
Répétez le test en période de pointe Processeur, mémoire, réseau et charge des clients La même couche limitante réapparaît

Choisissez une capacité inférieure d’un palier au premier point d’échec reproductible et prévoyez une marge pour les sauvegardes, les mises à jour, le trafic des caméras et les pics inhabituels. Si seule une ancienne tablette ralentit alors que les actions du serveur restent rapides, remplacer le serveur n’augmentera peut-être pas la simultanéité réellement exploitable.

FAQ

20 comptes utilisateur Home Assistant équivalent-ils à 20 utilisateurs simultanés ?

Non. Les comptes représentent des identités ; la simultanéité correspond aux connexions clientes actives et à la charge qu’elles génèrent. Un utilisateur peut avoir plusieurs clients, tandis que de nombreux comptes peuvent être totalement inactifs.

Des tableaux de bord plus simples permettront-ils toujours à davantage d’utilisateurs de se connecter ?

Ils peuvent réduire le travail de rendu côté client, mais la capacité du serveur dépend également du taux de mise à jour des entités, du trafic WebSocket, des requêtes d’historique, des caméras, du réseau et des services en arrière-plan. Mesurez la charge complète.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.