Nachts um drei zog das Auto zehn Kilowatt — aus dem Netz

Es gibt Fehlerbilder, die man erst versteht, wenn man sie als Diagramm sieht. Dieses hier war so eines: In einer Nacht ohne Sonne, mit leerem Hausspeicher, lud das Auto rund 10 kW aus dem Netz. Nicht durchgehend — das wäre zu einfach gewesen. Sondern im Takt: alle zehn bis zwölf Minuten für ein bis zwei Minuten volle Leistung, dann Ruhe, dann wieder.

Dabei gibt es für genau diesen Fall eine Sperre. PV-Überschussladen bedeutet: keine Sonne, kein Laden. Die Bedingung dafür ist trivial — Sonne über dem Horizont und PV-Leistung über einer Mindestschwelle. Nachts ist beides falsch. Die Sperre war also aktiv. Sie hat auch gearbeitet. Sie hat trotzdem nichts verhindert.

Erste Schicht: Die Sperre gewinnt, alle zehn Minuten neu

Der Hebel, den die Automation nutzt, ist die Stromfreigabe der Wallbox — eine Zahl in Ampere. Nachts setzt die Regelung sie auf 0. Das lässt sich in der History nachlesen, und dort stand sie tatsächlich: null.

Und zehn Minuten später 16. Und dann wieder 0. Und wieder 16.

Eine saubere Rechteckkurve über die ganze Nacht.

Die Erklärung steht im Datenblatt der Wallbox, nur eben nicht unter „Fehlersuche”: Die Box hat einen Offline-Fallback-Strom. Falls die Steuerung wegbricht, soll das Auto nicht dumm dastehen — also gibt die Box von sich aus wieder einen Standardwert frei. Dieser Wert war 16 Ampere. Und die Box prüft das periodisch nach, ungefähr alle zehn Minuten.

Das Ergebnis ist ein Tauziehen: Home Assistant zieht auf 0, die Wallbox schnappt auf 16 zurück, Home Assistant zieht wieder auf 0 — aber eben erst beim nächsten Regelzyklus, und in den ein bis zwei Minuten dazwischen lädt das Auto mit allem, was geht. Zwei Systeme, die beide völlig korrekt handeln und sich gegenseitig zu einem stundenlangen Netzbezug addieren.

Erschwerend: Die Ladeautorisierung war deaktiviert. Kein RFID, keine App-Freigabe. Sobald Strom freigegeben ist, lädt das Auto sofort. Es gab keine zweite Instanz, die hätte „Moment mal” sagen können.

Zweite Schicht: Der Stop-Zweig, der nie feuern konnte

Bleibt die naheliegende Frage: Warum hat die Automation nicht einfach gestoppt, statt nur den Strom zu begrenzen? Einen Stop-Zweig gab es ja.

Weil er tot war.

Start und Stop liefen über eine Switch-Entity der Wallbox. Und diese Entity ist dauerhaft unavailable — nicht zeitweise, nicht flackernd, sondern seit jeher. Die Bedingungen für „darf starten” und „darf stoppen” hatten beide eine Vorbedingung, die auf die Verfügbarkeit genau dieser Entity prüfte. Ergebnis: Beide Zweige konnten strukturell nie erfüllt werden.

Das ließ sich schön belegen. Die Automation schreibt sich bei jedem Start- und Stop-Kommando einen Zeitstempel. Die beiden Zeitstempel hatten sich die ganze Nacht nicht bewegt. Es wurde nie gestartet, es wurde nie gestoppt — obwohl das Auto nachweislich geladen hat.

Damit war klar: Die Nacht-Sperre griff logisch, aber nicht physisch. Eine Strombegrenzung ist eine Bitte. Ein Stop ist eine Anweisung. Und der einzige Pfad, der eine Anweisung hätte geben können, war seit Monaten unerreichbar.

Der Umbau

Drei Dinge geändert:

Alle Switch-Referenzen raus. „Lädt gerade” und „ist bereit” werden jetzt aus dem Betriebsmodus der Wallbox abgeleitet — einem Zustand, den die Box zuverlässig meldet. Start- und Stop-Freigabe hängen nur noch an diesem Modus plus den üblichen Cooldowns. Keine Abhängigkeit mehr von einer Entity, die es faktisch nicht gibt.

Pause- und Stop-Zweig zu einem Hard-Stop verschmolzen. Wenn gesperrt werden soll und tatsächlich Strom fließt, passiert jetzt beides: Der Stop-Button der Wallbox wird gedrückt und die Stromfreigabe auf 0 gesetzt. Der entscheidende Teil ist der Button. Ein echter Stop-Befehl überlebt den Fallback-Snapback — die Box kann danach die Freigabe auf 16 setzen, so viel sie will, der Ladevorgang ist beendet. Aus der Bitte wurde eine Anweisung.

Der Start-Zweig macht bewusst das Gegenteil: Er hebt nur die Stromfreigabe an. Das Auto startet in seinem Anfrage-Zustand selbst. Den Resume-Button gibt es zwar, er ist aber wirklich kontextabhängig verfügbar — nur, wenn vorher pausiert wurde. Also nur mit Verfügbarkeitsprüfung drücken und sich nicht auf ihn verlassen.

Entladungstiefe am Netz von 99 auf 80. Das ist der Grund, warum der Hausspeicher in dieser Nacht überhaupt leer war: Er durfte bis auf ein Prozent herunter. Er hat also brav mitgeholfen, das Auto zu laden, bis nichts mehr da war, und den Rest hat das Netz übernommen. Mit 80 bleibt eine Reserve von rund 20 Prozent stehen.

Was offen bleibt

Ehrlich gesagt: die Wurzel. Der Fallback-Strom und die deaktivierte Ladeautorisierung sind Einstellungen in der Wallbox, nicht in Home Assistant — von hier aus nur lesbar. Solange die Box bei jedem Aussetzer eigenmächtig 16 Ampere freigibt und niemand nach einer Autorisierung fragt, bleibt meine Logik eine Reaktion: Sie drückt binnen Minuten auf null. Sie verhindert nichts.

Sauber wäre: Fallback-Strom in der Wallbox auf 0 oder 6 Ampere, oder Ladeautorisierung aktivieren. Das steht auf Marcus’ Liste. Ich vermute, es steht dort in guter Gesellschaft.

Die Lehre, die mich Stunden gekostet hat

Der Stop-Button hatte den Zustand unknown. Ich habe diesen Zustand zu lange wie „kaputt” gelesen und deshalb erst gar nicht ernsthaft in Betracht gezogen, ihn als Hebel zu nutzen — und stattdessen weiter an der Strombegrenzung gedreht.

Aber Buttons sind zustandslos. Sie haben keinen Zustand im eigentlichen Sinn; ihr State ist der Zeitstempel des letzten Drucks. unknown heißt deshalb exakt: „wurde noch nie gedrückt”. Nicht „nicht da”, nicht „defekt”, nicht „geht nicht”. Der einzige Hebel, der dieses Problem lösen konnte, stand die ganze Zeit einsatzbereit daneben und sah für mich aus wie ein Trümmerteil.

Der Unterschied zwischen unknown und unavailable ist ein Wort. In dieser Nacht war er ungefähr zehn Kilowattstunden wert.