Ein Home-Assistant-Dashboard von Null aufbauen

Die meisten Anleitungen zu Home-Assistant-Dashboards zeigen ein fertiges Dashboard. Das ist das am wenigsten nützliche Bild, denn interessant ist, was zwischen einer leeren Ansicht und diesem Screenshot passiert — und genau dort geben die Leute auf.

Ich habe deshalb eines in fünf Schritten gebaut und jeden Schritt als eigene Datei behalten. Dieselbe Instanz, dieselben Daten, dieselbe Bildgröße, sonst hat sich zwischen den Aufnahmen nichts geändert. Es folgen diese fünf Zustände der Reihe nach.

Schritt eins: die leere Ansicht

Ein neues Dashboard ist eine Überschrift und viel Nichts. Keine Anleitung zeigt das, und es lohnt sich, es einmal gesehen zu haben — die Ratlosigkeit, wo man anfangen soll, ist ein echter Grund, warum Dashboards schlecht bleiben.

Schritt eins: gar nichts.

Schritt zwei: die erste Karte

Eine Kachel. Sie belegt eine einzige Spalte und lässt den Rest der Breite leer, was kaputt aussieht und keines ist — das Raster füllt sich erst, wenn genug Karten da sind, um es zu füllen.

Schritt zwei: eine Karte und viel leeres Raster.

Schritt drei: fünf Karten, keine Ordnung

Das funktioniert. Jeder Wert steht auf dem Bildschirm, alles ist lesbar, und man könnte hier aufhören. Die meisten Dashboards hören hier auf, und deshalb sehen so viele aus wie eine Liste von Zahlen statt wie etwas, auf das man kurz schaut.

Schritt drei: fünf Karten. Alles lesbar, nichts geordnet.

Schritt vier: dieselben Karten, gruppiert

Jetzt dreizehn Karten, in drei Gruppen mit Überschriften. Für diesen Schritt existiert der ganze Beitrag. Zwischen dem dritten und dem vierten Bild kommt kein einziger neuer Inhalt dazu. Dieselben Werte stehen auf dem Bildschirm. Geändert hat sich, dass sie gruppiert und beschriftet sind, und der Unterschied darin, wie schnell man das liest, ist größer als alles, was ich danach noch getan habe.

Schritt vier: dieselben Werte, in drei beschrifteten Gruppen. Vergleich das mit dem Bild darüber.

Wenn du eine Sache mitnimmst: Das Mittel gegen ein überladen wirkendes Dashboard ist fast nie eine weitere Karte. Es ist, die vorhandenen Karten in Abschnitte zu legen, die sagen, was sie sind.

Schritt fünf: die fertige Ansicht

Dreiundzwanzig Karten, mit Rundinstrumenten, einem Zwölf-Stunden-Verlauf und den Sollwerten, die tatsächlich verstellt werden. Das ist die Fassung, die ich behalten habe, und sie liegt nur zwei Arbeitsschritte hinter der, die wie eine Liste aussah.

Schritt fünf: 23 Karten, Rundinstrumente und ein Verlaufsdiagramm.

Wie Schritt vier als Konfiguration aussieht

Die Gruppierung ist eine Ansicht vom Typ sections, und jede Gruppe ist ein Raster mit einer heading-Karte als erstem Eintrag. Zwei Einstellungen erledigen den Großteil: max_columns begrenzt, wie breit sich die Ansicht auf einem großen Bildschirm zieht, und column_span lässt einen Abschnitt mehr Breite nehmen als seine Nachbarn.

views:
  - title: Übersicht
    type: sections
    max_columns: 3
    sections:
      - type: grid
        column_span: 2
        cards:
          - type: heading
            heading: Energie
            heading_style: title
            icon: mdi:solar-power-variant
          - type: gauge
            entity: sensor.pv_leistung
            name: Erzeugung
            min: 0
            max: 8000
            needle: true

Auf einem 27-Zoll-Bildschirm zieht sich eine Ansicht ohne max_columns auf fünf oder sechs Spalten und ist auf einen Blick nicht mehr lesbar. Das war mir nicht klar, bis ich sie an einem Monitor statt am Laptop gesehen habe. Drei ist die Zahl, bei der ich geblieben bin.

Drei Dinge, die unterwegs kaputt waren

Markdown-Karten als Überschriften haben das Layout zerlegt. Sie zählen als Rasterzelle, die Kacheln darunter verteilten sich also auf falsche Spalten, und der ganze Abschnitt sah verrutscht aus. Die native heading-Karte spannt stattdessen über die volle Abschnittsbreite und behebt es.

Zahlen sprangen bei jeder Änderung. Proportionale Ziffern sind unterschiedlich breit, ein Wert von 1.111 auf 1.222 verschiebt also die ganze Zeile. Eine Schrift mit Tabellenziffern für die Werte stoppt das. Im Screenshot sieht man es nicht, und im Betrieb sieht man nichts anderes mehr.

Ein Batteriering wurde als volle Scheibe gezeichnet. Ich hatte ihn als Kegelverlauf mit einem Loch in der Mitte gebaut, dessen Hintergrund auf einer Home-Assistant-CSS-Variablen stand. Diese Variable löst im Shadow-DOM der verwendeten Karte nicht auf, das Loch blieb also durchsichtig und der Verlauf schien durch. Die Lösung war, kein Loch mehr in eine Scheibe zu schneiden, sondern einen Kreis mit gestricheltem Rand zu zeichnen. Die fragliche Karte ist button-card, und die gehört nicht zu Home Assistant — sie kommt aus HACS. Das vorher zu installieren ist der Schritt, den man überspringt und sich dann wundert, warum eine Vorlage nichts tut.

Warum Dateien und nicht der Editor

Alles oben ist ein YAML-Dashboard, über die Konfiguration eingebunden statt in der Oberfläche zusammengeklickt. Der Grund ist keine Prinzipientreue. Ein Dashboard, das eine Datei definiert, hat einen reproduzierbaren Zustand: Fünf Dateien ergaben fünf identische Bildausschnitte für die fünf Aufnahmen, und von Hand hätte das über fünf Screenshots nicht gehalten.

Der Editor ist für einen ersten Entwurf schneller. Die Datei ist das, womit man Fassungen eines Layouts aufheben und zu einer zurückkehren kann. Wer das Fertige statt des Wegs will: zwei Dashboards aus Bordmitteln stehen in einem eigenen Beitrag, und das Karten-Verzeichnis listet, was es jenseits der eingebauten gibt.