Climate Seasonal Comfort Controller
A single blueprint that runs a climate device — heat pump, AC, or a heat-only / cool-only unit — the way you'd actually want it run all year: a proper comfort schedule, a winter/summer split, and a thermal-demand filter that stops it short-cycling, plus an opt-in stack of extras (presence, room vacancy, open-window response, frost protection, mould protection, condensation dry sweeps, timed boost) that you can turn on one at a time as you need them.
Almost everything is optional with sensible defaults. At its simplest you point it at a climate entity, tell it which modes the device has, give it a winter/summer helper, and enable one comfort period. Everything else layers on top only if you switch it on.
Two variants below — pick the one that matches your Home Assistant temperature unit. The sliders and internal maths are fixed to a unit, so a °F install needs the imperial variant and everything else needs metric. Don't mix them.
Import
Metric — °C (most installs outside the US)
Imperial — °F (Home Assistant set to Fahrenheit, e.g. most US installs)
Both variants are identical in behaviour — only the temperature units, slider ranges, and a couple of internal margins differ. If a button doesn't open the import dialog, install manually instead: Settings → Automations & Scenes → Blueprints → Import Blueprint, paste the matching Gist URL above, or download the YAML (the Gist's Raw button) into config/blueprints/automation/<your-folder>/.
Minimum Home Assistant version: 2024.10.0.
Highlights
- Seasonal — one automation handles both heating (winter) and cooling (summer), switched by a single helper.
- Comfort schedule — up to 10 time periods, each with its own days, window, and per-season target. The periods are the schedule and the permission gate.
- No short-cycling — a thermal-demand filter plus compressor minimum run/off timers decide when it actually switches.
- Opt-in everything else — presence, per-room vacancy, open-window response, frost protection, mould protection, dry/condensation sweeps, and timed boost are all independent toggles.
- Respects you — if you grab the remote or the app and change the unit yourself, it backs off. Works even on IR-controlled units that don't report who made the change.
- Device-aware — you select which HVAC modes your unit supports; it never tries to use one you didn't tick. Setpoints are clamped to the device's own min/max.
Features
Seasonal operation. A winter/summer binary_sensor (on = winter) drives the whole thing. The easiest source is a Threshold helper on an outdoor-temperature sensor, so the house flips to summer automatically once it warms up — but any binary sensor or a manual toggle wrapped in a template sensor works.
Comfort schedule (10 periods). Each period has winter and summer enable switches, a name, a start/end time, selected days, and separate winter and summer target temperatures. A period is active when it's enabled for the current season, the time is inside its window, and today is a selected day. If periods overlap, the most-recently-started one wins. Outside every period the unit follows your out-of-comfort action (off, or hold a setback).
Comfort bands. Targets are paired with a band (an offset). The unit doesn't chase the exact setpoint — it lets the room drift within the band before acting, which is gentler on the compressor.
Thermal-demand filter. The core anti-cycling brain. To start, the room has to be meaningfully off target (beyond the band). To keep running, it considers the room, an outdoor threshold, and — optionally — a weather forecast trend and/or an indoor temperature trend (via a Derivative sensor), so it doesn't stop a second before it's actually warm/cool enough.
Compressor protection. Independent minimum run-time and minimum off-time, so nothing flaps on and off.
Presence (optional). Configure occupancy entities (people, phones, zone.home, or sensors) and comfort only runs while someone's home — heating starts once presence is detected. A guest-mode toggle keeps the house "occupied" even when trackers leave. Leave presence empty to run purely on the schedule.
Room vacancy (optional). Point it at a per-room presence/mmWave/motion sensor and it eases the room back (then optionally off) when the room itself is empty, in two configurable stages, even while the rest of the house is occupied.
Open window / door (optional). Door and window sensors trigger a two-stage response — ease the target back first, then optionally switch off after a longer delay — so you're not heating the street.
Frost protection (optional). An absolute safety floor: if the room falls below your frost minimum it forces heat to protect the space, overriding manual holds, boost, open windows, and even summer mode. Has its own hysteresis so it doesn't chatter.
Mould protection (optional). A humidity-driven warmth floor. When indoor RH climbs past your threshold it gently holds a minimum temperature to discourage mould. Point it at a mean-RH statistics helper for sustained tracking rather than instantaneous spikes.
Condensation / dry mode (optional). A moisture-mitigation mode, not a comfort mode. In winter it estimates the indoor dew point and runs short dry (dehumidify) sweeps when condensation is likely on the glass. It never overrides heating, yields to an open window or a manual change immediately, and has its own minimum-run, minimum-off, and maximum-runtime caps. Run it only when the house is empty, only inside a scheduled window, or both.
Timed boost (optional). A dashboard button that temporarily nudges the target (warmer in winter, cooler in summer) by your amount for a set duration, then switches itself off. Works relative to the active period — or to the setback when no period is active.
Manual-override awareness. If you change the unit yourself it stands down for a configurable period. The recommended path uses an input_boolean helper, which makes this reliable even on IR/SmartIR/Broadlink setups that can't tell HA who changed the device; there's also a context-based fallback if you don't add a helper.
Quality-of-life. Optional one-line status string written to an input_text helper (great on a dashboard), an unavailable-entity guard, and automatic setpoint clamping to the device's reported limits.
Requirements
Required
- A
climateentity — heat pump, AC, or a heat-only / cool-only device. - The list of HVAC modes your device actually supports (heat / cool / dry).
- A winter/summer
binary_sensor(on = winter). A Threshold helper on an outdoor temperature sensor is the easy option. - At least one enabled comfort period (otherwise there's nothing scheduled to run).
Optional — add only for the features you want
- Manual-override helper — an
input_boolean. Strongly recommended for IR-controlled units. - Room temperature sensor — otherwise it uses the climate entity's own reading.
- Outdoor temperature sensor — improves the keep-running logic; required for dry/condensation.
- Indoor temperature + humidity sensors — required for dry/condensation (dew-point).
- Humidity sensor — for mould protection.
- Weather entity — for the forecast-trend keep-running option.
- Derivative sensor — for the indoor-trend start option.
- Occupancy entities —
person,device_tracker,zone, orbinary_sensor. - Room presence sensor(s) — mmWave / motion, for room-vacancy easing.
- Window/door
binary_sensors — for the open-window response. input_booleanhelpers — guest mode, dry-mode runtime switch, boost button.input_texthelper — for the status string.
How it works (the model)
- Periods are both the schedule and the gate. When a period is active it sets the target; when none is active the unit follows your out-of-comfort action.
- Bands are offsets, not absolute temperatures. They define how far the room may drift before the unit acts.
- The thermal-demand filter decides when, not what. Targets come from the schedule; this layer decides whether running is actually justified right now.
- Priority, roughly top to bottom:
- Climate entity unavailable → do nothing.
- Frost protection (if enabled) overrides everything else.
- Your manual changes are respected (except while frost protection is active).
- Normal operation follows the schedule for the active season, with boost, room-vacancy, and open-window responses layered on, mould protection acting as a warmth floor, and dry sweeps running opportunistically only when heating isn't needed.
- Compressor timers and the demand filter govern the actual switching throughout.
Quick start (minimal setup)
- Import the variant that matches your unit system and create an automation from it.
- Climate Device — pick your
climateentity and tick the modes it supports. - Season Mode — choose your winter/summer
binary_sensor. - Comfort Period 1 — enable it for the season(s) you want, set the days, the time window, and a target temperature.
- Save. That's a working schedule with anti-cycling.
- Add features later by opening the relevant (collapsed) section and switching it on.
Notes & caveats
- Pick the variant that matches your HA temperature unit and don't mix them — the slider labels, ranges, and a few internal margins are baked into each unit. The two are otherwise behaviourally identical.
- IR / SmartIR / Broadlink units: add the manual-override
input_booleanhelper. Without it, manual changes from a physical remote can't be detected reliably (the integration doesn't preserve change context). - After updating the blueprint, reload it and — if any inputs changed — re-create the automation from it. Home Assistant caches blueprint inputs, so an automation built from an older copy keeps the old fields and layout until re-created.
- Tested on real hardware, including an IR-controlled Hitachi heat pump via SmartIR.
Changelog
- v1.0 — initial release (metric and imperial variants).
Feedback, bug reports, and feature ideas welcome — reply below.