Heizung in Home Assistant neu gebaut: Ein Blueprint für alle Räume

Meine Heizungssteuerung war über die Jahre gewachsen – und zwar so, wie Dinge eben wachsen, wenn man sie nie richtig plant. Am Ende hatte ich 29 einzelne Heizungsautomationen, eine HACS-Integration für Thermostate, ein paar verwaiste Thermostat-Entitäten aus alten Experimenten und einen zusätzlichen Zeitplan-Baustein, von dem ich zeitweise gar nicht mehr wusste, was er eigentlich schaltet. Irgendwann habe ich die Reißleine gezogen: alles raus, sauber neu aufbauen.

Hier zeige ich euch, wie die neue Struktur aussieht und warum ich sie für deutlich wartbarer halte.

Warum der HACS-Scheduler rausflog

Der Auslöser für den Neuanfang war eigentlich der Pelletofen. Der ging eines Vormittags einfach an, ohne dass ich eine Automation dafür finden konnte. Ich habe meine YAML-Dateien durchsucht, das Logbuch angeschaut – nichts. Im Logbuch stand nur ein Dienstaufruf ohne Benutzer.

Die Ursache war die Scheduler-Integration aus HACS. Die hatte ich vor langer Zeit mal ausprobiert, und dort standen noch Zeitpläne, die den Ofen an bestimmten Wochentagen einschalteten – ohne jede Jahreszeit-Bedingung. Das Tückische: Diese Zeitpläne stehen nicht in den normalen YAML-Dateien, sondern in einer internen Speicherdatei der Integration. Mit einer Textsuche über die Konfiguration findet ihr sie nicht.

Ich habe die Zeitpläne gelöscht und die Integration komplett deinstalliert. Der Ofen läuft seitdem nur noch über eine einzige, ganz normale Automation mit dem schönen Namen „Nur Winter“: Sie schaltet an festen Tagen, aber nur von Oktober bis April. Meine Lehre daraus: Wenn ein Gerät schaltet und ihr keine Automation dafür findet, schaut zuerst in Integrationen, die ihre eigenen Zeitpläne verwalten.

Der Grundgedanke: Ein Blueprint, viele Räume

Statt für jeden Raum drei, vier eigene Automationen zu pflegen, habe ich einen einzigen Blueprint geschrieben: eine „Raumsteuerung“. Jeder Raum ist eine Instanz davon – aktuell sieben Stück, von Wohnzimmer und Küche über Bad und Schlafzimmer bis zu den beiden Kinderzimmern und dem Abstellraum.

Ändere ich etwas an der Logik, ändere ich es einmal im Blueprint, und alle Räume profitieren. Das war mit 29 Einzelautomationen praktisch unmöglich, weil sich die Varianten über die Zeit auseinanderentwickelt hatten.

Jede Instanz bekommt über Eingaben (input) nur die raumspezifischen Dinge:

• das Thermostat bzw. die Heizgruppe des Raums,
• einen Zeitplan-Helfer (schedule),
• einen Helfer für die Tagtemperatur,
• optional einen Fensterkontakt,
• optional den Pelletofen.

Zeitpläne als Helfer statt in der Automation

Das Herzstück sind die schedule-Helfer, die Home Assistant von Haus aus mitbringt. Jeder Raum hat einen eigenen Heizplan. Ist der Zeitplan „an“, soll der Raum auf Tagtemperatur geheizt werden, ist er „aus“, gilt eine gemeinsame Absenktemperatur von 19 °C.

Der große Vorteil: Die Zeiten stehen nicht im Code. Wer den Heizplan fürs Bad ändern will, klickt im Helfer-Editor ein paar Balken zurecht und fertig. Die Automation selbst muss dafür niemand anfassen.

Die Tagtemperatur ist ebenfalls ein eigener Helfer pro Raum (input_number). Im Kinderzimmer sind es andere Werte als in der Küche, und so lassen sich die Temperaturen bequem über das Dashboard verstellen.

Stark vereinfacht sieht der Kern des Blueprints so aus:

blueprint:
  name: Heizung Raumsteuerung
  domain: automation
  input:
    thermostat:
      selector:
        entity:
          domain: climate
    heizplan:
      selector:
        entity:
          domain: schedule
    tagtemperatur:
      selector:
        entity:
          domain: input_number
    absenktemperatur:
      selector:
        entity:
          domain: input_number

triggers:
  - trigger: state
    entity_id: !input heizplan
    to: ["on", "off"]

variables:
  plan: !input heizplan
  tag: !input tagtemperatur
  absenk: !input absenktemperatur

actions:
  - action: climate.set_temperature
    target:
      entity_id: !input thermostat
    data:
      temperature: >
        {{ states(tag) | float(20) if is_state(plan, 'on')
           else states(absenk) | float(19) }}
mode: restart

Mein echter Blueprint ist länger, aber das Prinzip ist genau das.

Nur an Schaltpunkten schalten

Eine bewusste Designentscheidung: Die Automation greift nur an den Schaltpunkten des Zeitplans ein, also wenn der Plan von „aus“ auf „an“ wechselt oder umgekehrt. Sie überschreibt nicht alle paar Minuten die Solltemperatur.

Das hat einen einfachen Grund: Wenn jemand am Thermostat oder in der App mal zwei Grad hochdreht, weil ihm kalt ist, soll das bis zum nächsten Schaltpunkt so bleiben. Nichts nervt mehr als eine Heizung, die die eigene Einstellung nach fünf Minuten wieder zurückdreht. Meine alten Automationen haben genau das getan.

Fenster auf: Temperatur merken und zurückholen

Für Räume mit Fensterkontakt gibt es eine Fensterlogik direkt im Blueprint. Geht das Fenster auf, merkt sich die Automation die aktuelle Solltemperatur in einem Speicher-Helfer und stellt das Thermostat auf 12 °C. Geht das Fenster wieder zu, wird der gemerkte Wert zurückgeschrieben. Steht im Speicher eine 0, ist nichts gemerkt – so erkenne ich, ob es überhaupt etwas zurückzuholen gibt.

Das Bad ist die Ausnahme. Dort gibt es schon eine eigene, ausgefeilte Fensterlogik samt Duschmodus, die ich bewusst behalten habe. In der Bad-Instanz ist die Fensterlogik des Blueprints deshalb einfach abgeschaltet.

Der „Kind krank“-Modus

Das ist die Funktion, die ich im Alltag am meisten schätze. Die normalen Zeitpläne sind auf einen ganz gewöhnlichen Alltag ausgelegt und senken in vielen Räumen tagsüber ab. Ist unser Kind aber krank und zu Hause, soll es tagsüber überall angenehm warm sein.

Dafür gibt es einen Schalter „Kind krank“. Ist er an, verwenden die Raumsteuerungen statt ihrer normalen Pläne einen eigenen Zeitplan: für die meisten Räume tagsüber von 8 bis 18 Uhr, für Wohnzimmer und Küche von 8 bis 21 Uhr. Ein Klick morgens, und ich muss nicht in sieben Zeitplänen herumklicken.

Pelletofen und Heizung vertragen sich

Wohnzimmer und Küche werden zusätzlich vom Pelletofen mitgeheizt. Läuft der Ofen, wäre es Unsinn, wenn die Heizkörper parallel voll mitheizen. Deshalb gibt es im Blueprint optional einen Ofen-Eingang: Ist der Ofen an, gilt für diese Räume höchstens eine eigene Ofen-Temperatur von 20 °C. Die Formel ist schlicht das Minimum aus Plan und Ofen-Temperatur. Damit wird in der Absenkphase auch nicht versehentlich hochgedreht, nur weil der Ofen läuft.

Better Thermostat für die Schlaf- und Kinderzimmer

In den beiden Kinderzimmern und im Schlafzimmer regle ich nicht mehr nach dem Sensor im Heizkörperthermostat, sondern über „Better Thermostat“ aus HACS nach einem separaten Zigbee-Raumsensor. Der Sensor direkt am Heizkörper misst naturgemäß zu warm, und gerade nachts im Kinderzimmer ist mir die echte Raumtemperatur wichtig. Better Thermostat nutzt bei mir nur Raumsensor und Luftfeuchte, die Fensterlogik bleibt beim Blueprint. Die übrigen Räume laufen über Heizgruppen mit Homematic-IP-Wandthermostat, das die Raumtemperatur ohnehin sauber misst.

Ein eigenes Heizungs-Dashboard

Zum Schluss habe ich die Heizungs-Tabs aus meinen alten Dashboards entfernt und ein eigenes Heizungs-Dashboard gebaut. Dort landet alles, was ich im Alltag brauche: die Räume mit ihren Tagtemperaturen, der „Kind krank“-Schalter und ein Hauptschalter, mit dem sich die gesamte Heizungsautomatik auf einen Schlag pausieren lässt. Die Zeitpläne selbst pflege ich weiterhin direkt in den Helfern.

Fazit

Abbau und Neuaufbau habe ich an einem einzigen Tag erledigt, und es hat sich sofort gelohnt. Statt 29 Automationen, die sich gegenseitig ins Gehege kamen, habe ich einen Blueprint und sieben schlanke Instanzen. Zeiten ändere ich in den Zeitplan-Helfern, Temperaturen im Dashboard, und manuelle Änderungen bleiben respektiert. Der wichtigste Tipp aus der Aktion: Macht vor so einem Aufräumen ein Backup eurer Automationen, und schaut nach Integrationen, die im Hintergrund eigene Zeitpläne verwalten – sonst sucht ihr euch wie ich den Wolf nach einem Ofen, der „von allein“ angeht.