Günstigste Stunden ohne Regler: Der Hub meldet, Home Assistant entscheidet

Fragen Sie Home Assistant, welche Stunden morgen am günstigsten sind, und Sie landen an einer Stelle, die Sie nicht vorhatten: einer Planer-Integration, einem Template-Sensor mit einem Makro darin, einer sortierten Liste der Stunden und einer Automation, die die aktuelle Stunde mit dem Ergebnis vergleicht. Es funktioniert, und Menschen pflegen genau dieses Setup seit Jahren. Es sind aber viele bewegliche Teile für eine Frage mit einer Ein-Wort-Antwort: Ist jetzt eine gute Zeit?

Der Hub beantwortet diese Frage selbst. Er kennt die Preise für jede 15-Minuten-Periode, kann daher ermitteln, welche Perioden günstig sind, und veröffentlicht das Ergebnis als Zeitfenster: offen oder geschlossen, bis wann und wann das nächste beginnt.

Was er nicht tut, ist, danach zu handeln. Dieser Teil liegt bei Ihnen.

Was ein Zeitfenster ist

Sie beschreiben die Regel; der Hub wertet sie gegen die Preise aus, die er hat.

Zwei Niveaus statt eines bei der ersten Regel ist keine Pedanterie: Ein Preis, der um eine einzelne Zahl schwankt, würde das Fenster in jeder Periode an- und ausschalten. Lassen Sie sich einen Abstand.

Neben den Regeln gibt es zwei einfache Flags — Kaufpreis ist günstig unter und Verkaufspreis ist niedrig unter —, die etwas über den Preis genau jetzt aussagen, ohne Planung und ohne Hysterese. Das Verkaufs-Flag ist auf einer Anlage mit eigener Erzeugung das nützlichere: Es ist das Signal, dass Ihr eigener Strom mehr wert ist, verbraucht als eingespeist zu werden.

Acht Regeln sind das Maximum. Eine neunte wird abgelehnt, statt stillschweigend verworfen zu werden.

Den Zustand lesen, nicht die Nachricht

Dies ist der eine Hinweis, der darüber entscheidet, ob Ihre Automation funktioniert.

Der Zustand des Zeitfensters wird bei jeder 15-Minuten-Grenze erneut veröffentlicht, und sofort, wenn sich etwas ändert — ein Fenster öffnet oder schließt sich, neue Preise treffen ein, eine Regel wird bearbeitet. Es ist ein Zustand, keine Ankündigung.

Bauen Sie also auf dem aktuellen Wert auf. Eine Automation, die jede Veröffentlichung als Ereignis behandelt, feuert während eines langen Fensters immer wieder und verpasst den Übergang, der geschah, während sie neu startete. Eine Automation, die fragt „ist dieses Fenster aktiv?“, stimmt in jedem Moment, auch in dem Moment, in dem sie zurückkehrt.

Auslesen aus Home Assistant: die zwei Wege, so wie es hier steht

Die ehrliche Antwort hängt davon ab, wie Sie den Hub betreiben.

Über den eigenen Weg des Hubs, per MQTT, kommt der Zustand als retained-Nachricht auf rbgrid/<mac>/price an — unter einem Kilobyte, mit einem Eintrag pro Regel: ihr Name, ob sie aktiv ist, bis wann und wann sie als Nächstes beginnt. „Retained“ ist das wichtige Wort: Wer sich später verbindet, erhält den aktuellen Zustand sofort, sodass ein Neustart Sie nichts kostet. Die Nachricht ist JSON, daher ist die übliche Form ein MQTT-Sensor mit einem Template, das die Regel herauszieht, die Sie interessiert — die Referenz des Hubs enthält ein ausgearbeitetes Beispiel genau dafür, mit den Feldnamen.

Auf dem ESPHome-Weg sind die Zeitfenster ebenfalls Entitäten: ein Binärsensor pro Regel, auf dem Gerät des Hubs, on, solange das Fenster offen ist, mit Angabe, wann es schließt und wann das nächste beginnt. Daneben stehen ein Preis-ist-günstig-Flag, ein Verkaufspreis-ist-niedrig-Flag und ein Rang-Sensor für die aktuelle Periode. Sie aktualisieren sich jede Minute und sofort nach jedem Preisereignis des Hubs.

Eine Automation ist also auf beiden Wegen eine Zustandsbedingung auf einer Entität. Zum Rang, da er an beiden Stellen vorkommt: Er zeigt, wo die aktuelle Periode unter den bekannten Perioden des heutigen Tages steht — 1 ist die günstigste, und der Nenner ist die Anzahl der Perioden, für die der Hub bisher Preise hat.

⚠️ Wenn Ihre Integration älter ist, sind die Zeitfenster keine Entitäten, und der Zustand muss abgefragt werden — über eine Aktion, die dieselbe Struktur zurückgibt, die die MQTT-Nachricht trägt. Das Rezept dafür ist ein trigger-basierter Template-Sensor, und es funktioniert nach wie vor; es ist nur nicht mehr nötig. Aktualisieren Sie die Integration, und der Schritt entfällt.

Eine Grenze sollten Sie beachten: Die Sensoren pro Regel wurden im Test verifiziert, nicht beim Öffnen eines Fensters an einem laufenden Hub beobachtet, weil die Testbank abgeschaltet war, bevor ein Fenster kam. Die Zuordnung ist geprüft; der Anblick davon ist noch nicht berichtet.

Worauf eine Automation hinausläuft

Die Verdrahtung unterscheidet sich, wie oben beschrieben. Die Logik unterscheidet sich nicht, und sobald der Zustand dort liegt, wo Ihre Automation ihn sehen kann, sind es drei Zeilen:

1. Ist das Fenster Boiler aktiv? — Fragen Sie den Zustand ab.
2. Ja → Ihre Automation schaltet den Schalter des Boilers ein.
3. Nein → Ihre Automation schaltet ihn aus.

Jede Entscheidung nach Schritt 1 liegt bei Home Assistant. Der Hub hat einen Wahrheitswert und den Grund dafür beigesteuert.

Außerdem werden Öffnungen und Schließungen auch im eigenen Protokoll des Hubs festgehalten, sodass Sie danach nachlesen können, was passiert ist, während Sie nicht hingesehen haben:

price: window 'Boiler' on until <time>
price: window 'Boiler' off, next <time>

Der eine Blueprint, der mitgeliefert wird, und wofür er da ist

Die Integration bringt zwei Blueprints mit. Der erste, RBgrid — notify on hub events, tut, was sein Name sagt: Er benachrichtigt. Seine Standardliste der Ereignisarten deckt Hardware- und Verbindungsereignisse ab — Rückfluss, ein Modul, das fehlt oder zurückkehrt, ein Knoten offline oder online, ein blockierter Bus, Firmware, Fehler.

Preisereignisse stehen nicht in dieser Standardliste. Sie können die Art price selbst hinzufügen, und Sie werden dann über Zeitfenster benachrichtigt — zusammen mit jedem anderen Preisereignis, einschließlich jedes erfolgreichen Abrufs, weil alle dieselbe Art haben und sich nicht trennen lassen.

Der zweite, RBgrid — cheap window turns a switch on and off, nimmt einen Fenster-Sensor und einen Schalter, eine Lampe, einen Ventilator oder einen Input-Boolean, mit einer Option zur Umkehrung. Es lohnt sich, genau zu sein, was das bedeutet, weil es dieselbe Grenze ist wie überall in diesem Artikel: die Automation schaltet; der Hub meldet. Der Blueprint ist eine vorbereitete Automation, keine Fähigkeit des Zählers.

Was der Hub niemals tut

• Er schaltet nichts. Es gibt kein Relais an ihm und keine Einstellung, die ihn etwas einschalten lässt.
• Er plant nicht über die Regel hinaus für Sie. Eine Regel ist eine Beschreibung, welche Perioden sich qualifizieren; der Hub wendet sie an und sagt, was das Ergebnis ist.
• Es gibt keine Fenster auf der Verkaufsseite. Fenster verwenden den All-in-Kaufpreis. Für die Einspeisung ist das Flag Verkaufspreis ist niedrig das Signal.
• Nichts geschieht ohne eine gestellte Uhr. Regeln beschreiben Stunden und Tage; ein Hub, dessen Uhr nicht synchronisiert ist, kann sie nicht einordnen.

Wenn es nicht öffnete, obwohl Sie es erwarteten

• Prüfen Sie, ob die Preise angekommen sind — und lesen Sie den nächsten Absatz, denn das ist der häufige Fall. Eine Regel über die günstigsten Perioden eines Zeitraums braucht die Preise für diesen Zeitraum. Das Protokoll des Hubs sagt, was wann gespeichert wurde.
• Prüfen Sie die beiden Niveaus. Gleiche Niveaus lassen ein Fenster flackern; ein zu großer Abstand hält es geschlossen.
• Prüfen Sie die Uhr. Siehe oben — sie ist die stille Ursache.
• Prüfen Sie, welchen Preis die Periode verwendet hat. Wenn die Quelle ausfiel und stattdessen Ihr Tarif die Periode abdeckte, wurde das Fenster gegen den Tarifpreis ausgewertet, und das ist eine andere Zahl. Das Protokoll nennt die Quelle für jede Periode.

Die Nacht, in der die Preise für morgen spät kamen

Dies verdient einen eigenen Absatz, weil es ein Fenster erzeugt, das falsch aussieht, es aber nicht ist.

Der Hub wartet nicht auf Preise und überspringt die Stunden nicht, für die er keinen Marktpreis hat. Er ordnet jede Periode des Fensters nach dem Preis, den er für diese Periode berechnen würde — zuerst die Marktquelle, dann Ihre Ersatzquelle, dann der Zonenpreis Ihres Tarifs mit seinen Gebühren und der MwSt. Danach entscheidet er laufend neu, sodass wenn die Preise eintreffen, das Fenster in die Stunden wandert, die tatsächlich am günstigsten sind, unter den noch bevorstehenden.

Daraus folgen zwei Konsequenzen, und beide sind ehrliches Verhalten, kein Fehler:

• das Fenster kann an einer Stelle öffnen, mit der Sie nicht gerechnet haben — am Abend, wenn die Marktpreise dort die Tarifpreise Ihres Tarifs unterbieten, oder nachts zum Tarifpreis, wenn nichts anderes bekannt ist;
• das Fenster kann kürzer laufen, als Sie angefordert haben. Eine bereits gelaufene Auswahl wird nicht rückgängig gemacht; wenn die neue Menge der Günstigsten Perioden enthält, die bereits vorbei sind, gelten sie als gewählt und können nicht mehr laufen, und der Hub füllt die Nacht nicht mit zusätzlichen Perioden auf. Der nächste Tag ist normal.

Wenn die Preise überhaupt nicht eintreffen, wird alles zum Tarifpreis eingeordnet, und das Fenster landet in den günstigsten Tarifperioden — typischerweise der Nachtzone, falls Ihr Tarif eine hat.

In jedem dieser Fälle hat sich das Fenster für die Daten, die der Hub zu dem Zeitpunkt hatte, korrekt geöffnet. Das Ereignisprotokoll zeigt jede Verschiebung, und die Quellenspalte des Preisprotokolls zeigt, welche Perioden aus dem Tarif statt vom Markt bepreist wurden.

Wo Sie mehr lesen können

• Price notifications and cheap windows — die vollständige Referenz: jeder Parameter, die veröffentlichten Felder und das ausgearbeitete Beispiel.
• Where your price comes from — wie eine Periode überhaupt zu ihrem Preis kommt.
• Events — das eigene Protokoll des Hubs, einschließlich der Zeilen zu Fenstern oben.
• Zwei Wege, RBgrid zu betreiben — die Wahl des Weges, von der das letzte Drittel dieses Artikels abhängt.