Eine Wärmepumpe ist meist die größte einzelne Last im Haus und diejenige, deren Kosten sich am schwersten schätzen lassen. Sie läuft, wenn das Wetter es verlangt, nicht wenn Sie es verlangen, und bei einem Tarif mit Tag- und Nachtpreis hängt ihre Rechnung deshalb von Stunden ab, die Sie nie gewählt haben. Die Messung auf dem eigenen Stromkreis beantwortet die erste Frage — was sie tatsächlich kostet. Sobald Home Assistant weiß, in welcher Tarifzone der Hub gerade ist, können Sie mit der zweiten Frage etwas anfangen.
Was Sie brauchen:
- ein RBgrid-Hub, bei dem der Stromkreis der Wärmepumpe als eigener Messpunkt erfasst ist;
- ein Tarifplan, der am Hub eingegeben ist — wenn Sie das noch nicht getan haben, beginnen Sie mit Ihrem eigenen Zeittarif;
- der Hub auf Ihre Zeitzone eingestellt, mit synchronisierter Uhr: Jede Zonengrenze in dieser Anleitung wird anhand der Hub-Uhr aufgelöst, nicht anhand Ihrer (welche Zeitzone der Hub verwenden sollte);
- ein MQTT-Broker, mit Home Assistant am Hub angebunden. Diese Anleitung beginnt, nachdem das funktioniert. Falls nicht, richtet Ein Stromzähler für Home Assistant das Schritt für Schritt ein — den Broker, das Formular Settings → Home Assistant des Hubs und die ersten Entitäten — und dann kommen Sie hierher zurück.
Zur Verdrahtung und zur Dimensionierung der Stromzangen behandelt der Dreiphasenaufbau in was Wärmepumpe und E-Auto kosten eine Wärmepumpe durchgehend.
Sicherheit. Für jede Arbeit im Inneren eines Elektrokastens rufen Sie eine Elektrofachkraft.
1. Geben Sie der Wärmepumpe einen eigenen Messpunkt
In Management → Points binden Sie den Kanal der Wärmepumpe und setzen ihre Role auf Heating/cooling. Die Rolle sagt der App, dass es sich um eine Last mit eigenem Zeitplan handelt: Die Standby-Last-Karte etwa nimmt Heiz- und EV-Ladeleitungen aus der Grundlast des Hauses heraus, bevor sie abschätzt, was dauerhaft läuft, denn eine Pumpe, die um 03:00 läuft, ist kein Standby.
Benennen Sie den Messpunkt, bevor er überhaupt in Home Assistant ankommt. Das ist wichtiger, als es aussieht — siehe §3.
Einphasige Pumpen sind ein Messpunkt. Eine Dreiphasenpumpe hat je eine Stromzange pro Leiter, jede am Basic-Modul dieser Phase, als drei Messpunkte gebunden und gruppiert; der Dreiphasen-Leitfaden führt Sie durch den Vorgang.
2. Was die App Ihnen zeigt
Monitoring → Economics zeigt bei ausgewählter Wärmepumpe ihre Energie und ihre Kosten für eine Stunde, heute, gestern, die letzten 7 Tage, diesen Monat, letzten Monat oder dieses Jahr. Die Kosten sind diejenigen, die der Hub berechnet hat, während die Energie verbraucht wurde: alle 15 Minuten, zum Preis der damals gültigen Zone, gespeichert zusammen mit dem Stundendatensatz. Nachträglich wird nichts neu bepreist. Ändert Ihr Anbieter einen Tarif, bleibt also, was die Pumpe letzten Winter gekostet hat, bei dem, was sie gekostet hat.
History mit der Kennzahl Money stellt sie für denselben Zeitraum neben Ihre anderen Stromkreise, und Download CSV nimmt die Zahlen mit.
Zu den Kosten nach Zone: Economics zeigt diese Aufteilung, aber lesen Sie sie für das, was sie ist — eine laufende Summe seit dem letzten Neustart des Hubs, die dem Zeitraumauswahlfeld nicht folgt. Sie beantwortet „wie sieht die Aufteilung gerade aus“, nicht „was hat mich die Pumpe in der Nachtzone im Oktober gekostet“. Eine Monatsansicht der Kosten nach Zone gibt es nicht; für einen Monat nehmen Sie das Zeitraumauswahlfeld und die Summe.
Und bevor Sie zur CSV greifen, um es selbst zu tun: Die gespeicherten Datensätze enthalten Energie und Geld pro Zeitraum, aber kein Zonenfeld — die Aufteilung existiert nur in dieser laufenden Summe. Der Vergleich Nacht gegen Tag für einen Monat ist also keine Ansicht, die Ihnen fehlt; es ist eine Zahl, die der Hub nicht speichert.
3. An Home Assistant senden
Bei verbundenem MQTT erscheint jeder gebundene Messpunkt als eigenes Gerät mit acht Sensoren: Strom, Leistung, Blindleistung, Leistungsfaktor sowie Energie ein und aus, jeweils als Lebensdauer- und Tageszähler. Die Energie geht direkt unter Individual devices ins Energy dashboard — kein utility_meter, kein Template-Sensor. Verwenden Sie den Lebensdauerzähler Energy In, nicht den (Day)-Zähler: Die Tageszähler werden um Mitternacht der Ortszeit des Hubs zurückgesetzt, während die Lebensdauersummen garantiert nie abnehmen und einen Neustart oder ein Firmware-Update im eigenen Speicher des Hubs überstehen. Ein Werksreset löscht sie, und das Löschen des Messpunkts ebenfalls.
Zwei Dinge, die Ihnen einen Abend ersparen:
- Die Entity-ID wird bei der ersten Erkennung festgeschrieben. Benennen Sie den Messpunkt danach in der App um, ändert sich nur der Anzeigename: Ein Messpunkt, der zuerst als „UI7 I2“ erkannt wurde, behält
sensor.rbgrid_ui7_i2_power. Sie können die Entitäten in Home Assistant umbenennen, es ist also nicht endgültig — es ist nur Arbeit, die Sie sich sparen können. Benennen Sie den Messpunkt bevor Sie den Broker verbinden, oder benennen Sie die Entitäten in HA einmal um. - Die Rolle wandert nicht mit. Heating/cooling ist ein Begriff der App; in Home Assistant sieht das Gerät der Wärmepumpe genauso aus wie jeder andere Messpunkt. Was Sie mit der Rolle vorhaben, erledigen Sie auf der RBgrid-Seite.
4. Die Tarifzone für HA sichtbar machen
Der Hub veröffentlicht seine aktuelle Tarifzone, aber nicht als erkannte Entität — die Erkennung erfasst die Messwerte, nicht den Tarif. Die Zone steckt im Telemetrie-Frame des Hubs, der alle drei Sekunden veröffentlicht wird und nicht retained ist. Ein MQTT-Sensor holt sie ab. <MAC> sind die zwölf Hex-Zeichen des Hubs in Kleinbuchstaben — Topics unterscheiden Groß- und Kleinschreibung, und das Präfix rbgrid/ ist fest:
mqtt:
sensor:
- name: "Tariff Zone"
unique_id: ha_rbgrid_<MAC>_tariff_zone
default_entity_id: sensor.rbgrid_tariff_zone
state_topic: "rbgrid/<MAC>/telemetry"
value_template: >-
{% set t = value_json.get('system', {}).get('tariff') or {} %}
{{ t.zone if t.zone is defined else None }}
expire_after: 30
availability:
- topic: "rbgrid/<MAC>/status"
payload_available: "online"
payload_not_available: "offline"
json_attributes_topic: "rbgrid/<MAC>/telemetry"
json_attributes_template: >-
{% set t = value_json.get('system', {}).get('tariff') or {} %}
{{ {'plan_active': t.zone is defined,
'time_src': value_json.get('time_src'),
'buy_rate': t.get('buy_rate'), 'sell_rate': t.get('sell_rate'),
'currency': t.get('currency'),
'placeholder': t.get('placeholder', false)} | tojson }}
device:
identifiers: ["<MAC>"]
- name: "Tariff Buy Rate"
unique_id: ha_rbgrid_<MAC>_tariff_buy_rate
default_entity_id: sensor.rbgrid_tariff_buy_rate
state_topic: "rbgrid/<MAC>/telemetry"
value_template: >-
{% set t = value_json.get('system', {}).get('tariff') or {} %}
{{ t.buy_rate if t.buy_rate is defined else None }}
unit_of_measurement: "EUR/kWh"
expire_after: 30
availability:
- topic: "rbgrid/<MAC>/status"
payload_available: "online"
payload_not_available: "offline"
device:
identifiers: ["<MAC>"]
Drei Details darin sind keine Zierde.
Die Templates sind abgesichert, und das müssen sie auch sein. Die Tariffelder fehlen im Frame, bis am Hub ein Plan existiert — und den Broker zu verbinden, bevor Sie einen Tarif eingeben, ist eine ganz normale Reihenfolge. Ein ungeschütztes value_json.system.tariff.zone schlägt beim fehlenden Schlüssel fehl, und Home Assistant protokolliert nichts: MQTT verschluckt Template-Fehler still. Schlimmer noch: Der Sensor setzt expire_after neu, bevor er das Template auswertet, sodass ein Hub ohne Plan den Sensor unbegrenzt mit dem letzten Wert am Leben hält — eine veraltete Zone, die völlig gesund aussieht. Die abgesicherte Version meldet stattdessen unknown, ein Zustand, bei dem Ihre Automatisierung sich weigern kann zu handeln.
Der zweite Sensor ist der aktuelle Preis, und dafür gibt es einen Grund, den es sich auszusprechen lohnt. Das Energy dashboard von Home Assistant kann eine Entität als aktuellen Preis für eine Quelle übernehmen, daher liefert buy_rate des Hubs Ihrem Dashboard die richtige Zahl für die Zone, in der Sie sich gerade befinden — so werden die Kosten auf der Seite von Home Assistant berechnet, mit Ihrem eigenen Tarif, für alles, was Sie dort bereits haben. RBgrid führt das Geld je Stromkreis; HA behält das Gesamtbild des Hauses, das es schon immer hatte.
plan_active ist Ihr einziges Anzeichen. Da nichts im Protokoll erscheint, ist dieses Attribut der Weg zu sehen, ob der Hub tatsächlich einen Tarif hat. Lohnt sich auf einem Dashboard, wenn Sie sich auf irgendetwas davon verlassen wollen.
default_entity_id legt die Entity-ID fest. MQTT-Entitäten leiten ihre ID aus dem Gerätenamen plus dem Entitätsnamen ab; ohne diesen Eintrag landet dieser Sensor bei sensor.rbgrid_system_tariff_zone, und jede Automatisierung unten beobachtet still nichts. (object_id erledigte dieselbe Aufgabe und ist ab HA 2025.12 veraltet.) Das Präfix ha_ in unique_id hält ihn vom eigenen Namensraum der Firmware fern, sodass bei einem künftigen Release, das selbst eine Zonen-Entität erkennt, beide nebeneinander bestehen und Sie diesen Block löschen.
expire_after: 30 bleibt wichtig: Der Frame wird nicht retained, daher wird der Sensor, wenn der Hub verstummt, unavailable, statt eine Zone festzuhalten, die vielleicht nicht mehr stimmt.
Auch das Verfügbarkeits-Topic leistet echte Arbeit: Der Hub veröffentlicht online bei jeder Verbindung retained und registriert ein MQTT-Last-Will, damit der Broker offline veröffentlicht, falls er ohne Abschied abbricht. Ein Home Assistant, das neu startet, erfährt daher den Zustand des Hubs sofort, statt auf einen Frame zu warten. Und wenn Ihr Broker neu startet und seine retained Nachrichten verliert, veröffentlicht der Hub bei der Wiederverbindung seine gesamte Discovery-Menge neu, sodass Ihre Messpunkt-Entitäten nicht verwaisen.
Eine Falle, bevor Sie darauf aufbauen. time_src zeigt sntp erst, nachdem der Hub einen NTP-Server erreicht hat. Eine Uhr, die Sie von Hand über Ihren Browser stellen, meldet weiterhin none, obwohl sie richtig geht — bei einem Hub ohne Internetzugang wird also die Bedingung im nächsten Abschnitt nie erfüllt, und die Automatisierung feuert nie, still und für immer. Bleibt time_src auf none, dann ist das die Spur: der Weg des Hubs zu einem Zeitserver, nicht die Automatisierung.
Der Sensor liefert einen von acht Werten — NIGHT, MORNING_PEAK, DAY, EVENING_PEAK, LATE_EVENING, WEEKEND, HOLIDAY, CRITICAL_PEAK — in genau dieser Schreibweise. Es ist der Typ der aktiven Zone, nicht der Name, den Sie ihr gegeben haben; zwei Zonen unterschiedlichen Typs zum selben Preis werden daher trotzdem unterschiedlich angezeigt. Ohne Tarifplan am Hub fehlt das Feld im Frame ganz, und der abgesicherte Sensor zeigt unknown mit plan_active: false.
Sie erkennen, dass es funktioniert, wenn Developer Tools → States den neuen Sensor mit einem Zonennamen wie NIGHT zeigt, und unter seinen Attributen plan_active: true, time_src: sntp und placeholder: false. Bleibt er bei unknown, ist das Topic oder der Template-Pfad für Ihren Hub falsch: Abonnieren Sie rbgrid/# in einem beliebigen MQTT-Client und vergleichen Sie einen echten Frame mit dem Template.
Die Attribute sind aus einem Grund dabei, und der ist schärfer, als er aussieht. Der Hub ermittelt die Zone aus seiner eigenen Uhr, auch wenn diese Uhr noch nicht synchronisiert ist — nach einem Start ohne SNTP steht sie nahe 1970 plus Betriebszeit, daher können die gemeldete Zone und der berechnete Preis schlicht falsch sein. Während er wartet, hält er das Feld nicht zurück. time_src zeigt Ihnen den Unterschied, und der nächste Abschnitt verweigert jede Aktion, bis dort sntp steht.
⚠️ Nach jedem Neustart speichern Sie Ihren Tarif erneut, bevor Sie diesen Werten trauen — oder sie etwas steuern lassen. Bei v1.1.4 kommt ein Hub, der neu startet, mit seinem eingebauten Platzhalterplan Test Day/Night zurück, bis Sie Tariffs öffnen und Save drücken (the tariff guide hat die Details). Der Haken für diesen Artikel: Solange das gilt, zeigt die Zone weiterhin ein durchaus plausibles
NIGHT, undtime_srczeigt weiterhinsntp. Die Prüfung im nächsten Abschnitt besteht also, und Ihre Automatisierung steuert die Wärmepumpe nach den Grenzen des Testplans. Stellen Sie sich einen Stromausfall um 02:00 vor.
5. Automatisieren — in Home Assistant, am Sollwert
RBgrid misst und meldet. Es schaltet nichts: kein Relais, kein Schütz, keinen Ausgang irgendeiner Art. Alles Folgende läuft auf der Seite von Home Assistant, gegen eine Klima-Entität, die Sie bereits haben.
automation:
- alias: "Heat pump: follow tariff zone (reconcile)"
mode: single
max_exceeded: silent
triggers:
- trigger: state
entity_id: sensor.rbgrid_tariff_zone
to: ~
- trigger: state
entity_id: sensor.rbgrid_tariff_zone
attribute: placeholder
- trigger: homeassistant
event: start
- trigger: time_pattern
minutes: "/15"
conditions:
- condition: state
entity_id: sensor.rbgrid_tariff_zone
state: ["NIGHT", "DAY"]
- condition: template
value_template: "{{ state_attr('sensor.rbgrid_tariff_zone', 'time_src') == 'sntp' }}"
- condition: template
value_template: "{{ state_attr('sensor.rbgrid_tariff_zone', 'placeholder') is sameas false }}"
actions:
- variables:
target: "{{ 21 if is_state('sensor.rbgrid_tariff_zone', 'NIGHT') else 19 }}"
- condition: template
value_template: "{{ (state_attr('climate.heat_pump', 'temperature') | float(0)) != (target | float) }}"
- action: climate.set_temperature
target: { entity_id: climate.heat_pump }
data: { temperature: "{{ target }}" }
- alias: "RBGrid: placeholder tariff plan active"
mode: single
triggers:
- trigger: state
entity_id: sensor.rbgrid_tariff_zone
attribute: placeholder
to: true
actions:
- action: persistent_notification.create
data:
notification_id: rbgrid_placeholder_plan
title: "RBGrid: placeholder tariff plan"
message: >-
The hub is running the built-in Test Day/Night plan. Re-save your tariff
plan in the RBgrid app; zone automations stay paused until then.
Der Platzhalter-Schutz ist die dritte Bedingung, und es ist diejenige, auf die die meisten nicht kommen. Ein Hub, der auf v1.1.4 neu startet, kommt mit seinem eingebauten Plan Test Day/Night zurück, bis Sie Ihren eigenen erneut speichern — und solange das gilt, zeigt die Zone weiterhin plausibel und die Uhr meldet weiterhin Synchronisation, sodass alle naheliegenden Prüfungen bestehen. Würde man darauf reagieren, steuerte man die Wärmepumpe nach Testpreisen.
Der Hub sagt es allerdings, wenn Sie fragen: Solange der eingebaute Plan aktiv ist, trägt die Telemetrie placeholder: true, und der Schlüssel fehlt schlicht, sobald Ihr eigener Plan gespeichert ist. Die Bedingung ist mit Absicht streng — sie handelt nur bei einem ausdrücklichen false, nie bei einem fehlenden Attribut —, sodass ein Sensor, der es Ihnen nicht sagen kann, genauso behandelt wird wie ein Hub, der auf dem Testplan läuft.
Die zweite Automatisierung tut nichts anderes, als Ihnen zu sagen, warum alles still geworden ist. Und weil die Abgleich-Automatisierung auch auf dieses Attribut auslöst, zieht der Sollwert in dem Moment, in dem Sie Ihren Plan in der App erneut speichern, sofort nach, statt auf den nächsten Viertelstunden-Takt zu warten.
Richten Sie das auf einen Raumthermostaten, und prüfen Sie das vorher. climate.set_temperature setzt eine Entität mit einem einstellbaren Raumsollwert in °C voraus. Viele Wärmepumpen-Integrationen stellen etwas anderes bereit: eine Vorlauf- oder Wassertemperatur, eine Witterungskompensationskurve, bei der ein Sollwert nichts bewirkt, eine Entität nur mit Voreinstellungen ohne einstellbare Temperatur — oder den Warmwasserspeicher. Eine 21 an einer Vorlauftemperatur-Entität ist kein Anstoß; an einem Warmwasserspeicher ist es ein kalter Speicher und ein Legionellenlauf, den Sie nicht vorgesehen hatten.
Öffnen Sie Developer Tools → States, suchen Sie Ihre Klima-Entität und bestätigen Sie, dass sie ein Attribut temperature im Bereich hat, den Sie erwarten, bevor Sie irgendetwas auf sie schreiben lassen.
Ergänzen Sie sie durch die spiegelbildliche Automatisierung für die Tageszone, die die Temperatur ein bis zwei Grad niedriger setzt, oder climate.set_preset_mode: eco, falls Ihr Gerät das hat.
Prüfen Sie, ob NIGHT wirklich Ihre günstige Zone ist. Der Sensor meldet den Typ der Zone, nicht den Namen, den Sie ihr gegeben haben, und der Typ entscheidet, was passiert:
- Hat Ihr Tarif eine Weekend-Zone, hat sie an ihren Tagen Vorrang vor Night, und
WEEKENDsteht nicht in der obigen Bedingung — ab dem Beginn dieser Zone entscheidet die Automatisierung also nichts mehr. Sie fällt nicht auf den Tagessollwert zurück: Der Sollwert behält, was ihm zuletzt vorgegeben wurde; wenn also die Freitagnacht den Nachtsollwert gesetzt hat, hält das Haus diesen Sollwert, bis die Wochenendzone endet. Ob das Ihnen passt, ist eine Frage nach Ihrem Wochenendpreis, den der Name der Zone nicht beantwortet — siehe unten. - Kommt Ihr günstiger Tarif in zwei Fenstern — eine günstige Nacht und ein günstiger Mittag, was zu einer Wärmepumpe gut passt —, dann kommt das zweite als anderer Typ, etwa
LATE_EVENING, und braucht einen eigenen Auslöser. Zwei günstige Zeitfenster an einem Tag erklärt, wie ein solcher Plan aufgebaut wird. - Bei einem Dreizonentarif kann „die Tageszone“
DAY,MORNING_PEAKoderEVENING_PEAKsein, und Sie brauchen einen Auslöser für jede.
Beobachten Sie den Sensor einen Tag lang, bevor Sie auch nur einem einzigen to:-Wert trauen.
Eine Wochenendzone verdient eine Entscheidung, keinen Standard. WEEKEND ist ein Zonentyp; es sagt nichts darüber, was Sie zahlen. Setzen Sie den Sensor Tariff Buy Rate aus §4 auf ein Dashboard, schauen Sie an einem Samstag darauf und fügen Sie dann "WEEKEND" zur Liste state: hinzu, damit die Automatisierung am Wochenende handelt, statt es still zu übergehen. Wie es von dort weitergeht, ist eine Zeile. So wie es ist, behandelt das Template target jede Zone, die nicht NIGHT ist, als Tagessollwert; ein Wochenende zum vollen Preis bekommt daher den Tagessollwert — was Sie wollen. Fügen Sie or is_state('sensor.rbgrid_tariff_zone', 'WEEKEND') dieser Zeile hinzu, bekommt ein günstiges Wochenende stattdessen den Nachtsollwert:
conditions:
- condition: state
entity_id: sensor.rbgrid_tariff_zone
state: ["NIGHT", "DAY", "WEEKEND"] # add WEEKEND here → the automation also acts at weekends
actions:
- variables:
# a full-price weekend: leave this line exactly as it is in the automation above — WEEKEND then gets 19
# a cheap weekend: add the second is_state(), as below — WEEKEND then gets 21
target: "{{ 21 if is_state('sensor.rbgrid_tariff_zone', 'NIGHT') or is_state('sensor.rbgrid_tariff_zone', 'WEEKEND') else 19 }}"
Beide Fassungen wurden gegen eine laufende WEEKEND-Zone ausgeführt und tun genau das; die Schutzbedingungen time_src und placeholder oben bleiben unverändert und gelten in beiden Fällen weiter. Die Automatisierung handelt standardmäßig in zwei Zonen, weil der Hub Ihnen den Typ und den Preis der Zone sagen kann, aber nicht, nach welcher Ihr Haushalt leben will.
Schalten Sie zuerst jeden Zeitplan ab, den Sie bereits auf dieser Entität laufen haben. Wenn eine zeitbasierte Automatisierung und diese beide den Sollwert schreiben, bekämpfen sie sich, und wer zuletzt schrieb, gewinnt — eine Eigenschaft, die Sie nicht über Ihre Heizung entscheiden lassen wollen.
Der Hub ermittelt die Zone alle drei Sekunden neu und veröffentlicht auf seinem eigenen Drei-Sekunden-Takt, daher zeigt sich ein Zonenwechsel im schlimmsten Fall nach etwa sechs Sekunden, meist früher, zuzüglich der eigenen Latenz von Home Assistant. Für einen Sollwert schnell genug; bauen Sie nichts, das die Grenze auf die Sekunde genau braucht.
Sie konvergiert, sie reagiert nicht. Das ist der Teil, den Sie verstehen sollten, bevor Sie es anpassen. Eine Automatisierung, die nur beim Übergang in eine Zone auslöst, hat einen Fehler, den Sie nicht bemerken: Startet Home Assistant neu, hakt der Broker kurz oder ist der Hub still, wenn 23:00 vorbeigeht, wird der Übergang verpasst, und der Sollwert wird nie zurückgesetzt. Die Pumpe bleibt beim Tagessollwert — und nichts im Haus sagt es Ihnen, bis es kalt ist.
Der Auslöser lautet also nicht „die Nachtzone hat begonnen“, sondern „etwas hat sich geändert, oder wir haben neu gestartet, oder fünfzehn Minuten sind vergangen“. Die Aktion ermittelt dann, was die aktuelle Zone verlangt, und sendet es nur, wenn die Wärmepumpe nicht bereits dort ist. Das ist idempotent: Es nach einem Neustart auszuführen ist korrekt und nichts, was man unterdrücken sollte, und eine verpasste Grenze repariert sich spätestens beim nächsten Viertelstunden-Takt selbst.
Was es sicher hält, sind die Bedingungen, nicht der Auslöser: Die Zone muss ein echter Wert sein (unknown und unavailable fallen heraus), die Uhr des Hubs muss synchronisiert sein, und Sie müssen den Tarifplan bestätigt haben. Schlägt eine davon fehl, wird nichts gesendet, und die Wärmepumpe läuft mit ihrem eigenen Programm weiter.
Den Sollwert anstoßen; die Versorgung nicht sperren. Die Pumpe so lange auszuhalten, bis die günstige Zone beginnt, ist die naheliegende Idee und die falsche: Verdichter brauchen ihren eigenen Takt, Abtauläufe und Anti-Legionellen-Zyklen.
Der eigene Netzsignaleingang des Geräts — in den meisten Teilen Europas SG Ready — kann sie sperren, einschließlich einer harten Sperre von bis zu zwei Stunden, und Sperrkontakte der Versorger sind bei Wärmepumpentarifen üblich. Der Unterschied: Die Steuerung des Herstellers behält während der Sperre die Abtau- und Legionellenplanung und weiß, wann sie übersteuern muss. Eine Steckdose mit Schaltuhr in der Versorgungsleitung besitzt nichts davon. Also: der Sollwert, eine Voreinstellung oder ein Modus, über die eigene Oberfläche des Geräts — niemals die Versorgung.
Machen Sie „keine Daten“ zum sicheren Zustand — und wissen Sie, was er zurücklässt. Geht der Hub offline, wird der Sensor unavailable, die Bedingungen schlagen fehl, und nichts wird gesendet, sodass die Wärmepumpe unter ihrem eigenen Programm weiterläuft. Das ist das richtige Verhalten für das Gerät.
Seien Sie allerdings klar darüber, was es nicht ist: Hatte die Tagesautomatisierung Ihren Sollwert bereits gesenkt, stellt nichts ihn wieder her, solange der Hub abwesend ist. Stille schützt das Gerät, nicht Ihren Komfort. Genau deshalb ist das Abgleich-Design wichtig — sobald der Hub zurück ist, setzt der nächste Takt den Sollwert dorthin, wo die aktuelle Zone ihn haben will, ohne dass Sie etwas tun müssen.
Lassen Sie es zuerst als Benachrichtigung laufen. Ersetzen Sie ein bis zwei Tage lang die Aktion climate.set_temperature durch
- action: persistent_notification.create
data:
title: "Tariff zone"
message: "Would set the heat pump to {{ target }} °C"
und beobachten Sie, wann sie gefeuert hätte. Es kostet nichts, und so finden Sie heraus, dass Ihre Zonengrenze nicht dort liegt, wo Sie dachten — oder dass Ihre Klima-Entität nicht die ist, die Sie angenommen haben.
Wenn Sie in Home Assistant keine Klima-Entität haben, überspringen Sie diesen Abschnitt ganz. Die Messung und das Bild der Kosten nach Zone stehen für sich allein, und eine Automatisierung, die Sie nicht richtig steuern können, ist schlechter als keine.
Was das nicht leistet
- RBgrid schaltet nie etwas. Es hat keine Ausgänge. Jede Aktion in dieser Anleitung ist Home Assistant, das an Ihrer eigenen Anlage arbeitet.
- Die Kosten je Stromkreis bleiben in der App. Home Assistant bekommt die Energie der Wärmepumpe, nicht deren Kosten.
- Keine Kosten nach Zone je Zeitraum. Die Aufteilung nach Zone ist eine laufende Summe seit dem letzten Neustart des Hubs.
- Die Rolle ist in HA nicht sichtbar, daher kann eine Automatisierung einen Heizungsmesspunkt nicht von jedem anderen unterscheiden.
- Ein Hub, dessen Uhr nicht synchronisiert ist, meldet trotzdem eine Zone und bepreist trotzdem Energie, und zwar anhand dessen, wofür er die aktuelle Zeit hält. Deshalb prüft die Automatisierung oben
time_src, und deshalb verdienen die ersten Werte nach einem Kaltstart einen zweiten Blick. - RBgrid zeigt, was die Energie der Pumpe zu Ihren Tarifen kostet. Es prüft nicht die Rechnung Ihres Versorgers und macht keine Aussage darüber, was Sie sparen werden.