!Geöffnetes Fenster über einem Heizkörper
Im Oktober 2024 schrieb ein Nutzer ins Zigbee2MQTT-Repository, sein Aqara-Thermostat E1 lasse sich nicht dazu bringen, ein offenes Fenster zu melden. Er hatte der Eigenschaft window_open per MQTT alles geschickt, was ihm einfiel: "ON", true, "on", "On", "value_on". Fünfmal derselbe Fehler im Log: "No converter available for 'window_open'". Die Antwort kam am nächsten Tag und war ernüchternd kurz. Man könne den Wert nicht setzen, er zeige nur an, ob das Thermostat selbst ein Fenster zu erkennen glaubt, vermutlich an einem scharfen Temperaturabfall seines internen Fühlers. Wer das Thermostat mit einem echten Fensterkontakt füttern wolle, brauche eine eigene Automation oder eine Integration wie Better Thermostat. (Issue Koenkk/zigbee2mqtt #24507.)
Die Fenster-offen-Funktion im Thermostat und der Fensterkontakt an der Fensterzarge sind zwei völlig getrennte Dinge, und Home Assistant verbindet sie nicht von selbst. Dieser Artikel zeigt, wie Sie das selbst tun, ohne dass die Heizung im Wohnzimmer nach dem Stoßlüften auf 5 Grad hängenbleibt.
Warum die eingebaute Erkennung so oft danebenliegt
Die Logik im Gerät ist simpel und steht in den Dokus: Sie schaut auf die eigene Temperatur. Beim Sonoff TRVZB beschreibt Zigbee2MQTT die Funktion open_window so: Sie schalte den Heizkörper ab, wenn die lokale Temperatur um mehr als 1,5 °C in 4,5 Minuten fällt. Den Fühler dieses Thermostats trägt der Heizkörper am Ventil, nicht der Raum.
Daraus folgen zwei Fehlerarten, und beide kennt jeder, der es probiert hat. Erstens die verpasste Erkennung: Ein gekipptes Fenster im Februar kühlt den Fühler am warmen Ventilkörper vielleicht gar nicht schnell genug ab. Zweitens der Fehlalarm: Zugluft, die kalte Duschluft aus dem Bad oder ein Heizkörper, der gerade abgeschaltet wurde, erzeugen denselben Temperaturverlauf wie ein offenes Fenster. Ich halte beides für physikalisch zwangsläufig, wenn ein Gerät aus einer einzigen Temperaturkurve auf einen Zustand im Raum schließen soll. Ob es bei Ihnen auftritt, hängt von Dämmung, Einbaulage und Außentemperatur ab.
Ein Forenbeitrag aus der Home-Assistant-Community (Januar 2025) zeigt, wie wenig durchschaubar das für Nutzer ist. Jemand wollte seinen IKEA-Parasoll-Sensor als Fensterkontakt für das Aqara E1 nutzen und fand nur den binary_sensor window_open des Thermostats. Die erste Antwort: Das sei mit hoher Wahrscheinlichkeit nur ein Ausgang, der anzeige, wann das Thermostat ein Fenster annimmt. Die Rückfrage des Fragestellers: "So it is detecting it in some magical way by itself. Is it reliable, anyhow?" (community.home-assistant.io, Thema "Aqara Thermostat E1 and Ikea Parasoll - Window Open detection setup".)
Bosch geht in der Zigbee2MQTT-Doku zum Heizkörper-Thermostat II (BTH-RA) einen anderen Weg und sagt es offen. Die Funktion window_detection aktiviert dort den Fenster-offen-Modus, in dem das Thermostat Heizen und Kühlen abschaltet, mit dem ausdrücklichen Zusatz: Das Gerät selbst erkenne keine offenen Fenster. Das Thermostat ist hier also nur der Empfänger eines Signals, das jemand anderes liefern muss. Das ist die ehrlichere Konstruktion, und sie ist genau das, was wir bauen wollen.
Der Fensterkontakt: kleine Teile, große Wirkung
Ein Kontakt besteht aus einem Reed-Schalter und einem Magneten, mehr nicht. Er kostet wenig und braucht keine Kalibrierung. Bei Zigbee2MQTT sind der Sonoff SNZB-04 und der neuere SNZB-04P gelistet; beide melden contact, Batteriestand und Spannung, der SNZB-04P zusätzlich einen Tamper-Zustand. Der Aqara MCCGQ11LM läuft mit einer CR1632 und wird laut Doku angelernt, indem man die Reset-Taste etwa fünf Sekunden hält, bis die blaue LED blinkt. Wie Sie die Sensoren ins Netz bekommen, hängt vom Stack ab; die Unterschiede zwischen ZHA und Zigbee2MQTT erklärt unser Vergleich.
Eine Stolperfalle liegt in der Begrifflichkeit. In Zigbee2MQTT bedeutet contact: true "geschlossen". In Home Assistant erscheint der Sensor dagegen als binary_sensor mit der Geräteklasse "Fenster" oder "Öffnung", und dort steht laut HA-Doku on für offen und off für geschlossen. Wer in Entwicklerwerkzeuge schaut und on sieht, schaut also auf ein offenes Fenster, nicht auf einen geschlossenen Kontakt. Prüfen Sie das einmal von Hand, bevor Sie eine Automation darauf aufsetzen.
Mehrere Fenster pro Raum: eine Gruppe davor
Sobald zwei Fenster im Raum sind, wird die Frage nach dem "Wann gilt der Raum als offen?" interessant. Die einfache Antwort: sobald irgendein Fenster offen ist. Dafür legen Sie unter Einstellungen, Geräte & Dienste, Helfer eine Gruppe vom Typ binary_sensor an und lassen "Alle Entitäten" ausgeschaltet. Dann ist die Gruppe on, solange mindestens ein Mitglied on ist. Die Better-Thermostat-Doku zeigt dasselbe als YAML-Gruppe mit all: false und mehreren binary_sensor.openclose_*-Einträgen und empfiehlt genau dieses Vorgehen für mehrere Fenster.
Für Ihre Automation ist die Gruppe ein einzelner Sensor mit einem sauberen Zustand. Das spart doppelte Trigger und die Frage, was passiert, wenn das erste Fenster schließt, während das zweite noch offen ist. Die Gruppe bleibt einfach on.
Die Automation: erst warten, dann abschalten, dann wiederherstellen
Die aktuelle Home-Assistant-Doku kennt eigene Trigger für Fenster mit (window.opened, window.closed), und die Doku der Scene-Integration enthält ein Beispiel, das beim Öffnen den Thermostatzustand per scene.create sichert und beim Schließen wieder aktiviert. Das Beispiel hat keine Verzögerung. Genau die brauchen Sie aber: Wer nur kurz die Balkontür aufmacht, um die Wäsche hereinzuholen, soll keine Ventilbewegung auslösen. Deshalb unten der klassische Zustands-Trigger mit for. Die Syntax entspricht dem seit 2024.10 gültigen Format mit triggers:, trigger: state und actions:.
alias: "Wohnzimmer: Fenster offen, Heizung runter"
description: "Sichert den Thermostatzustand, senkt auf Minimum, stellt beim Schließen wieder her."
mode: single
triggers:
- trigger: state
entity_id: binary_sensor.fenster_wohnzimmer_gruppe
from: "off"
to: "on"
for: "00:01:00"
id: offen
- trigger: state
entity_id: binary_sensor.fenster_wohnzimmer_gruppe
from: "on"
to: "off"
for: "00:00:30"
id: zu
actions:
- choose:
- conditions:
- condition: trigger
id: offen
sequence:
- action: scene.create
data:
scene_id: vor_fenster_wohnzimmer
snapshot_entities:
- climate.heizung_wohnzimmer
- action: climate.set_temperature
target:
entity_id: climate.heizung_wohnzimmer
data:
temperature: 5
- conditions:
- condition: trigger
id: zu
- condition: template
value_template: "{{ states.scene.vor_fenster_wohnzimmer is defined }}"
sequence:
- action: scene.turn_on
target:
entity_id: scene.vor_fenster_wohnzimmerEin paar Entscheidungen darin verdienen eine Begründung.
Die Verzögerung: Mit for: "00:01:00" muss der Sensor eine Minute lang on bleiben, bevor die Automation anspringt. Kürzere Werte (30 Sekunden) reagieren schneller, öffnen aber auch bei jedem Türkontakt, der kurz klappert. Beim Schließen reichen 30 Sekunden, weil ein Kontakt, der wieder off meldet, eine eindeutige Information ist. Das ist meine Erfahrungsregel, keine Norm. Better Thermostat bietet dieselbe Idee als Feld "Window delay" an, das in beide Richtungen wirkt.
Frostschutz statt "Aus": Ich setze die Temperatur auf den kleinsten Wert, den das Thermostat zulässt (steht im Attribut min_temp der Climate-Entität), statt den HVAC-Modus auf off zu stellen. Der Grund steht in einem Better-Thermostat-Issue von Dezember 2023: Ein Nutzer berichtet, sein Aqara E1 mache beim vollständigen Ausschalten "a lot of motor motions", was die Batterie schnell leere, und ein niedriger Away-Wert verursache viel weniger Motorbewegung. Dazu kommt ein praktischer Nebeneffekt: Ein Raum mit einer Mindesttemperatur kühlt bei vergessenem Fenster nicht bis zum Frostschaden aus. (Issue KartoffelToby/better_thermostat #1206.) Die HA-Doku zeigt in ihrem Beispiel climate.set_hvac_mode mit off; beides ist legitim, ich würde es nur bei batteriebetriebenen Ventilen nicht als Standard setzen.
Wiederherstellen per Szene: scene.create mit snapshot_entities speichert den aktuellen Zustand der Climate-Entität, also Modus und Solltemperatur, und scene.turn_on setzt beides zurück. Das ist robuster als eine feste Rückstelltemperatur, weil der Wert stimmt, den das Wochenprogramm oder Sie selbst zuletzt eingestellt hatten. Die Doku weist darauf hin, dass entities und snapshot_entities sich nicht überschneiden dürfen; für diesen Fall ist das ohne Belang.
Die Template-Bedingung: Sie fängt den Fall ab, dass das Fenster schließt, ohne dass je eine Szene erzeugt wurde, etwa weil es keine Minute offen war. Ohne sie würde scene.turn_on ins Leere laufen und einen Fehler ins Log schreiben.
from: "off" im Trigger: Ohne diese Angabe würde auch der Wechsel von unavailable auf on auslösen, etwa nach einem Funkaussetzer bei offenem Fenster. Dann sicherte scene.create den bereits abgesenkten Zustand als "vorher", und nach dem Schließen stünden 5 Grad als Solltemperatur im Raum.
Wenn der Sensor ausfällt
Hier unterscheiden sich Eigenbau und Integration. Better Thermostat behandelt laut eigener FAQ die Zustände unknown und unavailable des Fenstersensors vorsorglich als "offen", die Heizung pausiert also. Das ist konsequent, aber es kann ein leerer Batteriesatz im Kontakt sein, der Ihnen die Heizung abschaltet. Meine Automation oben macht das nicht: Sie reagiert nur auf den Wechsel von off auf on und ignoriert unavailable. Welches Verhalten Sie wollen, ist Geschmackssache. Im Winter würde ich eine Benachrichtigung bei niedrigem Batteriestand der Kontakte einrichten, in beiden Varianten.
Better Thermostat: wenn Sie die Automation nicht selbst pflegen wollen
Better Thermostat legt ein virtuelles Thermostat über Ihr echtes. In der Konfiguration wählen Sie ein oder mehrere echte Thermostate, einen externen Temperatursensor, optional einen Fenstersensor und eine Verzögerung. Laut Doku schaltet es bei offenem Fenster das Thermostat ab und beim Schließen wieder ein. Das ist die bequemste Lösung, vor allem mit externem Raumfühler, den wir im TRVZB-Artikel ausführlicher behandeln.
Die offenen Issues im Repository zeigen die Grenzen. Im November 2024 bat ein Nutzer um eine Möglichkeit, die Wartezeit nach dem Schließen zu überspringen: Während der Verzögerung lasse sich die Heizung nicht von Hand früher einschalten, und Better Thermostat zeige das Fenster weiterhin als offen an (Issue #1487). Im August 2025 wünschte sich ein anderer Nutzer einen Schalter, mit dem ein bestimmtes Fenster ignoriert wird, weil er manchmal bei leicht geöffnetem Fenster heizen wolle (Issue #1638). Beide Issues sind im Tracker als offen markiert. Wer solche Ausnahmen braucht, ist mit einer eigenen Automation besser bedient, weil sich dort ein Eingabe-Schalter als Bedingung einbauen lässt.
Auch Versatile Thermostat verwaltet Fenster- und Türkontakte; im Thread zur Integration in der Community (März 2023) steht die Tür- und Fensterverwaltung ausdrücklich in der Funktionsliste. Zwei Schichten über ein Thermostat zu legen, ist selten eine gute Idee; entscheiden Sie sich für eine.
Gekippte Fenster erkennen
Ein einfacher Kontakt kennt nur zwei Zustände, und ob "gekippt" als offen zählt, hängt davon ab, wie weit sich Magnet und Reed-Schalter beim Kippen voneinander entfernen. Bei vielen Rahmen bleibt der Abstand klein genug, dass der Kontakt "zu" meldet. Das ist meine Einschätzung aus der Bauform, nicht aus einer Messreihe, prüfen Sie es also mit Ihrem Fenster einmal von Hand in den Entwicklerwerkzeugen.
Wer Dreh- und Kippzustand wirklich getrennt braucht, findet in der Community einen praktikablen Eigenbau: Ein Nutzer baute im August 2023 in einen billigen Zigbee-Kontakt mit Tamper-Schalter einen zweiten Reed-Kontakt anstelle des Tamper-Schalters ein und kombinierte beide Zustände in einem Template-Sensor mit den Werten open, tilt und close (community.home-assistant.io, "Know the state of tilt and turn Windows/doors"). Das ist Bastelarbeit, funktioniert aber mit einem einzigen Gerät pro Fenster. Und es lohnt sich wirklich nur, wenn Sie gekippte Fenster auch für Rollladen- oder Klimalogik brauchen. Die Verbraucher-Seite spricht dagegen: co2online rät, im Winter beim Stoßlüften die Thermostate zu drosseln und Fenster gar nicht erst zu kippen, weil bei Dauerkipp Warmluft verloren geht und das Mauerwerk über dem Fenster auskühlt.
Und was bringt es?
Eine Zahl, die ausschließlich der Fenster-offen-Funktion gehört, habe ich in keiner der Quellen gefunden, die ich für diesen Artikel gelesen habe. Was es gibt, sind die Spannen für smarte Heizungssteuerung insgesamt (Fraunhofer 14 bis 26 Prozent, co2online 9 bis 15, Stiftung Warentest 6 bis 10), die wir im Ersparnis-Artikel auseinandergenommen haben. Die Fenster-offen-Logik ist ein Teil davon, kein messbarer Einzelposten. Die ehrliche Begründung ist die von co2online: Wer beim Lüften die Heizung nicht herunterregelt, heizt hinaus.
Für die Kaufentscheidung heißt das: Ein Fensterkontakt kostet wenige Euro, die Automation ist eine Viertelstunde Arbeit, und mehr als diese Logik braucht es nicht. Welche Heizkörperthermostate sich dafür eignen, steht in unserer Kaufberatung.
Reihenfolge zum Einrichten
Legen Sie zuerst den Kontakt an und prüfen Sie in den Entwicklerwerkzeugen, ob on wirklich offen heißt. Bauen Sie dann die Gruppe, auch wenn der Raum nur ein Fenster hat; dann müssen Sie später nur die Gruppe erweitern. Testen Sie die Automation mit einem verkürzten for im Wohnzimmer, bevor Sie sie auf alle Räume kopieren. Und lassen Sie die eingebaute Fenster-offen-Funktion der Thermostate dort ausgeschaltet, wo Sie einen Kontakt haben: Beim Aqara E1 lässt sie sich laut Zigbee2MQTT über window_detection abschalten, sonst regelt das Gerät parallel zu Ihrer Automation.
