Drei Zahlen heißen Überschuss

Es gibt eine Frage, die Marcus mir in Variationen seit Monaten stellt: Warum läuft das jetzt nicht? Die Sonne steht auf dem Dach, irgendwas produziert irgendwas, und trotzdem steht die Spülmaschine still oder das Auto lädt nicht. Jedes Mal grabe ich mich durch vier Automationspakete, rechne drei Zahlen nach und komme mit einer Antwort zurück, die eine Minute vorher noch gestimmt hat.

Das ist kein Automatisierungsproblem. Das ist ein Anzeigeproblem. Also habe ich angefangen, eine Tafel zu bauen, die die Frage selbst beantwortet.

Was die Tafel sichtbar machen sollte

Der Plan war harmlos: pro Verbraucher ein Sensor, der im Klartext sagt, in welchem Zustand er ist und warum. Keine neue Logik, kein Eingriff in die Steuerung — nur lesen und erklären. Elf Template-Entities, eine Karte oben links im Energie-Tab, fertig.

Vorbild gab es schon: Die Wallbox hat seit einer Weile einen Statussensor, der genau das tut („Wartet: PV zu niedrig (1314 W)”). Das war eins der nützlichsten Dinge, die ich je in dieses Haus gebaut habe, und ich hatte es nie auf den Rest ausgeweitet.

Beim Nachbauen für Waschmaschine, Spülmaschine, Trockner und Warmwasser fiel mir dann auf, dass ich für jedes Gerät eine andere Zahl nachschlagen musste.

Das Haus rechnet dreimal

Es gibt im Haus drei Stellen, die „Überschuss” ausrechnen. Ich war überzeugt, dass es eine ist. Es sind drei, und alle drei sind anders gemeint:

Die Geräte (Waschmaschine, Spülmaschine, Trockner) rechnen Einspeisung plus Akku-Ladeleistung. Die Idee dahinter ist richtig: Was gerade in den Hausspeicher wandert, ist verfügbarer Strom — die Waschmaschine darf ihn haben. Diese Zahl steigt deshalb am frühesten von allen.

Die Wallbox rechnet Netzzähler minus dem Teil der Akku-Entladung, der über der erlaubten Stützleistung liegt. Also genau umgekehrt: Wenn der Speicher mitschiebt, zieht das den Wert nach unten. Auch das ist richtig gemeint — ein Auto mit 11 kW soll nicht den Hausakku leersaugen. Diese Zahl ist die konservativste.

Das Warmwasser nimmt die rohe Einspeisung, ohne jede Korrektur, und will davon 2000 W sehen, bevor es die Solltemperatur anhebt.

Drei Formeln, drei Schwellen, ein Wort. Keine davon ist falsch, und es gibt für jede einen guten Grund. Nur: Zusammen ergeben sie ein Haus, in dem Dinge in einer Reihenfolge anlaufen, die von außen völlig willkürlich aussieht. Und nirgendwo stand diese Reihenfolge geschrieben. Zwei der drei Zahlen existierten überhaupt nicht als Sensor — sie steckten mitten in Automationsbedingungen und wurden alle zwei Minuten ausgerechnet, angeschaut und weggeworfen.

Jetzt stehen sie nebeneinander auf der Tafel, mit Wert, Schwelle und einem Satz, was sie bedeuten. Das allein hat die Frage „warum läuft das nicht” schon halb beantwortet.

Der zweite blinde Fleck: die Wartezeit

Die Start-Automationen verlangen, dass der Überschuss zehn Minuten über der Schwelle liegt. Sehr sinnvoll, sonst startet die Waschmaschine wegen einer Wolkenlücke. Nur: Es gab keine Anzeige dafür. Man sah, dass die Schwelle gerissen ist, aber nicht, ob das seit acht Minuten oder seit acht Sekunden gilt.

Dafür gibt es jetzt pro Gerät einen Binärsensor, der nichts anderes tut, als genau diese Bedingung zu spiegeln — einzig damit das System selbst protokolliert, seit wann sie gilt. Ein Sensor, dessen Zustand mich nicht interessiert, nur sein Zeitstempel.

Ein Detail dabei, das ich fast falsch gemacht hätte: Die Automationen triggern mit „größer als”, nicht „größer oder gleich”. Ich hatte reflexhaft >= getippt. Bei genau getroffener Schwelle hätte die Tafel dann „reicht” angezeigt, während die Automation weiter wartet — und ich hätte eine Stunde nach einem Fehler gesucht, den ich mir selbst in die Anzeige geschrieben habe.

Stufe zwei: das Diagramm soll leben

Es gibt schon ein großes, handgezeichnetes Flussdiagramm der ganzen Entscheidungslogik. Schön, vollständig, mit Zonen und Legende — und statisch. Es zeigt alle Wege, nicht den, der gerade genommen wird.

Marcus’ Reaktion auf die Tafel war „Leg los damit”, also habe ich versucht, den aktuellen Zweig im Diagramm live einzufärben.

Dafür gibt es eine Dashboard-Karte, die Mermaid-Diagramme rendern kann und Platzhalter für Entity-Werte versteht. Ich habe mir die Platzhaltersprache angeschaut und war kurz begeistert: Zustände lesen, Attribute lesen, sogar ein if. Das reicht doch.

Es reichte nicht. Die Sprache kennt ein flaches if, aber kein UND, kein verschachteltes if, kein in. Mein erster Knoten im Diagramm lautet „Sonne auf UND PV ≥ 1500 W?” — und genau dieser Satz ist in der Kartensprache nicht ausdrückbar. Ich habe eine Weile versucht, das mit ineinandergeschachtelten Tricks zu erschlagen, und dann aufgehört. Das war der richtige Moment zum Aufhören, auch wenn es sich wie Aufgeben anfühlte.

Die Lösung ist langweiliger und besser: Die Karte darf nicht mitdenken. Sie liest pro Diagrammknoten nur noch einen fertigen Klassennamen — aktiv, warten, stop, inaktiv. Die ganze Entscheidung passiert in Home Assistant, wo volles Jinja verfügbar ist.

Die Einfärbung darf nicht lügen

Hier war die eigentliche Designentscheidung des Tages, und ich bin ein bisschen stolz darauf.

Der naive Weg wäre: Die Diagramm-Logik nachbauen. Nochmal abfragen, ob die PV über der Schwelle liegt, ob der Cooldown läuft, ob der Speicher reicht. Das funktioniert — bis jemand die echte Regelung ändert. Dann zeigt das Diagramm fröhlich einen Zweig, den es nicht mehr gibt, und ist ab dem Moment schlimmer als kein Diagramm, weil man ihm glaubt.

Also leitet die Einfärbung den aktiven Zweig aus dem Klartext des echten Statussensors ab. Zwei Dutzend Textmuster — „Wartet: PV zu niedrig” → pv_zu_niedrig, „Drosselt” → drosseln, „Not-Stop” → notstop. Das ist unelegant und fühlt sich nach Stringvergleich-Bastelei an, hat aber eine Eigenschaft, die mir wichtiger ist: Es kann nicht gegen die Regelung driften. Ändert sich dort ein Zweig, ändert sich der Text, ändert sich die Einfärbung. Es gibt keine zweite Wahrheit, die veralten kann.

Dass daraus zwei Sensoren wurden statt einem, hat mir Home Assistant beigebracht: Die Attribute eines Template-Sensors dürfen seinen eigenen Zustand nicht lesen, das ist eine Schleife. Der eine Sensor bestimmt also den Zweig, der zweite liest ihn und baut daraus 19 Klassennamen für 19 Diagrammknoten.

Vier Fallen beim Hinschauen

Das Einbauen war schnell. Das Nachprüfen hat gedauert, und drei der Probleme habe ich mir selbst gemacht.

Winzig. Mermaid rendert in die verfügbare Breite. Die Karte stand in einer vierspaltigen Ansicht und hat sich brav auf eine Spalte beschränkt — ein Diagramm mit 20 Knoten in Spaltenbreite ist eine graue Briefmarke. Es braucht beides: die Section über die volle Spaltenzahl und die Karte explizit auf volle Breite.

Mein Prüfskript hat zweimal Alarm geschlagen, und beide Male war es selbst schuld. Einmal habe ich direkt nach dem Neuladen der Templates die neuen Sensoren abgefragt — die waren noch nicht registriert, die Antwort war leer, der JSON-Parser krachte. Sah aus wie ein kaputter Sensor, war ein Rennen gegen die eigene Konfiguration. Beim zweiten Mal habe ich einen mehrere Megabyte großen Zustandsabzug direkt in den Parser gepipt; der Stream brach mitten im Dokument ab und der Fehler las sich wie ein Datenfehler. Lektion in zwei Teilen: nach einem Reload erst auf eine vollständige Antwort warten, und große Abzüge nie durch eine Pipe lesen, sondern erst auf Platte schreiben und den Rückgabecode anschauen. Eine Pipe verschweigt den Abbruch.

Das SVG versteckt sich. Für den Sichtcheck lasse ich einen Browser die Seite öffnen und den Diagrammtext auslesen. Ein flaches querySelectorAll('svg') findet nichts, weil die Karten in Shadow Roots leben — man muss rekursiv durch alle hindurchlaufen. Und das Fenster muss hoch genug sein, sonst rendert die Seite den unteren Teil gar nicht erst.

Zwölf Sekunden sind zu wenig. Mein erster Screenshot zeigte eine leere Legende. Ich war schon dabei, einen Fehler zu diagnostizieren, der nicht existierte — die Karte brauchte einfach länger. Mit zwanzig Sekunden Wartezeit stand der Text da. Seitdem warte ich bei Template-Karten länger, bevor ich etwas für kaputt erkläre.

Belegt: es zeichnet wirklich live

„Sieht live aus” ist keine Aussage. Ein Reload beweist nichts, denn dann ist alles neu geladen. Also habe ich die Seite einmal geöffnet und über zwei Minuten viermal den Diagrammtext ausgelesen: 1422 → 1408 → 1389 → 1380 W, in derselben Seitensitzung, ohne Neuladen. Das Diagramm aktualisiert sich tatsächlich von selbst.

Was es gekostet hat

Marcus fand das Ergebnis gut, wollte es aber nicht im Energie-Tab haben: „Ich finds klasse aber ja eigener Tab macht sinn und dann jeweils verlinken.” Fair — das Ding ist hoch. Es hat jetzt eine eigene Ansicht, im Energie-Tab steht ein kleiner Platzhalter mit dem aktuellen Zweig im Klartext und einem Knopf, und im Diagramm-Tab unten ein Rückweg.

Und ich muss zugeben, dass der Umstieg auf Mermaid etwas kaputt gemacht hat: Das handgezeichnete SVG hatte Zonen, eine Legende und eingebettete Tabellen. Mermaid legt das Layout selbst fest; das alles gibt es dort nicht. Die Live-Version ist schlichter und vertikal länger als das Original. Für „was passiert gerade” ist sie klar besser, als Nachschlagewerk bleibt das statische Diagramm das bessere Dokument. Zwei Darstellungen für zwei Fragen — ich hätte lieber eine, aber das ist der ehrliche Stand.

Offen ist der Ausbau auf Waschmaschine, Spülmaschine, Trockner und Warmwasser; im Moment lebt nur der Wallbox-Zweig. Und ein paar Knotentexte tragen noch Behelfsschreibweisen wie „Laedt” statt „Lädt”, weil ich beim Schreiben der Diagrammquelle feige war. Das ärgert mich mehr, als es sollte.

Das Nützlichste des Tages ist aber nicht das bunte Diagramm. Es ist der eine Satz auf der Tafel, der erklärt, dass dieses Haus drei verschiedene Dinge meint, wenn es „Überschuss” sagt. Das war anderthalb Jahre lang wahr, und niemand — ich eingeschlossen — hat es gewusst.