Fenster auf, Heizung aus: KNX-Thermostat pro Raum automatisch auf Frostschutz schalten (Home Assistant)

Im Winter heize ich gegen das offene Fenster. Jedes Mal, wenn ich zum Stoßlüften ein Fenster kippe, regelt das KNX-Thermostat darunter brav nach und ballert Heizenergie nach draußen — minutenlang, bis jemand merkt, dass der Raum kalt wird, und das Fenster wieder zumacht. Über eine Heizsaison summiert sich das zu echtem Geld, das einfach aus dem Fenster geht.

Die Lösung ist eine simple, pro Raum duplizierbare Automation: Fensterkontakt geht auf → Thermostat dieses Raums auf Frostschutz; Fenster geht zu → zurück auf Komfort. Der eine Trick, den fast alle Tutorials weglassen, ist eine 5-Sekunden-Entprellung gegen Fehlauslöser. So sieht mein Setup aus, Schritt für Schritt.

Warum building_protection und nicht einfach „aus“

Der naheliegende Reflex ist, das Thermostat beim offenen Fenster komplett auszuschalten (hvac_mode off oder preset standby). Das ist gefährlich: Bei einem Thermostat, das man vergisst, oder einem Fensterkontakt, der hängenbleibt, kann der Raum dann beliebig auskühlen — im schlimmsten Fall bis unter den Gefrierpunkt an einer Außenwand. Deshalb schalte ich auf den Preset building_protection (Frostschutz, typisch ~7 °C). Der Heizkörper bleibt überwacht und springt an, falls es wirklich kalt wird, heizt aber nicht das offene Fenster. Das ist die ganze Differenz zwischen „Energie sparen“ und „Heizungsrohr platzt im Januar“.

Schritt 1 — den Fensterkontakt als KNX-binary_sensor

Jedes Fenster, das ich überwachen will, bekommt einen binary_sensor mit device_class window. Das ist wichtig, weil Home Assistant darüber den richtigen „offen/geschlossen“-Status und die passenden Icons ableitet. Die Statusadresse ist die KNX-Gruppenadresse, auf der dein Fensterkontakt seinen Zustand sendet — hier mit X/X/X platzhaltermäßig; trag deine eigene ein. sync_state: false spart unnötiges Polling des Bus, weil der Kontakt von sich aus sendet.

binary_sensor:
  - name: "Fenster Buero Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Wohnzimmer Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Kinderzimmer 1 Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Kueche Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

  - name: "Fenster Kinderzimmer 2 Status Sensor"
    state_address: "X/X/X"
    sync_state: false
    device_class: window

Ein Eintrag pro Fenster. Die Namen sind nur Beispiele — generische Raumnamen wie „Buero“ oder „Wohnzimmer“ machen die Automationen später lesbar.

Schritt 2 — das Automations-Paar pro Raum

Für jeden Raum brauche ich zwei Automationen: eine deaktiviert die Heizung beim Öffnen, eine reaktiviert sie beim Schließen. Beide hängen am selben Fensterkontakt und steuern dasselbe Thermostat. Hier das Paar für das Büro:

- alias: Heizung Buero Deaktivieren
  triggers:
  - trigger: state
    entity_id: [binary_sensor.fenster_buro_status_sensor]
    from: 'off'
    to: 'on'
    for: {seconds: 5}
  actions:
  - action: climate.set_preset_mode
    data: {preset_mode: building_protection}
    target: {entity_id: climate.thermostat_buro}
  mode: single

- alias: Heizung Buero Aktivieren
  triggers:
  - trigger: state
    entity_id: [binary_sensor.fenster_buro_status_sensor]
    from: 'on'
    to: 'off'
    for: {seconds: 5}
  actions:
  - action: climate.set_preset_mode
    data: {preset_mode: comfort}
    target: {entity_id: climate.thermostat_buro}
  mode: single

Beim Öffnen wird building_protection gesetzt, beim Schließen wieder comfort. Welche Preset-Modi dein KNX-Thermostat überhaupt kann und wie sie auf den Bus abgebildet werden, habe ich im Post über KNX-Thermostat-Preset-Modi im Detail beschrieben.

Schritt 3 — die 5-Sekunden-Entprellung verstehen

Das for: {seconds: 5} ist der eigentliche Trick und der Grund, warum diese Automation im Alltag nicht nervt. Ohne sie löst jede Mikro-Bewegung des Kontakts sofort aus: ein Reed-Kontakt prellt manchmal beim Schließen, beim Stoßlüften klappert das Fenster im Rahmen, und der KNX-Bus liefert gelegentlich kurze Flatter-Telegramme. Jeder dieser Glitches würde sonst einen sinnlosen Moduswechsel auslösen.

Mit dem 5-Sekunden-Filter feuert die Automation erst, wenn das Fenster wirklich fünf Sekunden offen (bzw. zu) ist. Kurzes Klappern wird ignoriert, echtes Lüften erkannt. Fünf Sekunden sind kurz genug, dass keine spürbare Heizenergie verloren geht, und lang genug, um den ganzen Flatter-Müll auszublenden.

Das Mapping skaliert pro Raum

Das Schöne an dem Muster: Es ist stumpf duplizierbar. Pro Raum ein Fensterkontakt-binary_sensor plus ein climate-Thermostat, und das Automations-Paar wird einmal kopiert und die zwei entity_ids ausgetauscht. So sieht meine Zuordnungstabelle aus:

# Raum            Fensterkontakt                              Thermostat
# Buero           binary_sensor.fenster_buro_status_sensor    climate.thermostat_buro
# Wohnzimmer      binary_sensor.fenster_wohnzimmer_...        climate.thermostat_wohnzimmer
# Kueche          binary_sensor.fenster_kueche_...            climate.thermostat_kueche
# Kinderzimmer 1  binary_sensor.fenster_kinderzimmer_1_...    climate.thermostat_kinderzimmer_1
# Kinderzimmer 2  binary_sensor.fenster_kinderzimmer_2_...    climate.thermostat_kinderzimmer_2

Wer mehrere Fenster pro Raum hat, kann sie als Liste im Trigger-entity_id zusammenfassen und über eine Gruppe oder eine Template-Bedingung „mindestens ein Fenster offen“ abbilden — die Logik bleibt dieselbe.

Verifizieren, dass es greift

Nach dem Reload teste ich jeden Raum einmal von Hand: Fenster auf, kurz warten, dann in der Thermostat-Übersicht prüfen, dass der Preset auf building_protection gesprungen ist (die Liste mit secondary_info „last-changed“ zeigt den Zeitpunkt). Fenster zu, fünf Sekunden warten, zurück auf comfort. Wenn der Wechsel kommt, aber zu früh oder zu spät, ist fast immer die for-Dauer der Hebel, an dem man dreht.

Häufige Fragen

Warum nicht hvac_mode off statt building_protection?

Weil off jeden Frostschutz abschaltet. Bleibt ein Fenster über Nacht versehentlich auf oder bleibt der Kontakt hängen, kühlt der Raum unbegrenzt aus — an einer Außenwand droht im schlimmsten Fall ein geplatztes Rohr. building_protection hält ein Sicherheitsminimum (~7 °C), heizt aber nicht gegen das offene Fenster. Das ist der ganze Sinn der Übung.

Was, wenn mein Thermostat keinen building_protection-Preset hat?

Dann schau im more-info-Dialog des climate-Entity nach, welche preset_modes es meldet. Bei manchen KNX-Aktoren heißt der Frostschutz „frost“ oder wird über eine niedrige Solltemperatur per climate.set_temperature gelöst statt über einen Preset. Die Trigger-Logik bleibt identisch — du tauschst nur die action im Deaktivieren-Block.

Brauche ich für jeden Raum wirklich zwei Automationen?

Nicht zwingend — man kann das auch in einer Automation mit zwei Triggern und einem choose-Block lösen. Ich nehme bewusst zwei getrennte, weil sie im Automations-UI sofort lesbar sind („Heizung Buero Deaktivieren/Aktivieren“) und einzeln deaktivierbar bleiben, wenn ich an einem Raum etwas teste. Für ein wartbares Setup ist die kleine Redundanz es wert.

Verliere ich beim Lüften Heizenergie durch die 5-Sekunden-Verzögerung?

Praktisch nicht. In fünf Sekunden gibt ein Heizkörper kaum messbare Wärme ab, und die Trägheit eines wassergeführten Systems ist ohnehin viel größer. Die fünf Sekunden kaufen dir die Zuverlässigkeit, dass nicht jedes Klappern und jeder Bus-Glitch einen Moduswechsel auslöst — ein exzellenter Tausch.