Dashboard Home Assistant : une interface utile

Le dashboard est l'écran du quotidien ; l'administration sert à configurer Home Assistant et ne doit pas être confondue avec lui.

Lovelace, c'est le nom historique de l'interface de tableaux de bord de Home Assistant. Le terme « UI » désigne simplement cette interface graphique cliquable : vous y voyez vos appareils, vous cliquez, ça réagit, sans écrire une ligne de code.

Un dashboard affiche et contrôle des entités : un capteur de température s'y consulte, une lampe s'y allume. Il ne modifie ni les intégrations ni les automatisations, ce sont les entrailles du système. Gardez l'administration à part, car personne d'autre dans le foyer n'a besoin d'y accéder, et une fausse manœuvre y casse la configuration.

Quatre vérifications suffisent avant de modifier quoi que ce soit.

Avant de modifier votre interface, faites une sauvegarde de la configuration. Une fausse manipulation ou une carte mal supprimée devient alors réversible : vous restaurez au lieu de tout reconstruire. C'est le réflexe qui vous évite de repartir de zéro, car une modification faite dans la précipitation se répare rarement à l'œil.

Songez aussi à ce que vous attendez de ce tableau de bord. Un dashboard se conçoit comme un outil du quotidien, pas comme une vitrine : si vous savez ce que vous voulez y voir, vous saurez quoi garder et quoi écarter.

Cinq étapes suffisent : créer, nommer, découper, remplir, tester.

Votre premier réflexe sera souvent de réorganiser l'interface par défaut. Résistez-y : partez d'un dashboard vide. Donnez-lui un nom clair et un jeu d'icônes reconnaissables au premier coup d'œil, car c'est ce découpage initial qui rendra l'ensemble lisible. Créez ensuite les vues avant les cartes : c'est cette structure qui organise la lecture. Ajoutez deux ou trois cartes par vue pour un premier essai, puis étoffez progressivement selon vos besoins.

Ce cheminement évite la surcharge visuelle qui décourage après quelques jours d'usage.

Tout dépend du mode : les dashboards en mode interface vivent dans .storage, ceux en YAML dans votre dossier de configuration ; les deux survivent au redémarrage.

Vos dashboards ne disparaissent pas au redémarrage, car Home Assistant recharge simplement la même configuration. Mais l'endroit où ils vivent dépend du mode choisi. En mode interface, tout est enregistré dans le dossier caché .storage de l'installation. Le modifier à la main casse l'affichage. En mode YAML, la définition se trouve dans un fichier de votre dossier de configuration : vous pouvez alors le versionner ou le copier, ce qui change tout quand vous voulez garder une trace ou dupliquer votre travail.

Un détail pratique : après une mise à jour d'une ressource HACS, un simple rechargement du navigateur est souvent nécessaire pour voir le changement, car votre navigateur garde l'ancienne version en mémoire. Rien de cassé, juste un cache à rafraîchir.

Commencez par les cartes natives, ajoutez Mushroom ou un thème ensuite, seulement si un besoin précis n'est pas couvert.

Les cartes natives couvrent la majorité des usages, donc avant d'installer quoi que ce soit, demandez-vous si un bouton, une carte entités, un thermostat, un historique ou une caméra ne suffit pas. Ces cartes arrivent avec Home Assistant, se configurent sans dépendance externe et restent stables à chaque mise à jour. Le natif d'abord, l'ajout ensuite.

Si un besoin précis n'est pas couvert, vous passez par HACS (le gestionnaire de ressources communautaires) : une carte comme Mushroom ou un thème s'ajoute dans les paramètres du dashboard et se met à jour depuis HACS. Mais une ressource non maintenue finit par casser à une mise à jour, et un thème change l'apparence globale sans réécrire vos cartes, à condition de rester compatible. Vérifiez la compatibilité après chaque mise à jour. Pour un débutant, restez au natif ; pour un intermédiaire, Mushroom ; le thème quand l'ensemble vous paraît déjà cohérent.

On joue sur trois leviers : le nombre de colonnes, la taille des éléments et le contraste, puis on verrouille l'écran sur une seule vue.

Sur un mur, vous lisez debout, à quelques mètres, et personne ne touche l'écran en étant assis. Les tuiles doivent donc être grosses et peu nombreuses. Une interface dense se devine mal à distance. Limitez chaque vue à quelques actions principales. Au-delà, on ne sait plus quoi toucher.

Sans mode kiosque ou plein écran, la tablette sort du dashboard après quelques minutes, un point trop souvent oublié. Verrouillez-la donc sur une seule vue et laissez le navigateur s'en charger, puisque c'est lui qui gère l'affichage permanent.

Par pièce pour le quotidien, par usage pour les cas transverses comme l'énergie ou la sécurité ; le mélange des deux est ce qui rend un dashboard illisible.

Une vue par pièce rassemble les lumières, prises et volets de l'endroit où vous vous trouvez, et répond à la question que vous vous posez devant l'écran : « je suis ici, qu'est-ce que je contrôle ? ». Elle rassemble sous un même endroit les lumières, prises et volets de la pièce où vous vous trouvez. Elle sert donc le quotidien. Une vue par usage, elle, regroupe ce qui traverse les pièces : consommation, alarme, caméras, extérieur.

Comme vous ne savez plus où chercher, le mélange des deux rend un dashboard illisible. La vue fourre-tout qui liste toutes les entités par type grossit à chaque nouvel appareil et devient inutilisable ; méfiez-vous-en. Par pièce pour le quotidien, par usage pour le transverse.

Trois causes reviennent. Trop d'entités par vue, trop de dépendances externes et aucune sauvegarde.

Quand vous empilez les entités sans trier, la page finit par ne plus rien mettre en avant. Chaque entité ajoutée est une décision que vous repoussez, et au bout du compte c'est vous qui triez à chaque coup d'œil. Retirez donc régulièrement ce que vous n'utilisez jamais. Votre dashboard respire, et vous aussi.

Tout faire dépendre d'un seul dépôt communautaire vous expose au même écueil. Si toutes vos cartes viennent du même auteur et qu'il abandonne le projet, votre dashboard casse d'un coup ; variez les sources ou rabattez-vous sur du natif. Ne modifiez rien sans sauvegarde récente. Une erreur vous oblige à tout reconstruire à la main, entité par entité.

Si vous devez écrire du YAML ou installer un serveur pour afficher un seul écran, arrêtez-vous : les cartes natives et un dashboard en mode interface couvrent le besoin dans la grande majorité des cas.

Votre page d'accueil n'a pas besoin d'être la plus riche. Il doit d'abord être compris par ceux qui l'utilisent au quotidien. Si plusieurs personnes vivent dans le logement, faites valider les vues principales par les occupants concernés avant d'ajouter des cartes. Une interface que personne ne lit ne sert à rien.

Vous voulez malgré tout un rendu très personnalisé ? Prévoyez alors du temps pour la maintenance, puisqu'une mise à jour peut demander une vérification et que ce qui est bricolé finit par se casser. Le YAML, ce format de configuration écrit à la main, se paie en suivi.

Votre dashboard personnel gagne à rester simple, stable et compris par ceux qui l'utilisent, sans confondre l'interface du quotidien avec l'administration.

Cette interface que vous et vos proches consultez chaque jour n'est pas un écran d'administration. Votre priorité n'est donc pas d'empiler des cartes, mais de préparer un terrain propre, puis de construire par étapes selon une logique claire, par pièce pour le quotidien et par usage pour les besoins transverses comme l'énergie ou la sécurité. Un dashboard lisible naît d'une organisation cohérente, pas d'une accumulation de widgets.

Côté technique, les dashboards en mode interface ou en YAML survivent au redémarrage, et les cartes natives couvrent la grande majorité des besoins. N'ajoutez Mushroom, un thème ou du YAML écrit à la main que si un besoin précis n'est pas couvert, en gardant en tête la maintenance. Si vous devez installer un serveur pour afficher un seul écran, arrêtez-vous. La simplicité est votre meilleur allié sur la durée.