It's crazy how many different scenarios I have to take into account. But I think I've found the bug. It's been fixed here.
New update
CCA 2026.05.29
Fix: Shading never executed when pending-start (pnd=beg) armed before the opening time window and the opening trigger fired at window-start — the opening handler's "Shading detected" branch matched on helper_state_pending_start, cleared the pending state (pnd=non, ts.due=0) without driving the cover (because effective_state != 'shd' while shd was still 0), causing the t_shading_start_execution trigger to be silently killed. The opening handler now defers to the execution trigger: a new "Opening skipped: Shading start pending" branch preserves pnd, ts.due, and ts.arm, updates only the base state (bas=opn, ts.opn), and lets the execution trigger fire 1 second later to handle the drive — including the correct retry/abort logic for manual overrides.
will this also fix the error, that if resident is active and sun shading becomes true in the meantime, that after switching resident off, it will go directly from opening to sun shading? With 28.05V2 it will open the cover and sun shading never comes true on that day.
As i understand this is working only using the „Force sun shading“ action and checks „only“ the postion of the sun to the window. Other conditions are ignored.
Will this also force sun shading in winter, temperature below set treshold or cloudy forecast?
The Window-Sun-Angle recipe works only through the Force Activation
Sun Shading via Entity input. Force functions sit at the top of the
priority cascade, so when your binary sensor turns on, the cover shades immediately — the blueprint's normal shading conditions (brightness,
temperature threshold, weather forecast, elevation window) are skipped
entirely.
So out of the box: yes, it will force shading in winter, below your
temperature threshold, and on cloudy days — because the sensor from the
recipe only checks the sun-to-window geometry, nothing else.
The fix: the sensor is the decision, so add any conditions you want
directly into the binary sensor template via and:
template:
- binary_sensor:
- name: "Kitchen Window Sun Direct"
unique_id: kitchen_window_sun_direct
device_class: light
state: >
{{ states('sensor.kitchen_window_sun_similarity') | float(0) > 30
and is_state('binary_sensor.kitchen_window_contact', 'off')
and states('sensor.outdoor_temperature') | float(0) > 22
and states('sensor.outdoor_brightness') | float(0) > 30000
and state_attr('weather.home', 'cloud_coverage') | float(100) < 60 }}
This way it only shades when the sun hits the window and it's warm,
bright, and not too cloudy — and the window-contact gate keeps lockout
safety intact. Don't forget to enable Return to Target State After
Force Disable so the cover returns cleanly when the sensor goes off.
Hi,
I have a bit of a struggle with the blueprint, because I want to archive 4 things:
I want the shutter to open/close automatically based on time of day in combinition with the sun position - works
I want it to open automatically in the morning, when I open the window (which is possible via the Ventilation setting in combination with a window sensor) - works
I want it NOT to open in the morning as long a someone is laying in the bed (possible via a sensor under the mattrass) - works
I want to be able to tilt the window during night time for fresh air without any position change of the shutter, no matter if window tilt, mattrass occupancy sensor or anything
and the latter is my problem... I archived the possibility to tilt the window at night by setting up a additional condition for start ventilation on a time basis...
but in this setup, if I have to get out of bed during night, the shutter opens
How to deactivate?
Even if Forecast Temperature is valid, shading should start only if Azimut is in a valid range.
Does not make sense to start shading, if the sun is not close to the windows.
Hi Skol, this is expected behaviour, not a bug — and you found the right cause. The "Independent Shading via Temperature Comparison" option is designed to bypass all other conditions, including the sun azimuth and elevation. Its purpose is to decide early — from the forecast temperature alone — that the day will be hot, and move the blinds straight into the shading position before the sun even reaches the facade. That's why the azimuth (64.5°, outside your 110–290° range) and the low elevation are ignored in your trace: independent_temp_valid=true short-circuits the whole AND/OR block.
Note that the bypass is not limited to the morning — it applies whenever a shading-start trigger fires while the forecast stays above the Independent Temperature Threshold (25 °C in your case).
To deactivate: open Sun Shading – Configuration and uncheck "Independent Shading via Temperature Comparison". Shading will then start only when the normal AND/OR conditions — including the sun azimuth/elevation — are met.
I've clarified the in-app description for the next release so this is obvious up front.
I had a look at how the blueprint handles this, and I think I can explain what's going on.
Why it happens
Your mattress sensor acts as the Resident sensor. Getting out of bed is an
ON→OFF transition, which makes CCA run its "Resident leaving" handler. That
handler drives the cover to whatever the current target state is.
The key part is the "target OPEN" branch. It fires when:
base state == 'opn' (the time/sun schedule has already flipped to "open"), and
you have "open when resident leaves" enabled.
So the cover going up at night isn't really triggered by you leaving the bed —
it's that the base state is already open, and your presence in bed was the only thing keeping the shutter down (privacy / "don't open while someone is
lying there"). The moment you get up, that hold is released and the OPEN branch
runs.
This is very likely a sunrise timing issue: at this time of year the sun
comes up extremely early, so if your opening is sun/brightness based, the base
state switches to open around dawn — i.e. in the middle of your "night".
Why the usual workarounds don't help here
The ventilation time condition you added only gates the ventilation
branches. The wake-up movement runs through the OPEN branch, which does not check the opening condition.
Manual override / "ignore after manual" is intentionally bypassed by the
resident handler (a presence change is treated as a hard reset).
The only thing that stops the OPEN branch is its first condition: the base state
must not be open yet.
What I'd try
Limit opening by time so the base state only flips to open at your
actual wake-up time (use the earliest up time rather than pure sun/brightness).
Then at night the base state is still closed, and getting up just lands in
the CLOSE branch → no movement.
Keep your early-morning fresh-air opening via fully opening the window
(lockout) — that works independently of the base state and of the
ventilation condition.
If you can confirm whether the shutter goes fully up or only to the ventilation position when you get up at night, and how you open in the
morning (time / sun / both), I can point you to the exact settings.
Improvement: Clarified the description of "Independent Shading via Temperature Comparison". The text now states explicitly that this mode bypasses the sun position (azimuth and elevation) and brightness, that shading can therefore start even when the sun is not on the facade, and that the bypass is not limited to the morning but applies all day while the temperature stays above the threshold. Users who want shading to keep respecting the sun position should leave the option unchecked
Feature: New option for reset manual override "reset in position". This option will automatically clear the manual override state and restore automatic control once the cover reaches a specific target position (± configured tolerance) and remains there for the duration of the defined timeout. Use Case: Keep the blind in manual mode after lowering it by hand, and only let the automation take over again once the blind is fully reopened to 100%. Many thanks to @wildcs for contributing this feature (#506)
Fix: Four handlers could drive the cover to the ventilation position even when ventilation was blocked by resident_allow_ventilation or the Additional Condition For Activating Ventilation — only the contact handler correctly checked both gates. The affected branches are: (1) the closing trigger's tilted branch, (2) "Ventilation after shading ends", (3) "Resident leaving: target VENTILATION (window tilted)", (4) "Resident arriving: window tilted → hold ventilation position", and (5) "Force disabled recovery: return to VENTILATION (window tilted)". All five now evaluate resident_flags.allow_ventilate and auto_ventilate_condition; when not met the branch is skipped and the cover follows the normal schedule instead (#504)
CCA 2026.05.30
Fix:"Don't end shading if cover is already closed" no longer ends shading (opening the cover) when the cover was manually closed further than the configured close position. The guard checked in_close_position, which is a tolerance window centered on the configured close position — a cover driven below that position (e.g. fully closed at 0 % while the close position is 15 %) was treated as "not closed", so shading ended and the cover opened. The condition now also treats a position below the close position (current_below_close, awning-aware) as closed (#502)
CCA 2026.05.29 V3
Fix: When a resident was present and shading conditions became true in the meantime (shading blocked by resident presence because resident_allow_shading was not configured), the cover opened normally after the resident left but shading never activated on that day — the sun-position template triggers only fire on FALSE→TRUE transitions and do not re-fire when conditions were already TRUE during residence. resident_flags.allow_shade is removed from the top-level "Check for shading start" conditions so the pending mechanism arms normally; the existing "Save shading state for the future" branch in the execution handler is extended with OR not resident_flags.allow_shade, so it saves shd=1 alongside the already-handled effective_state == 'cls' case. The existing "Resident leaving: target SHADED" branch then drives to the shading position when the resident leaves.
CCA 2026.05.29 V2
Fix:ts.opn no longer overwritten by the late opening trigger when the cover was already opened earlier the same day. The "Already in open position" branch now catches all cases where the cover is at open position with effective_state=opn — including the case where bas=opn and ts.opn is already from today. ts.opn is only refreshed when there is a real base-state transition or when the timestamp is from a previous day; otherwise the existing value is preserved. Additionally, the late trigger no longer redundantly drives the cover or clears the manual override (#495)
CCA 2026.05.29
Fix: Shading never executed when pending-start (pnd=beg) armed before the opening time window and the opening trigger fired at window-start — the opening handler's "Shading detected" branch matched on helper_state_pending_start, cleared the pending state (pnd=non, ts.due=0) without driving the cover (because effective_state != 'shd' while shd was still 0), causing the t_shading_start_execution trigger to be silently killed. The opening handler now defers to the execution trigger: a new "Opening skipped: Shading start pending" branch preserves pnd, ts.due, and ts.arm, updates only the base state (bas=opn, ts.opn), and lets the execution trigger fire 1 second later to handle the drive — including the correct retry/abort logic for manual overrides.
@Herr.Vorragend: i got a mysterious situation today!
cover gone to shading as he should, statushelper got to shading.
About 1 minute later the automation was triggered by the condition of the cover!!! <-is that normal, this happens everytime!!
But than 10 minutes later it was triggered again by the condition of the cover, but than the statushelper was set to shading and manual, but nobody has moved the cover! here is the trace for that, can you see what triggers?
Now the problem is the following: shading conditions are false now, but the cover is still in that position! I know manual changes wins over shading, but would it be possible, if the sun elevation/azimuth parameters are out of range that the cover will open!
Hi,
After updating from 2026.1.26 to 2026.5.31 I'm facing a weird situation:
In the night -> morning. Shutters are in venting as window is open and shutters should be closed by sun condition. Resident is present. Sun gets above thresholds, early opening time is reached, they stay in venting as resident is still present. However, after resident changes to false, they still stay in venting even if they should be open. Trace is here.
I did not find any change related to this in the changelog and also according to my understanding of a new statemachine, it should be in opened state. Am I understanding something wrong, or is the behaviour expected?
Hello, I would like to ask, if the following is possible:
I want only sun shading running on a specific window. And the initial shading is working. Then I can might close the cover completely for an hour, because baby sleeps. Then it wakes up, my wife opens the cover completely while still being in the shading azimute. And it never returns to shading even though I have a timeout of 5 minutes set for manual override.
I expected to go back to shading after 5 minutes, but it is not happening.
Fix: Shading never executed when pending-start (
Force Activation
Return to Target State After
Improvement: Clarified the description of "Independent Shading via Temperature Comparison". The text now states explicitly that this mode bypasses the sun position (azimuth and elevation) and brightness, that shading can therefore start even when the sun is not on the facade, and that the bypass is not limited to the morning but applies all day while the temperature stays above the threshold. Users who want shading to keep respecting the sun position should leave the option unchecked
Feature: New option for reset manual override "reset in position". This option will automatically clear the manual override state and restore automatic control once the cover reaches a specific target position (± configured tolerance) and remains there for the duration of the defined timeout. Use Case: Keep the blind in manual mode after lowering it by hand, and only let the automation take over again once the blind is fully reopened to 100%. Many thanks to