It's a quiet bug that only bites you when the flat is cold in the morning: after every Home Assistant restart — an update, an add-on install, a container restart, a power cut — all of my KNX thermostats sat on 'standby'. No heating, no error, the mode simply gone. By the time I noticed it was usually hours too late and the radiators stone cold.
The cause is both harmless and infuriating: on restart the KNX integration briefly loses its connection to the bus, and many KNX climate actuators fall back to a safe default state — namely 'standby'. Home Assistant no longer knows the previous mode after the reboot and doesn't restore it on its own. The fix is a small but precisely timed startup automation. It cost me about 30 minutes — and the waking-up-cold problem has been gone ever since.
The symptom: 'standby' instead of 'heat'
Concretely: before the restart a thermostat is on hvac_mode: heat with preset comfort. After the restart the same climate entity shows standby (or 'off' on some actuators). The setpoint drops out of the control loop and the radiator stays cold. In the history graph you see the kink exactly at the restart moment. Important to understand: this is not a fault in your automations — it's an initialisation gap right after boot.
Why a simple 'set mode' call isn't enough
The obvious reflex — just fire climate.set_hvac_mode at startup — fails, because in the first seconds after boot the climate entities are often still unavailable. The KNX bus has to connect first, the actuators have to report their state. Send the command too early and it goes nowhere, leaving the thermostat on standby. That's exactly why the automation needs two ingredients: a trigger on HA start and a short wait until the bus is back.
The fix: a timed startup automation
The automation below triggers on the homeassistant start event, waits 30 seconds for the KNX bus to connect and all climate entities to become available, and then sets the right state depending on night mode: if night mode is on, every thermostat goes to preset economy; otherwise to heat plus preset comfort. A simple input_boolean helper — which I share with the master heating switch — drives the day/night branch.
- 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:
# the KNX bus needs a few seconds after the restart until all
# climate entities are connected/available again
- delay:
seconds: 30
- choose:
# night mode active -> 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
# otherwise day mode -> 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: singleThe entity list here targets my six rooms — replace it with your own climate. entities. The room names are generic placeholders; fill in office, living room, kitchen and so on exactly as they're named in your setup.
Why exactly 30 seconds of delay
The 30 seconds aren't arbitrary. On my system the KNX integration reproducibly took about 10 to 20 seconds after boot before all climate entities flipped from 'unavailable' to a real state. 30 seconds gives a safe buffer without noticeably delaying when the flat warms up. On slower hardware (a Raspberry Pi, lots of integrations) it can make sense to go to 45 or 60 seconds. Rule of thumb: better to wait a little too long than to send the command into the void.
If you want it more robust, you can replace the fixed delay with a wait_template that waits until a representative climate entity is no longer 'unavailable' — but for a home setup the plain 30-second delay is proven and entirely sufficient.
The day/night branch via choose
The choose block makes sure that a restart at three in the morning doesn't ramp everything up to full comfort temperature. If input_boolean.heizung_nachtmodus is 'on', all thermostats get the economy preset (set back); in the default branch — i.e. during the day — heat is set as the HVAC mode first, then comfort as the preset. I share this night-mode helper with the central heating switch, so startup and manual control use the same source of truth.
I use the same building-protection/preset logic in my window-contact-triggered frost-protection automation too — both act on the same thermostat pool, just on different occasions.
Testing without restarting Home Assistant
You don't have to fully reboot every time to check the automation. In Developer Tools you can trigger the automation manually via 'Run' — the homeassistant-start trigger is skipped, but the actions (delay + choose) run exactly as they would. First set a thermostat to 'standby' as a test and watch in the more-info dialog how it snaps back to 'comfort'/heat after a good 30 seconds. For the real test, do a deliberate restart and check the last-changed timestamps of the climate entities.
Frequently asked questions
Why do the KNX thermostats drop to standby on restart at all?
On restart the KNX integration briefly loses the bus connection. Many KNX climate actuators fall into a safe default on connection loss — often 'standby' or 'off'. Home Assistant does not reconstruct the previous mode after boot automatically, so the actuator stays in the default until something actively resets it. That's precisely the gap the startup automation fills.
Isn't a shorter delay than 30 seconds enough?
Possibly, but it's risky. If you send the command before the climate entities are available, it goes nowhere and the thermostat stays on standby — the bug is back. 30 seconds is a conservative, proven value. On fast hardware you can go down to 15 seconds, but then verify across several restarts that it reliably takes effect.
What if I don't have a night-mode helper at all?
Then you don't need the choose block. Keep just the default branch: 30 seconds delay, then climate.set_hvac_mode heat and climate.set_preset_mode comfort for all thermostats. You only create input_boolean.heizung_nachtmodus if you actually want a nightly set-back.
Does this work for other climate integrations, not just KNX?
Yes. The pattern — trigger on homeassistant start, wait briefly for the entities to become available, then force the desired mode — is generic. Any climate integration that falls into an unwanted default after a restart can be initialised this way. You only adjust the entity IDs and, if needed, the delay duration.
