Kurzer Hinweis vorab: In diesem Artikel geht es nicht um den internen Zusatzheizstab einer Wärmepumpe, der bei niedrigen Außentemperaturen den Vorlauf unterstützt. Es geht um einen komplett eigenständigen Heizstab am Badheizkörper im Dachgeschoss – gesteuert über ein simples Smart-Plug-Relais, völlig unabhängig von der Wärmepumpe. Diese Verwechslung passiert schnell, deshalb einmal ganz deutlich: zwei getrennte Systeme, zwei getrennte Zwecke.
Das Ausgangsproblem: Heizstab am Badheizkörper
Eine Wärmepumpe ist auf Effizienz getrimmt. Das bedeutet in der Praxis: möglichst niedrige Vorlauftemperaturen, weil jedes Grad mehr die Arbeitszahl verschlechtert. Für die Fußbodenheizung im Wohnbereich ist das ideal. Für ein Badezimmer, das man morgens oder abends schnell warm haben möchte, reicht diese niedrige Vorlauftemperatur aber oft nicht aus – der Heizkörper wird lauwarm statt heiß.
Meine Lösung dafür ist ein eigener 900-W-Heizstab im Badheizkörper. Er kann unabhängig von der Wärmepumpe zusätzliche Wärme in den Heizkörper bringen. Geschaltet wird der Heizstab bei mir über einen Shelly Plug S Gen3, den Home Assistant abhängig von Temperatur, PV-Überschuss und weiteren Bedingungen ein- und ausschaltet.
Von mir verwendet: ECD Germany Heizstab 900 W bei Amazon ansehen*
Zur Steuerung: Shelly Plug S Gen3 bei Amazon ansehen*
Und weil der Heizstab mit 900 Watt durchaus spürbar Strom zieht, ist die naheliegende Frage: Wann sollte er laufen? Am besten natürlich genau dann, wenn PV-Überschuss vorhanden ist und der zusätzliche Strom nicht aus dem Netz bezogen werden muss.
Klingt nach einer simplen Ein/Aus-Automation. Ist es aber nicht, sobald man es einmal richtig macht.
Warum „einfach Ein/Aus“ nicht funktioniert
Die naive erste Idee wäre: Temperatur im Bad unter einem Schwellwert? Heizstab an. Temperatur erreicht? Heizstab aus. Das Problem zeigt sich, sobald die Temperatur genau um diesen einen Schwellwert herum pendelt – zum Beispiel durch die Trägheit des Heizkörpers, kurze Zugluft beim Türöffnen oder einfach Messrauschen des Sensors. Das Ergebnis: Der Heizstab schaltet im Minutentakt ein und aus. Das nennt man Takten, und es ist schlecht für die Lebensdauer des Relais, nervig im Log und bringt am Ende auch keine stabilere Temperatur.
Die Lösung dafür heißt Hysterese: zwei unterschiedliche Schwellwerte für Ein- und Ausschalten, mit einem Puffer dazwischen.
Die Hysterese-Logik in der Praxis
In meiner Automation sieht das so aus:
# Einschalten: nur wenn wirklich alles passt
condition:
- condition: state
entity_id: switch.heizstab
state: "off"
- condition: numeric_state
entity_id: sensor.dg_badheizung_bad_temperatur
below: 23.5
# ... weitere Bedingungen, siehe unten
# Ausschalten: großzügigerer Schwellwert
condition:
- condition: state
entity_id: switch.heizstab
state: "on"
- condition: or
conditions:
- condition: numeric_state
entity_id: sensor.dg_badheizung_bad_temperatur
above: 24.5
# ... weitere Abschaltgründe, siehe untenCode-Sprache: PHP (php)Der Heizstab schaltet also erst unter 23,5°C ein, aber erst über 24,5°C wieder aus. Dieser eine Grad Puffer reicht in der Praxis locker aus, um das Takten komplett zu verhindern. Die Temperatur pendelt jetzt sanft zwischen den beiden Werten, statt an einem einzigen Schwellwert zu vibrieren.
Wichtig dabei: Ein- und Ausschalt-Logik sind bei mir zwei getrennte choose-Zweige mit jeweils eigenen, vollständigen Bedingungssätzen – nicht eine einzelne Bedingung mit einem Template drumherum. Das macht die Automation deutlich lesbarer und du siehst auf einen Blick, was zum Einschalten und was zum Ausschalten führt. Wer sich generell für choose-Aktionen mit Trigger-IDs interessiert: Das ist ein Muster, das ich in praktisch jeder meiner Automationen wiederverwende – Details dazu gibt es in der offiziellen Home-Assistant-Doku zu Conditions.
Sicherheitsbedingungen für den Heizstab am Badheizkörper
Reine Temperaturlogik reicht nicht. Ein Heizstab, der munter vor sich hinheizt, während das Fenster offen steht oder die PV-Anlage längst keinen Überschuss mehr liefert, ist teuer und unnötig. Deshalb kommen mehrere Sicherheitsebenen dazu.
1. Fenster/Tür-Kontakt
Steht die Tür oder das Fenster offen, wird sofort abgeschaltet – unabhängig davon, wie kalt es im Bad gerade ist:
- condition: state
entity_id: binary_sensor.kontaktsensor_ii_tur
state: "off" # muss geschlossen seinCode-Sprache: PHP (php)Beim Ausschalten wird der offene Zustand sogar als eigener Abschaltgrund geprüft (per or-Bedingung), damit die Reaktion sofort erfolgt und nicht erst beim nächsten regulären Check.
2. Zeitfenster
Die Automation läuft nur zwischen 08:05 und 20:00 Uhr:
conditions:
- condition: time
after: "08:05:00"
before: "20:00:00"Code-Sprache: CSS (css)Nachts oder in den frühen Morgenstunden bleibt der Heizstab also grundsätzlich außen vor – das übernimmt bei mir eine separate, einfachere Automation (dazu gleich mehr).
3. Koordination mit der Wärmepumpe
Damit sich Heizstab und Wärmepumpe nicht gegenseitig ins Gehege kommen, prüft die Automation zusätzlich den Zustand von switch.smart_grid_1_2. Ist die WP-Sperre aktiv, bleibt der Heizstab aus:
- condition: state
entity_id: switch.smart_grid_1_2
state: "off"Code-Sprache: JavaScript (javascript)Das ist genau der Punkt, an dem beide Systeme sich berühren – aber eben nur als Sicherheitsbedingung, nicht als gemeinsame Steuerung. Der Heizstab bleibt sein eigenes System.
4. Hardware-seitige Schutzsensoren
Der Shelly Plug bringt von Haus aus vier Binary Sensoren mit, die bei kritischen Zuständen auslösen:
binary_sensor.heizstab_uberhitzungbinary_sensor.heizstab_uberlastbinary_sensor.heizstab_uberspannungbinary_sensor.heizstab_uberstrom
Diese sind zwar nicht direkt in der Hysterese-Automation verdrahtet, laufen aber als zusätzliche Sicherheitsebene mit und eignen sich hervorragend für eine separate Alarm-Automation – falls einer dieser Sensoren jemals auf „on“ springt, ist das ein klares Signal, sofort nachzuschauen.
Gerade hier ist der Smart Plug für mich mehr als nur ein WLAN-Schalter. Durch Leistungswerte und Schutzsensoren bekomme ich zusätzliche Informationen über den Betrieb des Heizstabs direkt in Home Assistant.
PV-Überschusserkennung: zwei Werte statt einem
Für die Erkennung, ob wirklich PV-Überschuss da ist, verlasse ich mich nicht auf einen einzelnen Messwert, sondern kombiniere zwei:
- condition: numeric_state
entity_id: sensor.shelly1pmminig3_3030f9e503f4_power
below: -150 # Wechselrichter liefert Überschuss
- condition: numeric_state
entity_id: sensor.tibber_pulse_XXXX_leistung
below: 100 # kaum NetzbezugCode-Sprache: CSS (css)Warum zwei? Ein einzelner Sensor kann kurzfristig danebenliegen – etwa durch Messungenauigkeiten oder kurze Lastspitzen anderer Geräte. Die Kombination aus „Wechselrichter zeigt Einspeisung“ und „Netzbezug ist niedrig“ ist deutlich robuster. Beim Ausschalten reicht dagegen schon ein einzelner Grund (Netzbezug über 400 W), damit die Reaktion auf einen echten Lastwechsel schnell genug erfolgt.
Ergänzt wird das Ganze noch durch eine Leistungsschwelle direkt am Netzanschluss, die zusätzlich für 90 Sekunden stabil über 200 W liegen muss, bevor überhaupt reagiert wird – das verhindert, dass kurze Lastspitzen einzelner Haushaltsgeräte die Logik durcheinanderbringen. Wie diese Art der PV-Überschusserkennung auch bei anderen Verbrauchern zum Einsatz kommt, zeige ich im Artikel zur SG-Ready-Steuerung fürs Warmwasser.
Bonus: Der Komfort-Zeitfenster-Ansatz
Nicht jede Automation muss smart und PV-abhängig sein. Für die Zeit zwischen 06:00 und 07:00 Uhr morgens habe ich eine zweite, bewusst einfache Automation:
alias: Bad Dach Heizung Morgen
description: Heizung 06:00–07:00 mit Tür + Temperatur, danach aus
triggers:
- trigger: time
at: "06:00:00"
- trigger: time
at: "07:00:00"
- trigger: state
entity_id: binary_sensor.kontaktsensor_ii_tur
- trigger: state
entity_id: sensor.dg_badheizung_bad_temperaturCode-Sprache: CSS (css)Hier zählt Komfort, nicht Wirtschaftlichkeit: Morgens ist ohnehin keine PV-Leistung da, aber ein warmes Bad zum Aufstehen ist es trotzdem wert. Auch hier gelten Tür-Kontakt und ein Temperaturlimit (25°C) als Sicherheitsbedingung, aber eben ohne jede PV-Logik. Der Kontrast zeigt ganz gut: Nicht jedes Problem braucht die volle Automatisierungs-Komplexität – manchmal reicht ein simpler Zeitplan mit ein, zwei Schutzbedingungen völlig aus.
Status auf einen Blick
Damit man nicht ständig in die einzelnen Sensoren schauen muss, habe ich mir zusätzlich einen Template-Sensor gebaut, der den aktuellen Zustand in Klartext zusammenfasst:
{% raw %}{% set t = states('sensor.dg_badheizung_bad_temperatur') | float(0) %}
{% if is_state('binary_sensor.kontaktsensor_ii_tur', 'on') %}
🚪 Fenster offen
{% elif t > 24.5 %}
🌡️ Warm
{% elif is_state('switch.heizstab', 'on') %}
🔥 Heizt
{% elif t > 23.5 %}
🎯 Zielbereich
{% else %}
⚪ Bereit
{% endif %}{% endraw %}Code-Sprache: JavaScript (javascript)Auf dem Dashboard sehe ich damit auf einen Blick, warum der Heizstab gerade läuft oder eben nicht – ohne mir die einzelnen Bedingungen der Automation ins Gedächtnis rufen zu müssen. Ein schönes Beispiel dafür, wie sich komplexe Automationslogik am Ende in einer einzigen, verständlichen Statuszeile bündeln lässt.
Fazit: Heizstab am Badheizkörper richtig steuern
Ein Heizstab am Badheizkörper ist auf den ersten Blick eine simple Ein/Aus-Sache. Wer es aber richtig macht, kombiniert:
- Hysterese gegen das Takten (1°C Puffer zwischen Ein- und Ausschaltschwelle)
- Mehrschichtige Sicherheitsbedingungen (Fenster/Tür, Zeitfenster, WP-Koordination, Hardware-Schutzsensoren)
- Robuste PV-Erkennung durch die Kombination mehrerer Messwerte statt eines einzelnen
- Bewusste Trennung zwischen wirtschaftlicher PV-Logik und reiner Komfortsteuerung
Das Ergebnis ist eine Automation, die nicht nur funktioniert, sondern auch bei Kantenfällen – offenes Fenster, schwankende PV-Leistung, WP-Konflikt – zuverlässig das Richtige tut. Und genau das unterscheidet am Ende eine Home-Assistant-Bastelei von einer Automation, der man wirklich vertrauen kann.
Die eigentliche Hardware dahinter bleibt dabei erstaunlich überschaubar: ein 900-W-Heizstab im Badheizkörper, ein über Home Assistant steuerbarer Shelly Plug S Gen3 und die Home-Assistant-Instanz, die bei mir auf einem Raspberry Pi 4 läuft. Die eigentliche Intelligenz entsteht durch die Automationslogik darum herum.
Meine Hardware: 900-W-Heizstab* · Shelly Plug S Gen3* · Raspberry Pi 4*
Diesen Heizstab am Badheizkörper habe ich übrigens auch im Pillar-Artikel zum kompletten PV-Lastmanagement eingeordnet. Im nächsten Artikel der Serie geht es darum, wie man mehrere PV-Verbraucher – Warmwasser, Heizungsvorlauf und Heizstab – konfliktfrei gegeneinander priorisiert, wenn der Überschuss mal nicht für alle reicht.
* Mit * gekennzeichnete Links sind Affiliate-Links. Wenn du darüber etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich entstehen dadurch keine zusätzlichen Kosten. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.