Extreme Heat - Sun not in FOV - Cloud suppression - keep cover closed?

[isi07]

Hi
I have a question and maybe proposal of handling cover under Extreme Heat in Climate Settings.

I have an observation, that my vertical cover is moving up under extreme heat condition, while sun is in FOV but then cloud suppression is activated (happening around 20:00 in my local timezone CET).
Only 15 min later sun moves out of FOV and outside temperature is stillabove extreme heat threshold and then cover is closed again under extreme heat (happening at 20:16 in my local time zone CET).

Would it not make sense during extreme heat to ignore cloud suppression while sun is in FOV and keep cover closed?
Also when sun is not in FOV, cover is closed under extreme heat.

config_entry-adaptive_cover_pro-01KXBBSEM637NQPATE6S7XBYM0(1).json

Thanks for consideration
Christian

Deine Beschattung
Vertikale Jalousie steuert cover.og_5_schlafzimmer_rollladen_fenster
1.2m hohes Fenster, Sonne 0.5m vor dem Glas blockiert (Laibung 0.15m, Fensterbank 0.95m)
🏢 Verknüpft mit Gebäudeprofil: ACP Building Profile Zuhause Kirchstrasse 45

So wird entschieden (erste zutreffende Regel gewinnt)
[80] ✋ Manuelle Übersteuerung: pausiert automatische Steuerung, wenn du die Beschattung bewegst (pausiert für 2 h, Übergangszeitüberschreitung: 30s)
[76] 🎯 Benutzerdefiniert #1: wenn binary_sensor.og_5_schlafzimmer_kontakt_fenster aktiv ist → 22% (als Minimum) — umgeht Delta-Gatter und automatische Steuerung
[60] ☁️ Wolkenunterdrückung: überspringt Sonnenverfolgung wenn is_sunny=binary_sensor.beschattung_status_sonne_scheint → Standard (100.0%)
[50] 🌡️ Klimamodus: passt Strategie für Heizung/Kühlung an (Komfortbereich 20–23°C, mit sensor.og_5_schlafzimmer_thermostat_temperatur, außen: sensor.og_4_balkon_sensor_temperatur_temperatur > 28°C, durchsichtige Jalousie, schließt sich vollständig bei Sommerhitze, hält den ganzen Tag 10.0% bei über 30°C außen)
[40] ☀️ Verfolgt die Sonne (Azimut 342.0°, ±80.0°/80.0° Sonnen-Akzeptanzwinkel, Höhe über 5.0°) und berechnet Position, um direkte Sonneneinstrahlung zu blockieren (heute: Sonne im Fenster 18:00 → 20:10)
🕒 Aktiv während Tageslicht.
🌅 Nach Sonnenuntergang (über input_datetime.wecker_raum_tag_ende_og_5_schlafzimmer) → 0%.
🌄 Nach Sonnenaufgang (über input_datetime.wecker_raum_tag_beginn_og_5_schlafzimmer) → 100.0% (Verfolgung fortgesetzt).
🌗 Tageslicht-Gate: input_boolean.wecker_raum_ist_tag_og_5_schlafzimmer entscheiden über Tag vs. Dunkelheit.
Wenn das Gate Tag anzeigt, lädt ACP die Sonnennachführung; wenn es Dunkelheit anzeigt, wendet ACP die Sonnenuntergangsposition an. Das Gate ersetzt die astronomische Sonnenuntergangs-/Sonnenaufgangsgrenze; Start-/Endzeiten begrenzen das Fenster weiterhin.
[31] 🎯 Benutzerdefiniert #2: wenn Template aktiv ist → 10% (als Minimum) — umgeht Delta-Gatter und automatische Steuerung
[0] 🌙 Standard (keine Regel trifft zu) → 100.0%

Positionsgrenzen
Bereich: 0.0%–100.0% · Standard: 100.0% · Min Änderung: 3.0% · Min Intervall: 8.0 Min · Positionstoleranz: 3.0% · 📍 Positionsabgleich aus (Befehl wird einmal gesendet; Abweichung wird als manuelle Übersteuerung behandelt) · Offen/Geschlossen-Schwellwert: 50.0% · Sonnenverfolgung Min: 17.0%
🎛️ My-Preset-Entitäten: deaktiviert

Proxy-Beschattung: deaktiviert

Entscheidungspriorität (höchste gewinnt, ✅ aktiv ❌ nicht konfiguriert)
❌Weather → ✅Manual → ✅Lüftungsposition(76) → ❌Motion → ✅Cloud → ✅Climate → ❌Glare → ✅Solar → ✅Nacht auf 10%(31) → ✅Default

[jrhubott]

Hi Christian,

You're right that losing the extreme-heat hold to Cloud Suppression at peak heat, with the sun still on the window, is backwards. It's a protective hold, not a comfort tweak, and it shouldn't fold that easily. But I don't want to fix it by swapping the default order of Cloud Suppression and Climate. Cloud Suppression sitting above Climate is correct for every other Climate branch. Summer cooling, winter heating, and the low-light path all need to keep losing to Cloud Suppression on an overcast day, and swapping the two globally would fix your case while breaking those.

What I've opened #1272 to track instead is narrower: making Cloud Suppression stand down specifically when the extreme-heat hold is active. The priority chain stays exactly as it is, 60 for Cloud Suppression, 50 for Climate. The only change is that suppression defers when a protective heat hold is in force.

Here's why it behaves the way it does today. Cloud Suppression runs at priority 60, Climate at 50, so when your sunny sensor (binary_sensor.beschattung_status_sonne_scheint) flips off while the sun is still inside your window's field of view, Cloud Suppression matches first and sends the default position, 100% in your case. The extreme-heat 10% hold is still being computed at priority 50 the whole time; it's just outranked.

That's also why it closes again 15 minutes later at 20:16. Cloud Suppression only fires while the sun is actually in the window's FOV. I added that guard deliberately in issue #417, ahead of everything else in the handler, so suppression can never override the default position once the sun has left the tracking window. Your summary shows "Sonne im Fenster 18:00 → 20:10," so at 20:10 the sun exits FOV, Cloud Suppression stops matching, and Climate becomes the top match again. The extreme-heat hold takes over and closes you to 10%, which is the move you saw at 20:16.

In the meantime, there are two ways to get closer to the behavior you want without waiting on #1272. The built-in handler priorities have been configurable per cover since v2.29.0, in the "🔀 Handler Priorities" step of the options flow. Put Climate above Cloud Suppression, Climate to 65 or Cloud Suppression down to 45, and the extreme-heat hold wins while the sun's still in FOV. It's the blunt option though: it's global for the cover, not scoped to extreme heat, so it also puts those same three Climate branches ahead of Cloud Suppression. On an ordinary overcast day, Climate would drive the position instead of falling back to default, and that global side effect is exactly why I don't want to ship the swap as the default.

The custom-position slot is closer to where I actually want to land: a template trigger on your outdoor temp sensor, above the extreme-heat threshold, set to the hold position, at a priority above 60. You're already doing this at priority slots 31 and 76, so the pattern should feel familiar.

Let me know how the workaround behaves for you in practice. That feedback's useful either way while #1272 is open.

For details, see the Custom Position wiki page.

[isi07]

Hi Jason,
Thanks a lot for your reply. I read also through the other linked issues/discussions in your reply.
I am now trying a third way:
In my cloud coverage settings I am using a binary sensor for the is_sunny condition.
Since one of the recent updates you are also offering to add a template condition to this setting and combine the binary sensor and the template expression with logical OR.
So I add an expression whether the outside temperature sensor is above the same threshold as the extreme heat temperature in the climate settings.
My expectation is that theen the is_sunny condition will remain true in any case, even if thee binary cloud sensor is turning false.

I was checking whether I could also use the climate_status entity in the ACP entities, but it does not seem to reflect the extreme heat status.

Tomorrow is next hot day, I will report how this works.

Maybe is an idea for ACP to include a setting in the light and cloud flow, to offer the user a switch to use Extreme Heat as bool expression as a logical OR to all the other condiitons in this page?

[isi07]

my workaround above has worked out pretty well today. The covers have kept closed today at extreme heat temperatures even in the early evening when the sun llight has decreased and usually is_sunny would have turned false.
Thanks