KNX-Thermostate stehen nach jedem Home-Assistant-Neustart auf 'Standby' — die Startup-Automation, die den richtigen Modus setzt

Es ist ein leiser Bug, der dich erst beißt, wenn die Wohnung morgens kalt ist: Nach jedem Neustart von Home Assistant — Update, Add-on-Installation, Container-Restart, Stromausfall — standen bei mir sämtliche KNX-Thermostate auf 'Standby'. Kein Heizen, keine Fehlermeldung, einfach Modus weg. Bis ich es bemerkte, war es meist schon mehrere Stunden zu spät und die Heizkörper kalt.

Die Ursache ist harmlos und ärgerlich zugleich: Beim Neustart verliert die KNX-Integration kurz die Verbindung zum Bus, und viele KNX-Klima-Aktoren fallen dabei in einen sicheren Default-Zustand — eben 'Standby'. Home Assistant kennt den vorherigen Modus nach dem Neustart nicht mehr und setzt ihn auch nicht von selbst zurück. Die Lösung ist eine kleine, aber präzise getimte Startup-Automation. Sie hat mich rund 30 Minuten gekostet — und das Kalt-aufwachen-Problem ist seitdem weg.

Das Fehlerbild: 'standby' statt 'heat'

Konkret: Vor dem Neustart steht ein Thermostat auf hvac_mode: heat mit Preset comfort. Nach dem Neustart zeigt dieselbe climate-Entität standby (oder bei manchen Aktoren 'off'). Der Sollwert verschwindet aus der Regelung, der Heizkörper bleibt kalt. Im Verlaufsgraphen sieht man den Knick exakt am Neustart-Zeitpunkt. Wichtig zu verstehen: Das ist kein Defekt deiner Automationen — es ist ein Initialisierungs-Loch direkt nach dem Boot.

Warum ein einfacher 'set mode'-Aufruf nicht reicht

Der naheliegende Reflex — beim Start einfach climate.set_hvac_mode feuern — schlägt fehl, weil die climate-Entitäten in den ersten Sekunden nach dem Boot oft noch unavailable sind. Der KNX-Bus muss sich erst verbinden, die Aktoren müssen ihren Zustand melden. Schickst du den Befehl zu früh, läuft er ins Leere und das Thermostat bleibt auf Standby. Genau deshalb braucht die Automation zwei Zutaten: einen Trigger auf den HA-Start und eine kurze Wartezeit, bis der Bus wieder da ist.

Die Lösung: eine getimte Startup-Automation

Die folgende Automation triggert auf das homeassistant start-Event, wartet 30 Sekunden, bis der KNX-Bus verbunden und alle climate-Entitäten verfügbar sind, und setzt dann je nach Nachtmodus den passenden Zustand: Ist der Nachtmodus aktiv, gehen alle Thermostate auf das Preset economy; sonst auf heat plus Preset comfort. Den Tag-/Nacht-Zweig steuert ein einfacher input_boolean-Helper, den ich mir mit dem Master-Heizungsschalter teile.

- id: heating_startup_initialize
  alias: 'Heizung: Modus beim Start initialisieren'
  description: >-
    Setzt alle Thermostate beim HA-Start auf den korrekten Modus,
    basierend auf dem Nachtmodus-Status
  triggers:
  - trigger: homeassistant
    event: start
  conditions: []
  actions:
  # KNX-Bus braucht nach dem Neustart ein paar Sekunden, bis alle
  # climate-Entities wieder verbunden/verfuegbar sind
  - delay:
      seconds: 30
  - choose:
    # Nachtmodus aktiv -> economy
    - conditions:
      - condition: state
        entity_id: input_boolean.heizung_nachtmodus
        state: 'on'
      sequence:
      - action: climate.set_preset_mode
        data:
          preset_mode: economy
        target:
          entity_id:
          - climate.thermostat_wohnzimmer
          - climate.thermostat_buro
          - climate.thermostat_kuche
          - climate.thermostat_schlafzimmer
          - climate.thermostat_kinderzimmer_1
          - climate.thermostat_kinderzimmer_2
    # sonst Tagmodus -> heat + comfort
    default:
    - action: climate.set_hvac_mode
      data:
        hvac_mode: heat
      target:
        entity_id:
        - climate.thermostat_wohnzimmer
        - climate.thermostat_buro
        - climate.thermostat_kuche
        - climate.thermostat_schlafzimmer
        - climate.thermostat_kinderzimmer_1
        - climate.thermostat_kinderzimmer_2
    - action: climate.set_preset_mode
      data:
        preset_mode: comfort
      target:
        entity_id:
        - climate.thermostat_wohnzimmer
        - climate.thermostat_buro
        - climate.thermostat_kuche
        - climate.thermostat_schlafzimmer
        - climate.thermostat_kinderzimmer_1
        - climate.thermostat_kinderzimmer_2
  mode: single

Die Entity-Liste ist bei mir auf sechs Räume gemünzt — ersetze sie durch deine eigenen climate.-Entitäten. Die Räume hier sind generische Platzhalter; du trägst Büro, Wohnzimmer, Küche und so weiter so ein, wie sie in deinem Setup heißen.

Warum genau 30 Sekunden Delay

Die 30 Sekunden sind kein willkürlicher Wert. Bei mir brauchte die KNX-Integration nach dem Boot reproduzierbar etwa 10 bis 20 Sekunden, bis alle climate-Entitäten von 'unavailable' auf einen echten Zustand wechselten. 30 Sekunden geben sicheren Puffer, ohne dass die Wohnung spürbar später warm wird. Auf langsamerer Hardware (Raspberry Pi, viele Integrationen) kann es sinnvoll sein, auf 45 oder 60 Sekunden zu gehen. Faustregel: lieber etwas zu lang warten als den Befehl ins Leere schicken.

Wenn du es robuster magst, kannst du den festen delay durch ein wait_template ersetzen, das wartet, bis eine repräsentative climate-Entität nicht mehr 'unavailable' ist — aber für ein Heim-Setup ist der schlichte 30-Sekunden-Delay erprobt und reicht völlig.

Der Tag-/Nacht-Zweig über choose

Der choose-Block sorgt dafür, dass ein Neustart um drei Uhr nachts nicht die volle Komfort-Temperatur hochfährt. Steht input_boolean.heizung_nachtmodus auf 'on', bekommen alle Thermostate das Preset economy (abgesenkt); im Default-Zweig — also tagsüber — wird erst heat als HVAC-Modus und dann comfort als Preset gesetzt. Diesen Nachtmodus-Helper teile ich mir mit dem zentralen Heizungs-Schalter, sodass Startup und manuelle Steuerung dieselbe Quelle der Wahrheit nutzen.

Dieselbe Building-Protection-/Preset-Logik nutze ich auch bei der fensterkontakt-getriggerten Frostschutz-Automation — beide greifen auf denselben Thermostat-Pool zu, nur zu unterschiedlichen Anlässen.

Testen, ohne Home Assistant neu zu starten

Du musst nicht jedes Mal komplett neu booten, um die Automation zu prüfen. In den Developer Tools kannst du die Automation manuell über 'Run' auslösen — der homeassistant-start-Trigger wird dabei übersprungen, aber die Aktionen (Delay + choose) laufen exakt so durch. Stell vorher ein Thermostat testweise auf 'standby' und beobachte im more-info-Dialog, wie es nach gut 30 Sekunden auf 'comfort'/heat zurückspringt. Für den echten Test hilft ein bewusster Neustart und ein Blick auf die last-changed-Zeitstempel der climate-Entitäten.

Häufige Fragen

Warum fallen die KNX-Thermostate beim Neustart überhaupt auf Standby?

Beim Neustart verliert die KNX-Integration kurz die Busverbindung. Viele KNX-Klima-Aktoren gehen bei Verbindungsverlust in einen sicheren Default — oft 'Standby' oder 'off'. Home Assistant rekonstruiert den vorherigen Modus nach dem Boot nicht automatisch, also bleibt der Aktor im Default stehen, bis ihn etwas aktiv zurücksetzt. Genau diese Lücke füllt die Startup-Automation.

Reicht nicht ein kürzeres Delay als 30 Sekunden?

Möglich, aber riskant. Setzt du den Befehl, bevor die climate-Entitäten verfügbar sind, läuft er ins Leere und das Thermostat bleibt auf Standby — der Bug ist wieder da. 30 Sekunden sind ein konservativer, erprobter Wert. Auf schneller Hardware kannst du auf 15 Sekunden runter, solltest dann aber über mehrere Neustarts hinweg verifizieren, dass es zuverlässig greift.

Was ist, wenn ich gar keinen Nachtmodus-Helper habe?

Dann brauchst du den choose-Block nicht. Lass nur den Default-Zweig stehen: 30 Sekunden delay, danach climate.set_hvac_mode heat und climate.set_preset_mode comfort für alle Thermostate. Den input_boolean.heizung_nachtmodus legst du nur an, wenn du tatsächlich eine nächtliche Absenkung möchtest.

Funktioniert das auch für andere climate-Integrationen, nicht nur KNX?

Ja. Das Muster — auf homeassistant-start triggern, kurz warten, bis die Entitäten verfügbar sind, dann den gewünschten Modus erzwingen — ist generisch. Jede climate-Integration, die nach einem Neustart in einen unerwünschten Default fällt, lässt sich so initialisieren. Nur die Entity-IDs und gegebenenfalls die Delay-Dauer passt du an.