Configurez le cache de Home Assistant en identifiant d’abord les données qui peuvent être supprimées ; ne déplacez jamais l’intégralité du chemin de configuration persistant vers un stockage temporaire.
Le terme « cache » peut désigner les ressources du frontend du navigateur, les sorties TTS, les fichiers temporaires propres à une intégration, le /tmp d’un conteneur, le cache de pages du système d’exploitation ou l’espace de travail de la base de données. Ces couches ont des responsables et des comportements de récupération différents. Conservez les utilisateurs, les registres, la configuration, l’état de Recorder et les autres fichiers faisant autorité sur un stockage durable. Utilisez tmpfs ou un stockage en mémoire uniquement pour un chemin temporaire documenté, dont la perte et la consommation mémoire ont été testées après redémarrage.
Classez le cache avant de déplacer un chemin
Commencez par identifier le responsable, le chemin, la taille maximale attendue, la méthode de reconstruction et ce qui se passe si les données disparaissent. Le cache du navigateur se trouve sur le client ; l’état applicatif persistant de Home Assistant se trouve sous le chemin de données configuré ; les caches des intégrations varient ; les fichiers temporaires d’un conteneur peuvent disparaître au redémarrage. Ils ne doivent pas être gérés par un unique paramètre global de « répertoire de cache ».
Un cas TTS de Home Assistant illustre une situation précise où les fichiers audio générés sous un chemin de cache spécifique ont été intentionnellement redirigés vers un emplacement en mémoire. La limite importante dans le déplacement d’un cache TTS temporaire est que l’utilisateur a ciblé un seul répertoire pouvant être reconstruit, et non l’ensemble de l’arborescence de configuration.
Si vous ne pouvez pas prouver qu’un fichier peut disparaître sans entraîner la perte de l’identité, de l’historique, des paramètres, des tableaux de bord ou de l’enregistrement d’une intégration, classez-le comme persistant. Le choix par défaut le plus sûr est le stockage durable. L’optimisation vient après l’identification du responsable de la récupération.
Conservez l’état persistant de Home Assistant et Recorder sur un stockage durable
Le volume de configuration n’est pas un cache simplement parce qu’il contient certains fichiers générés. Il peut contenir les authentifiants, les registres d’entités et d’appareils, l’état des automatisations, la configuration, les composants personnalisés et la base de données Recorder par défaut. Placer l’intégralité de ce chemin sur tmpfs transforme un redémarrage en perte de données et rend les sauvegardes dépendantes du contenu de la mémoire, qui n’a jamais été destiné à faire autorité.
L’explication de ZimaSpace sur les rôles des données persistantes de Home Assistant constitue le bon premier filtre : séparez l’état faisant autorité du cache reconstructible et des données de travail temporaires avant d’attribuer les niveaux de stockage.
Utilisez un SSD ou un autre système de fichiers durable et fiable pour l’état de l’application, en réservant suffisamment d’espace libre pour la croissance de la base de données, les mises à niveau et la maintenance. Déplacer un petit cache temporaire vers la RAM ne peut pas compenser un volume persistant sous-dimensionné ou défaillant.
Utilisez tmpfs uniquement pour des chemins explicitement temporaires et avec une limite mémoire
Tmpfs peut réduire les écritures et offrir une très faible latence, mais il consomme la RAM de l’hôte et disparaît lorsque le conteneur ou l’hôte s’arrête. Il convient donc aux données de travail temporaires et limitées, pas aux données nécessaires après un redémarrage. Le montage doit également être dimensionné afin qu’une charge temporaire ne puisse pas consommer la mémoire nécessaire à Home Assistant Core et aux services voisins.
Un guide actuel sur Docker Compose explique que l’utilisation de tmpfs est comptabilisée dans la capacité mémoire et peut entraîner des erreurs d’espace insuffisant ou d’OOM lorsqu’elle est surdimensionnée ou illimitée par rapport au budget du conteneur.
Définissez une limite de taille, surveillez l’utilisation maximale et redémarrez volontairement le conteneur. Le chemin doit se repeupler automatiquement, tandis que les utilisateurs, les paramètres, l’historique et les intégrations restent inchangés. Si l’application ne peut pas reconstruire le répertoire ou considère son absence comme une corruption, replacez-le sur un stockage durable.
Considérez le cache du frontend comme un problème client, et non comme un stockage serveur
Une page Home Assistant obsolète dans un navigateur peut persister même lorsque le serveur fonctionne correctement, car les ressources du frontend sont mises en cache par le navigateur ou l’application. Effacer les fichiers temporaires côté serveur ne corrigera pas cet état côté client. À l’inverse, vider le cache du navigateur ne réduira pas les entrées-sorties disque de Recorder et ne diminuera pas la taille de la base de données Home Assistant.
Les utilisateurs de Home Assistant distinguent explicitement le cache du frontend comme cache du navigateur, raison pour laquelle le dépannage du cache doit commencer par déterminer si le symptôme existe sur un seul client ou sur l’ensemble du serveur.
Utilisez un navigateur vierge ou un profil privé comme contrôle de validation. Si le nouveau client fonctionne correctement, concentrez la correction sur le frontend. Si tous les clients affichent les mêmes données manquantes ou la même erreur côté serveur, ne continuez pas à vider les caches locaux ; revenez aux journaux de Home Assistant et au dépannage du stockage, de l’intégration ou de la base de données.
Validez le stockage temporaire au moyen de tests de redémarrage, de pression et d’espace libre
Après avoir modifié un chemin de cache ou de tmpfs, mesurez la taille normale et maximale, la mémoire disponible sur l’hôte, la pression mémoire du conteneur, l’espace libre du volume persistant et le comportement au redémarrage. Exécutez ensuite la charge qui crée le cache — TTS, médias, traitement par une intégration personnalisée ou un autre producteur connu — et vérifiez que le nettoyage s’effectue comme prévu.
Conservez une marge sur le stockage durable pour les opérations qui nécessitent un espace de travail temporaire, même si la base de données quotidienne tient confortablement. Ne remplissez pas le volume persistant parce qu’un cache en RAM a réduit les écritures habituelles ; les mises à niveau, la maintenance de la base de données, les sauvegardes et les pics de journaux peuvent nécessiter des quantités d’espace temporaire très différentes.
Le test est concluant lorsque chaque chemin temporaire peut disparaître puis être reconstruit, que l’état persistant survit au redémarrage du conteneur et de l’hôte, que l’utilisation maximale de tmpfs reste dans le budget mémoire et que Home Assistant dispose toujours de suffisamment d’espace durable. Si un paramètre requis ou un historique disparaît après le test, le chemin a été mal classé et doit être replacé sur un stockage persistant avant toute optimisation supplémentaire.
Assistance et conseils
Plus à lire

Home Assistant peut-il partager un GPU ou un accélérateur avec un autre conteneur ?
Le partage du GPU dépend de la charge de travail : les conteneurs peuvent souvent partager les nœuds de rendu, tandis que le passthrough...

Comment déterminer si une erreur de Home Assistant provient du client ou du serveur
Les échecs touchant un seul client indiquent un problème d’état du client ; ceux touchant plusieurs clients orientent plutôt vers le serveur ou un...

Comment empêcher les sauvegardes de Home Assistant de capturer un état incohérent de la base de données
Utilisez des sauvegardes compatibles avec Home Assistant pour les systèmes en production ; si vous effectuez des copies brutes de fichiers, mettez la base...

