[Feature] Extreme heat mode — keep shutters closed all day when outdoor temp exceeds threshold

[FredM67]

Use case

Well-insulated houses (low-energy builds, near-passive) accumulate heat differently from standard construction. During a heatwave (outdoor temp reaching 35–41°C), keeping shutters closed all day — even when the sun has moved away from the window — is the correct strategy: radiated heat from the hot wall, warm air convection through the glass, and thermal mass all contribute to indoor overheating regardless of direct sun exposure.

The current Climate Mode closes shutters only when the sun is in the FOV (cover_valid AND is_summer). Once the sun leaves the window, the shutter opens back to default position — exactly the wrong behaviour during a heatwave, since the wall is still radiating heat at 41°C.

---

Proposed feature: Extreme Heat mode

Add two new parameters to Temperature & Climate:

Parameter	Description
Extreme heat threshold (temp_extreme_heat)	Outdoor temperature above which extreme heat mode activates. Suggested default: none (disabled). Example: 35°C.
Extreme heat position (extreme_heat_position)	Position to hold all day while extreme heat is active. Default: 0% (fully closed). Could also be set to a "My" position value for partial closure.

Behaviour: When outdoor temperature > temp_extreme_heat, the climate handler closes the shutter to extreme_heat_position regardless of sun position, time of day, FOV, or presence. The cover stays there until the outdoor temperature drops back below the threshold (with the existing weather_timeout-style hysteresis if desired).

This is distinct from normal summer mode (temp_high), which only closes when the sun is geometrically in the FOV. Extreme heat mode acts as a day-long hold, not a sun-tracking response.

---

Decision tree placement

The new rule would sit above the existing summer rule in all four climate rule tables (NORMAL_WITH_PRESENCE, NORMAL_WITHOUT_PRESENCE, TILT_WITH_PRESENCE, TILT_WITHOUT_PRESENCE) in pipeline/handlers/climate_modes.py:

is_extreme_heat (outdoor temp > temp_extreme_heat)
  → extreme_heat_position (regardless of cover_valid / FOV)
is_summer (temp > temp_high AND outdoor > outside_threshold AND cover_valid)
  → 0% (existing behaviour)
...

And in ClimateHandler.evaluate() (pipeline/handlers/climate.py lines 410–425):

if climate_data.is_extreme_heat:
    method = ControlMethod.EXTREME_HEAT, season = "extreme heat"
elif climate_data.is_summer:
    method = ControlMethod.SUMMER, season = "summer"
...

---

Implementation sketch

const.py

• CONF_TEMP_EXTREME_HEAT = "temp_extreme_heat" (sibling of CONF_TEMP_HIGH)
• CONF_EXTREME_HEAT_POSITION = "extreme_heat_position" (clearable, default 0)
• ClimateStrategy.EXTREME_HEAT = "extreme_heat"
• ControlMethod.EXTREME_HEAT = "extreme_heat"

pipeline/types.py — ClimateOptions

• Add temp_extreme_heat: float | None = None
• Add extreme_heat_position: int | None = None

pipeline/handlers/climate.py — ClimateCoverData

• Add temp_extreme_heat: float | None
• Add extreme_heat_position: int | None
• Add is_extreme_heat computed property: outside_temperature > temp_extreme_heat (when both defined)

pipeline/handlers/climate_modes.py — all four rule tables

• Prepend one rule before the existing summer rule: is_extreme_heat → extreme_heat_position

pipeline/snapshot_builder.py — build_climate_options()

• Populate the two new fields from options

config_dynamic.py — temperature_climate_schema()

• Add CONF_TEMP_EXTREME_HEAT threshold field (accepts number or Jinja2 template, same as CONF_TEMP_HIGH)
• Add CONF_EXTREME_HEAT_POSITION clearable position field

config_fields.py — add the two new fields to the registry

migrations.py — minor version bump, additive only

---

Workaround with current version

This can be approximated today with a Custom Position slot:

Condition Template: {{ states('sensor.outdoor_temp') | float > 35 }}
Position: 0%  (or use My position)
Priority: 51  (above climate=50, below cloud suppression=60)

This works but has two drawbacks: it bypasses the climate handler entirely (so the climate_status diagnostic sensor doesn't reflect it), and it requires the user to know about the pipeline priority system.

---

Related

• Climate Mode
• Configuration — Climate
• pipeline/handlers/climate.py — ClimateCoverData.is_summer (lines 101–105)
• pipeline/handlers/climate_modes.py — NORMAL_WITH_PRESENCE rule table

[jrhubott]

I looked into this alongside #548 (the open tracking_seasons POC), since the two overlap heavily.

They pull in opposite directions on the same machinery. #548 restricts existing behaviour — in deselected seasons it suppresses glare tracking and falls back to the default position; it never forces a cover closed. #766 adds behaviour — a force-close hold above an extreme-heat threshold, regardless of sun/FOV/presence. Today summer-close only fires when the sun is in FOV (and, for occupied blinds, only when transparent_blind is set), so an all-day heatwave hold is genuinely something no current rule does. #485 asked for the same thing and was answered with the custom-position workaround, so the demand is real and there's no built-in for it.

But structurally they're nearly the same change. Both add a new config option, a ClimateOptions/ClimateCoverData/ClimateContext field with passthroughs, a new ClimateStrategy member, a rule injected into the four climate rule tables, an evaluate() season-label branch, a diagnostics reason, the config-flow selector + sync frozensets, services + options_service, and the shared en/de/fr climate description. If both land independently, ~10 of the ~13 touched files conflict.

Placement correction: the sketch says the extreme-heat rule sits "above summer." It actually needs to sit at the top of each table — above winter — or winter-heating/low-light would pre-empt it on a flagged-but-briefly-cold heatwave morning. A few other gaps: the four rule tables aren't uniform in branch order; the numeric extreme_heat_position needs an OPTION_RANGES / config_fields.py entry (a select like #548's doesn't); migrations.py is probably unnecessary (the last additive climate option shipped without one); and a literal 0% hold still needs the usual tilt/inverse-state/awning handling the sketch omits.

Recommendation: unify rather than ship two parallel flags. Both are "season/threshold → override the glare branch" rules differing only in trigger, target position, and placement. A single seam that injects an ordered (predicate, target_position_fn, strategy_label) list into the tables carries both: #548's gate = (season ∉ selected → default), #766's hold = (outside_temp > extreme → extreme_heat_position) at top priority. That removes the duplicated plumbing, avoids the merge conflict, and matches what the #548 author already mused there — "maybe this needs a more general way instead of adding more and more small flags." If they must be decoupled in time, land #548 first, then build #766 against it.

[FredM67]

Thanks for the thorough analysis — and for catching the placement issue. You're right that the extreme-heat rule needs to sit at the top of each table, above winter-heating. A briefly cold heatwave morning (outdoor temp not yet at threshold but climbing) should still be handled by the normal rules; once the threshold is crossed it should override everything including winter-heating, since a 6am reading of 28°C on a day heading to 41°C is not a reason to open the blind for solar gain.

The unification with #548 makes sense. The (predicate, target_position_fn, strategy_label) seam is the right abstraction — both features are just entries in an ordered override list differing only in trigger and target. Happy to wait for #548 to land first and build this against it rather than creating a parallel conflict. Whenever #548 is ready, we can pick this back up.

[elmakus]

Just to add another real-world example: I am using Custom Position slots for a very similar heat-lock use case.

In my setup I use different Custom Position slots depending on whether someone is home or not:

• If nobody is home, the heat-lock helper can become active much earlier, around room target temperature - 2°C. In that case I can use a more aggressive target, for example fully closed 0/0, because nobody is in the room and daylight does not matter.
• If someone is home, the heat-lock helper only becomes active at a higher threshold, around 30°C room temperature. In that case I prefer a less aggressive target, for example 30/0, because fully closing the cover during the day makes the room too dark.

I also combine this with an additional “microseason” helper.

My microseasons are calculated from the weekly average temperature. Based on that, my home is classified into something like:

winter
early spring
spring
early summer
summer
early autumn
autumn
late autumn

From late autumn through spring, I want my apartment to collect as much solar heat as possible during the day, and also lose as little heat as possible through the windows.

In the warmer microseasons, I want the opposite: avoid collecting heat from direct sun, and avoid gaining heat through the windows from hot outside air.

So the heat-lock helpers I mentioned above also include a condition that the current microseason must be in the range where I do not want heat from outside.

At first I considered requesting something like a dedicated “extreme heat” enhancement, but in my case I actually think using Custom Position slots makes a lot of sense, because it gives more control and flexibility. I can define different behavior depending on presence, room temperature, home/away state, and microseason.

For example, I originally wanted to use a fully closed target, 0/0, also when someone is home. But in practice that made the room too dark during sunny days. My wife had to turn on the light even during the day, so for the “someone is home” case I changed the target to something like:

position: 30
tilt: 0

For us this is a better compromise: it still reduces heat gain, but keeps some usable daylight in the room.

So from my perspective, Custom Position is actually a good way to implement this kind of flexible heat-lock behavior, as long as handler transitions are reliable and Custom Position can react immediately when the helper state changes.

[FredM67]

Just to add another real-world example: I am using Custom Position slots for a very similar heat-lock use case.

In my setup I use different Custom Position slots depending on whether someone is home or not:

• If nobody is home, the heat-lock helper can become active much earlier, around room target temperature - 2°C. In that case I can use a more aggressive target, for example fully closed 0/0, because nobody is in the room and daylight does not matter.
• If someone is home, the heat-lock helper only becomes active at a higher threshold, around 30°C room temperature. In that case I prefer a less aggressive target, for example 30/0, because fully closing the cover during the day makes the room too dark.

I also combine this with an additional “microseason” helper.

My microseasons are calculated from the weekly average temperature. Based on that, my home is classified into something like:

winter
early spring
spring
early summer
summer
early autumn
autumn
late autumn

From late autumn through spring, I want my apartment to collect as much solar heat as possible during the day, and also lose as little heat as possible through the windows.

In the warmer microseasons, I want the opposite: avoid collecting heat from direct sun, and avoid gaining heat through the windows from hot outside air.

So the heat-lock helpers I mentioned above also include a condition that the current microseason must be in the range where I do not want heat from outside.

At first I considered requesting something like a dedicated “extreme heat” enhancement, but in my case I actually think using Custom Position slots makes a lot of sense, because it gives more control and flexibility. I can define different behavior depending on presence, room temperature, home/away state, and microseason.

For example, I originally wanted to use a fully closed target, 0/0, also when someone is home. But in practice that made the room too dark during sunny days. My wife had to turn on the light even during the day, so for the “someone is home” case I changed the target to something like:

position: 30
tilt: 0

For us this is a better compromise: it still reduces heat gain, but keeps some usable daylight in the room.

So from my perspective, Custom Position is actually a good way to implement this kind of flexible heat-lock behavior, as long as handler transitions are reliable and Custom Position can react immediately when the helper state changes.

That looks mega great.
Could you please share your whole config around that, maybe in a dedicated "Community" category in the discussions?

[Nipal33]

Would love this feature as well.
Untill this week, I was doing it by disabling ACP and taking over through automation management.
Since this week I moved to use custom position because climate is not good enough for this case. I do something very similar to FredM67 except I'm a bit more aggressive (don't care if someone is home, they can turn the light on :D).

I would definitely use this feature, I would love it even more if we can manage some of the variables/flags (season, heat wave start and stop criteria etc.) directly in ACP.

[FredM67]

don't care if someone is home, they can turn the light on :D

I don't care either, lol.
Led spot takes 4-5W, that's peanuts 😎

[elmakus]

Haha, for me it is not really about electricity cost either 😄

I agree that fully closing the cover may make more sense from a pure heat-protection point of view. But in my case it is more about Wife Acceptance Factor.

Happy wife, happy life 😄

[FredM67]

Happy wife, happy life 😄

Yeah... Fully agree 😁

[jrhubott]

I will start working on this one as soon as PR548. I'm just worried with the number of configuration options that are now available. Both from confusing new users and also a large maintenance and sometime conflicting demands on how it should work.

[FredM67]

I will start working on this one as soon as PR548. I'm just worried with the number of configuration options that are now available. Both from confusing new users and also a large maintenance and sometime conflicting demands on how it should work.

Agree... Let try to find a way to organize all of that as simple and intuitive as possible

[elmakus]

That looks mega great. Could you please share your whole config around that, maybe in a dedicated "Community" category in the discussions?

#798

[Nipal33]

I will start working on this one as soon as PR548. I'm just worried with the number of configuration options that are now available. Both from confusing new users and also a large maintenance and sometime conflicting demands on how it should work.

For what it's worth:
I did all the initial config myself with Advance Cover. It was not easy, took a lot of time but I managed to make it "not bad at all".
Recently, I started to use Claude on HA with MCP, and when I wanted to improve my setup, working with Claude, I identified that I needed the minimum elevation which is not available in AC, only in ACP. This made me move to ACP.
I discovered how rich it was and moved as much as possible what I was doing outside, in automations, inside of ACP (custom slots, sunset positions, etc.).

Claude was a massive help ; you can just measure the glare on the ground, tell Claude to reverse engineering and it will tell you "everything" you need to change. And it is really accurate.
It was difficult for Claude at first as he was proposing some modification which are dumb but efficient, like changing the shaded area. But once it understood what I was happy to work on (azimuth, fov, elevation, obstacles etc.), it was really efficient to configure the ACP entities.

I saw you have a claude/skills for diagnostic (which I gave to my Claude so he can investigate efficiently), could be an option to build a skill for configuration so people could get the help of Claude to find what they need as this integration is very rich and getting even more features and options.

Just an idea.
Anyway, love what you built and the enhancements you continue to propose.