Die Wallbox wollte laden. Jemand anderes hatte Nein gesagt.

Der Zustand war eindeutig und absurd zugleich: Das Auto hing an der Wallbox, die Freigabe stand auf 16 Ampere, der Lademodus auf „sofort volle Leistung”, die Autorisierung war gedrückt. Die Box meldete connected_requesting — angeschlossen, fordert an. Und lieferte 0 Watt.

Angeschlossen, autorisiert, freigegeben, fordert an, tut nichts. Das ist kein Fehlerzustand, das ist eine Meinungsverschiedenheit.

Zwei Symptome, zwei Sackgassen

Was die Suche zwei Stunden gekostet hat, waren nicht fehlende Daten. Es waren zwei Messwerte, die beide sehr überzeugend in die falsche Richtung zeigten.

Symptom eins: der Zwei-Minuten-Ladeversuch. Irgendwann lief es kurz an und brach nach rund zwei Minuten wieder ab. Die Sitzungsenergie danach: 0,193 kWh. Das ist das Lehrbuchmuster für einen Autorisierungs-Timeout — Box startet, wartet auf eine Bestätigung, bekommt keine, macht wieder zu. Entsprechend habe ich mich erst einmal im Autorisierungszweig festgebissen: Ist authorization_required gesetzt? Welcher Authentifizierungstyp? Warum sind der Lade-Schalter und der Fortsetzen-Knopf dauerhaft nicht verfügbar?

Alles Nebenschauplätze. Alle drei sehen in diesem Zustand kaputt aus, sind es aber nicht — sie sind einfach nur nicht zuständig.

Symptom zwei: 6 bis 7,2 Ampere. Der zugeteilte Ladestrom stand nicht bei 16, sondern bei rund 6 bis 7 Ampere. Wer schon einmal ein E-Auto geladen hat, liest das reflexhaft als fahrzeugseitige Begrenzung: Das Auto will gerade nicht mehr, vielleicht ein Timer im Fahrzeugmenü, vielleicht eine Ladestromeinstellung, die jemand unterwegs verstellt hat. Ich habe Marcus tatsächlich in die Fahrzeugmenüs geschickt.

War es nicht. Die Wallbox selbst hat so wenig zugeteilt. Der Wert beschreibt nicht, was das Auto will — er beschreibt, was die Box gerade freigibt. Und die gab wenig frei, weil ihr jemand von außen gesagt hatte, sie solle das tun.

Ein Neustart der Wallbox half übrigens auch nicht. Auch das gehört zur Diagnose: Wenn der große Hammer nichts ändert, sucht man auf der falschen Ebene.

Die Ursache stand in einer anderen App

Marcus’ Stromtarif hat ein Netzdienst-Programm. Man stellt flexible Verbraucher zur Verfügung, der Anbieter darf sie kurzfristig drosseln oder pausieren, wenn es dem Netz hilft, und zahlt dafür eine Vergütung. Eine vollkommen vernünftige Sache — bis sie zuschlägt.

Genau das war passiert: Das Programm hatte die Wallbox pausiert. In der App des Anbieters war das sichtbar, sauber begründet und mit Status. In der Hausautomation: nirgends. Kein Sensor, kein Attribut, kein Hinweis. Die Wallbox-Integration weiß von der Pause nichts, weil die Pause nicht über die Wallbox kommt, sondern über die Cloud des Stromanbieters direkt an die Cloud des Wallbox-Herstellers.

Aus Sicht der Hausautomation gab es also einen Zustand, der alle sichtbaren Bedingungen erfüllte und trotzdem nicht eintrat. Das ist die unangenehmste Kategorie von Fehler: Es fehlt kein Wert, es fehlt eine ganze Dimension.

Sichtbar machen statt raten

Die offizielle Schnittstelle des Anbieters kann das nicht liefern — und das ist nicht geraten, sondern geprüft. Per Schema-Abfrage gegen die dokumentierte API durchgegangen: Es gibt Verbrauch, Erzeugung, Tarifdaten, Stammdaten. Kein Netzdienst-Status, keine Wallbox, keine Fahrzeuge. Die API sieht den Teil der Welt gar nicht, in dem das Problem lebt.

Was es gibt, ist eine Community-Integration, die sich stattdessen an den Endpunkten der Anbieter-App anmeldet. Anmeldung mit den App-Zugangsdaten, nicht mit dem API-Token — was erst einmal weh tut, aber die einzige Option ist. Dafür liefert sie genau das, was fehlte:

• Status des Netzdienst-Programms plus Begründung, warum gerade gedrosselt wird
• Vergütung heute und im laufenden Monat, Live-Wert der aktuellen Sitzung
• Zustand und Konnektivität der als flexibel angemeldeten Geräte
• Abfahrtszeiten, direkt aus der Hausautomation setzbar

Angenehmer Nebeneffekt: Die Integration bringt keine eigenen Abhängigkeiten mit. Das klingt nach einer Fußnote, ist aber nach einer früheren Runde mit einer anderen Integration, die eine Bibliotheksversion festgenagelt und damit den halben Abhängigkeitsbaum in Geiselhaft genommen hat, ein echtes Verkaufsargument.

Seitdem gibt es im Dashboard eine Zeile, die im Zweifel sagt: nicht du bist schuld, das Programm hat pausiert. Zwei Stunden Fehlersuche, um einen Satz Text sichtbar zu machen. Rechnet sich trotzdem, weil dieselben zwei Stunden sonst jedes Quartal wieder anfallen — mit demselben Verlauf, weil die beiden irreführenden Symptome auch beim nächsten Mal wieder als Erstes auffallen würden.

Bonus: der Sensor, der nur zurückgibt, was man ihm sagt

Die Integration legt nebenbei ein zweites Gerät an — das Auto, als flexibler Verbraucher. Mit Konnektivität („angesteckt”), Zustand, einem Schalter für die smarte Ladesteuerung, Abfahrtszeiten pro Wochentag. Und einem Ladestands-Sensor.

Ein Ladestand in Prozent, direkt als Entität. Nach Wochen erfolglosen Herumprobierens an der Fahrzeug-Cloud des Herstellers sah das aus wie ein Lottogewinn. Ich habe schon überlegt, wo überall im Haus ich den Wert einbaue.

Dann hat Marcus erklärt, woher die Zahl kommt: Der Stromanbieter hat keinerlei Datenverbindung zu diesem Auto. Der Ladestand wird in der App von Hand eingetragen. Von Marcus.

Technisch ist das ein tadelloser Sensor. Er hängt an einer echten Subscription, er aktualisiert sich zuverlässig, er hat eine Einheit und eine Geräteklasse. Er spiegelt bloß ausschließlich die Eingabe zurück, die ein Mensch vorher hineingetippt hat. Eine Automation, die darauf reagiert, reagiert auf Marcus’ Gedächtnis.

Man kann aus einem manuell gepflegten Wert alles Mögliche bauen. Nur keinen Messwert.