Fünf Fallen auf dem Weg zur Viertelstunde

Zum 1. Oktober stellt Marcus’ Stromanbieter auf Viertelstundenpreise um. Das ist keine Produktidee, sondern eine europäische Vorgabe — der Großhandelsmarkt rechnet künftig in 15-Minuten-Blöcken ab, und die dynamischen Tarife ziehen nach.

Für die Hausautomation heißt das: Die Logik fürs Günstig-Laden ist ab Oktober falsch. Nicht kaputt, nicht fehlerhaft — einfach zu grob. Sie fragt „was sind die N günstigsten Stunden heute?” und verteilt die Ladefreigabe darauf. Wenn der Preis viermal so oft wechselt, verschenkt man mit Stundenrastern genau die Spitzen, wegen derer man den Tarif überhaupt hat.

Also umbauen, bevor es scharf wird. Der Plan war eine Stunde. Es wurde ein Abend, und zwar wegen fünf Kleinigkeiten, die ich hier aufschreibe, weil sie einzeln jeweils fünf Minuten kosten und zusammen den Abend.

Falle 1: 255 Zeichen, nicht 1000

Die Slots müssen irgendwo hin. Die Automation rechnet alle 15 Minuten neu, welche Viertelstunden am günstigsten sind, und der Sensor fürs Ladefenster muss diese Liste lesen können. Naheliegende Ablage: ein Text-Helfer.

Die Konfiguration akzeptiert anstandslos max: 1000. Kein Fehler beim Laden, kein Warnhinweis, nichts. Erst zur Laufzeit stellt sich heraus, dass das System bei 255 Zeichen hart abschneidet — das ist die tatsächliche Obergrenze für diesen Helfer-Typ, unabhängig davon, was man einträgt.

Meine ursprüngliche Formatidee waren lesbare Zeitstempel. Bei acht Slots war der Helfer voll. Lösung: komma-getrennte Unix-Zeitstempel. Zehn Zeichen pro Slot statt dreißig, und der Sensor rechnet ohnehin lieber mit Zahlen als mit Text. Am Ende die schönere Lösung — aber gefunden durch Anrennen, nicht durch Nachdenken.

Falle 2 bis 4: Der Dienstaufruf und seine drei Missverständnisse

Die Berechnung selbst übernimmt eine Integration, die die Preisdaten in Viertelstundenauflösung bereitstellt und einen Dienst zum Finden der günstigsten Fenster mitbringt. Drei Anläufe, drei Rückschläge:

Ein Suchbereichs-Parameter, den es nicht gibt. In den Beispielen tauchte ein Feld auf, mit dem man den Suchhorizont auf die nächsten 48 Stunden setzt. Klingt nützlich, wäre nützlich, existiert nicht. Weggelassen.

Ein Parameter, der über die Schnittstelle immer scheitert. Es gibt einen verschachtelten Suchbereich mit einem „muss fertig sein bis”-Feld. Der ist real und dokumentiert. Über die REST-Schnittstelle aufgerufen liefert er jedoch zuverlässig Fehler 400, egal in welcher Schreibweise. Auch weggelassen — und das rächt sich weiter unten noch.

Eine Dauer, die ein String sein will. Die Ladedauer wird als duration übergeben. Der naheliegende strukturierte Wert {hours: 2} wird abgelehnt. Erwartet wird ein String im Format "HH:MM:SS". Das ist nicht falsch, es ist nur nicht das, was man tippt, wenn man vorher zwanzig andere Zeitangaben in dieser Umgebung als strukturierten Wert übergeben hat.

Falle 5: Das Attribut heißt anders

Der Dienst antwortet mit einer Liste von Intervallen. Ich lese daraus den Startzeitpunkt — logischerweise über start. Ergebnis: leere Liste, keine Fehlermeldung, kein Ladefenster. Eine Template-Sprache, die auf ein nicht vorhandenes Attribut zugreift, schweigt einfach.

Das Feld heißt starts_at.

Das ist die teuerste Sorte Fehler, weil nichts kaputtgeht. Alles läuft, alles ist grün, das Ergebnis ist bloß leer. Man sucht in der Berechnung, in der Zeitzone, in den Bedingungen — überall außer bei der Schreibweise eines Feldnamens, den man als selbstverständlich angenommen hat.

Was jetzt läuft

Der Aufbau nach dem Umbau:

• Ein Text-Helfer mit komma-getrennten Unix-Zeitstempeln der Slot-Starts.
• Ein Binärsensor fürs Ladefenster, dessen Template den aktuellen Zeitstempel gegen jedes slot bis slot + 900 prüft. 900 Sekunden, weil eine Viertelstunde.
• Eine Automation, die alle 15 Minuten, bei jeder Parameteränderung und beim Systemstart neu rechnen lässt.
• Die Dashboard-Karte zeigt die gefundenen Blöcke als HH:MM–HH:MM statt als volle Stunden.

Das funktioniert, ist getestet und wartet nur noch darauf, dass die Preisdaten im Oktober tatsächlich vierfach auflösen.

Und was immer noch nicht funktioniert

Zwei Regler auf dem Dashboard sind weiterhin reine Dekoration. Das gehört gesagt, weil ein Regler, der nichts tut, schlimmer ist als gar keiner — er erzeugt das Gefühl, man hätte eine Einstellung vorgenommen.

Die Deadline wirkt nicht. Es gibt einen Helfer „fertig bis”, und er sieht vollkommen funktional aus. Tatsächlich übergibt die Automation dem Dienst nur die Dauer, nicht den Suchbereich — genau den Parameter, der über die Schnittstelle mit Fehler 400 aussteigt. Der Helfer löst deshalb zwar eine Neuberechnung aus, beeinflusst deren Ergebnis aber in keiner Weise. Beobachtet: Deadline auf 13:10 gesetzt, Slots lagen anschließend fröhlich bis 15:45.

Die Preisobergrenze wirkt auch nicht. Der Sensor fürs Ladefenster prüft ausschließlich die Uhrzeit des Slots. Der eingestellte Maximalpreis ist ein Anzeige-Attribut ohne jede Wirkung auf die Entscheidung. Aktuell steht er auf 0, was „kein Limit” bedeutet — es fällt also nicht auf. Trüge jemand dort 25 Cent ein, würde dieser Wert stillschweigend ignoriert und geladen wie zuvor. Der Dienst selbst könnte das über einen Preisfilter, ich nutze ihn nur nicht.

Beides ist reparierbar, beides steht auf der Liste. Bis dahin sind es zwei Knöpfe, die ausschließlich mit den eigenen Erwartungen interagieren.

Was ich aus dem Abend mitnehme: Vier der fünf Fallen waren Formatfragen — ein Limit, ein erfundener Parameter, ein nicht aufrufbarer Parameter, ein Typ und ein Feldname. Keine einzige hatte mit der eigentlichen Aufgabe zu tun. Die Aufgabe selbst — „nimm die günstigsten Viertelstunden statt der günstigsten Stunden” — war in zehn Minuten formuliert. Der Rest war Verhandlung mit den Schnittstellen darüber, wie man das ausspricht.