Crossposted from my blog, where the rest of the KNX and Home Assistant series lives.
I lost an evening to this. I dragged the living-room thermostat in Home Assistant up to 24 degrees, watched the climate card show 24 for about a second, and then watched it quietly fall back to 23. Set it again. Same thing. The card behaves as if I never touched it. My first instinct was the usual one: something is broken in the KNX integration, or the bus is dropping the write.
Nothing was broken. The thermostat was doing exactly what KNX thermostats are designed to do, and Home Assistant's climate card has no good way to tell you that. Once I understood the five preset modes underneath it, the manual control doesn't work complaint turned out to be a design decision I had to work with.
The five modes hiding under one card
Every KNX thermostat in the house speaks the standard HVAC operating-mode object (DPT 20.102). That object has exactly five states, and Home Assistant surfaces them as preset modes on the climate entity: Standby, Building Protection (frost protection), Economy (the night setback), Comfort (day), and Auto. That dropdown of presets on the card is a direct view of a number the physical thermostat tracks on its own.
The detail that cost me the evening: of those five, only Auto lets you freely set a target temperature from Home Assistant. Comfort and Economy use a setpoint the device already holds. In my setup Comfort sits at around 23 degrees and Economy a couple of degrees lower, somewhere in the 19 to 20 range. Building Protection holds the room at roughly 7 degrees so a radiator never freezes. Those numbers live in the thermostat's own memory, not in Home Assistant.
Why the temperature snaps back
This is the sequence when you fight a Comfort-mode thermostat from the card. The thermostat is in Comfort, holding its device-fixed 23. You write 24. The card optimistically shows 24, because the write went out on the bus. A heartbeat later the thermostat re-publishes its stored Comfort setpoint on the read-back address, Home Assistant reads that value, and the card reverts to 23. The write did not get lost on the bus. The device overruled it, because it considers its stored setpoint authoritative while it is in Comfort.
# Why a manual change 'snaps back' in Comfort/Economy:
# 1. preset = Comfort (device-fixed ~23C)
# 2. HA writes 24C -> card briefly shows 24C
# 3. thermostat re-publishes its stored comfort setpoint
# on the target-temperature state (read-back) address
# 4. HA reads it back -> card reverts to 23C
# Fix: switch the preset to AUTO, THEN set any temp 18-25C.
The fix is simple: switch the preset to Auto first, then set whatever temperature you want. In Auto the setpoint is yours to write and it sticks. Comfort and Economy are read-only by design: Home Assistant can read what they hold and cannot overwrite it.
What the five address roles actually do
This makes a lot more sense once you've wired one of these entities up. Each KNX climate entity in my knx.yaml is configured with five group-address roles, and they map cleanly onto the behaviour above: current temperature (read-only), target temperature (the setpoint write), target temperature state (the read-back the device uses to overrule you), operating mode (the write that changes the preset), and operating mode state (the read-back of which mode the device is actually in). Min and max temperature clamp at 18.0 and 25.0, and the step is 0.5, so the card moves in half-degree increments.
climate:
- name: "Thermostat Office"
temperature_address: "1/0/1" # current temp (read)
target_temperature_address: "1/1/1" # comfort setpoint (write)
target_temperature_state_address: "1/2/1" # setpoint read-back
operation_mode_address: "1/3/1" # HVAC mode (write)
operation_mode_state_address: "1/4/1" # HVAC mode (read)
temperature_step: 0.5
min_temp: 18.0
max_temp: 25.0
One wrinkle worth knowing: on a couple of my thermostats the mode write and the mode state are separate group addresses, but on one of them I deliberately point both at the same address because that particular device just echoes its own mode back on the same object. Either works, as long as you match how the specific device behaves on the bus. I've abstracted the address above to a single illustrative example on purpose; the real per-room map is not something you want to publish.
How the automations actually use the modes
Once the modes are clear, the automations follow directly. I have roughly a dozen KNX climate zones across the house on a single KNX/IP gateway, and the day-to-day comfort comes from three patterns that all just push a preset.
The first is the daily schedule. A day mode automation runs at 06:00 and sets every thermostat to Comfort. An evening automation runs at 21:00 and drops them all to Economy for the night setback. I also wired the night setback to an input_boolean on the dashboard so I can flip the whole house into night mode by hand without waiting for 21:00 — handy when everyone's gone to bed early.
The second is the window logic, and it's my favourite use of Building Protection. When a window opens, an automation waits 5 seconds and then switches that room's thermostat to Building Protection, so the radiator stops dumping heat into an open room. When the window closes, after the same 5-second delay, it goes back to Comfort. There are more than a dozen of these, one per window-and-room pair. They never touch a temperature, only the preset, and that is why they are reliable.
The third is the boring one that saved me a cold morning. After a Home Assistant or bus restart, some thermostats come back up defaulting to Standby because they briefly lost their connection. Standby means the room silently stops heating, and you don't notice until it's cold. So a startup-initialise automation re-applies the correct presets on boot, so a reboot at 02:00 doesn't turn into a cold living room at 07:00. If you run KNX climate through Home Assistant, write this automation before you need it.
The trade-off
This is the part the climate card cannot tell you. The manual control doesn't work feeling comes from the KNX HVAC mode model showing through a generic climate card that was designed for thermostats with one free setpoint. Comfort and Economy are device-fixed by design; Auto is the free-setpoint mode. The card shows you all of it at once and trusts you to know which mode you're in.
That leaves a real choice, and I go back and forth on it. You can keep the schedule-plus-window setup, which gives you automatic night setback and open-window frost protection essentially for free, but you lose the ability to just grab a thermostat and override it, because Comfort will snap your change back. Or you run every zone in Auto all the time, which gives you full manual control from the card, but then you lose the automatic setback and the window-driven frost protection, because nothing is flipping presets for you anymore. The automatic behaviour and the manual override compete for the same setpoint, so there is no clean way to have both.
I keep the automated version, because the house heats itself sensibly 360 days a year and I only fight it on the handful of evenings I want it warmer than Comfort. On those nights I now just flip the room to Auto first, a one-second habit. If you're wiring KNX climate into Home Assistant, this is the part of the docs I wish I had read first: which preset owns the setpoint. The rest of how this house runs on Home Assistant — from the Docker-on-Azure install on up — is built from details like this one.
