Hi. With the newest Versions I have the Problem that If
Resident Changes from on to Off and Window ist tilted (and Ventilation is on) the shutter rests in Ventilation Position.
Normally it should open completely because no Ventilation is needed at this Point.
I will Provide a trace tomorrow.
Timeline
shd:1, man:0t_manual_position fired → suppressed (settle window)t_manual_position fired → set man:1Yes. Driving the cover makes it report its position, which fires the trigger. It's suppressed for drive_time + 60s after each drive (motor settling). Runs, does nothing.
man:1, but nobody moved it"The cover reported a 1 % drift (58 → 59) ~11 min after the drive — outside the settle window. Manual detection treated any change as manual (only checked from != to, not the size), so even a 1 % jitter that's still within the shading tolerance set man:1. Hardware drift, not a person — but CCA couldn't tell them apart.
With ignore_shading_after_manual on, man:1 then blocked shading-end → cover stuck until the reset timeout.
A dead-band: a position change only counts as manual when it exceeds position_tolerance (all position sources):
- "{{ ((trigger.to_state.attributes.current_position | float(0)) - (trigger.from_state.attributes.current_position | float(0))) | abs > position_tolerance }}"
58 → 59 at tolerance 1 → not manual; real moves (e.g. 58 → 70) still detectedposition_tolerance = 0 restores the old behaviourResult: no more false man:1, so shading ends normally when elevation/azimuth leave the range. Note: an already-set man:1 clears only at the reset timeout / next real drive; raise position_tolerance if your cover drifts more than 1 %.
Root cause: This is a priority-cascade bug in the resident-leaving handler.
When the resident leaves (on → off) with the window tilted and the
schedule set to "open" (bas = opn), ventilation should only be a floor —
the cover must open fully, because with the resident gone no ventilation
is needed (effective_state = opn, since BASE=OPN ranks above VENT).
The branch "Resident leaving: target VENTILATION (window tilted)" only checked
the tilted sensor and drove to the 50% ventilation position regardless of the
effective target, so the cover got stuck at ventilation instead of opening.
Fix: The branch now also requires effective_state == 'vnt'. When the base
state is open it is skipped and the cover opens fully; at night (bas = cls)
ventilation stays the correct floor. This matches the BASE=OPN-before-VENT
behaviour already used by the contact handler.
Fixed in CCA 2026.06.07.
Note: for the cover to actually open on leaving, the "open when resident leaves"
option (resident_opening_enabled) must be enabled.
Your understanding is correct — this was a bug, not expected behavior.
When the resident leaves while a window is tilted and the schedule is in
its open window (bas=opn, no shading/privacy), the cover should open
fully, not stop at the ventilation position. Since 2026.05.24, BASE=OPN
beats VENT in the priority cascade — ventilation is only a floor that applies
when the cover would otherwise close/shade.
The resident handler's tilted-ventilation branches checked only the tilted
sensor and drove to the ventilation position, ignoring effective_state
(which already returned opn in your trace). The contact handler was fixed
for this in #460, but the resident handler was missed.
Both branches — "Resident leaving: target VENTILATION (window tilted)" and
"Resident arriving: window tilted → hold ventilation position" — now also
require effective_state == 'vnt'. So:
bas=opn → branch skipped → cover opens fully 
bas=cls (night) → ventilation stays the correct floor For the cover to actually open when you leave, the option
"Resident – enable opening" (resident_opening_enabled) must be set —
it's the counterpart to privacy-closing. Without it the cover no longer drops
to ventilation, but it won't open either; it just holds position.
Released in CCA 2026.06.07.
@Herr.Vorragend thank you for the many updates in the last weeks, its really becoming perfect now!
One thing I noticed, from time to time I see that shading is triggered and my two blinds in the living room next to each other are going into shading mode but a few seconds later one of them opens again and then never goes into actual shading position while the helper is showing that shading is active (like it would have actually closed, exactly like the one next to it that actually is in shading position)... no clue what's happening there and unfortunately I don't have a trace for it from today.
Maybe you still know what could trigger this...
where can i set what to do after shading ends?
Thanks
Is there a way to configure lockout protection without ventilation like years before 
?
I want prevent the shutter close, but immediately close when time is after down late and window sensor switches from on to off.
I could achieve it with using conditions and creating template sensor in HA but eventually there is a way to set it up in the blueprint.
Yes — that's exactly the built-in lockout protection, no template sensor or conditions needed. It's independent of the ventilation position.
Setup:
Ventilation Mode feature (in the feature selection at the top).
Contact Sensor For Open Window (Full Ventilation) → your window sensor Contact Sensor For Tilted Window (Partial Ventilation) → leave emptyWhat happens:
The partial ventilation position only exists when you also assign the tilted contact. Without it you get pure lockout — just like the older versions. 
Note: the "Full Ventilation" contact drives the cover to the open position (100%) while the window is open. If you instead want the cover to just stay put (not move to 100%), that's a different requirement — let me know.
That‘s exactly what i want to achieve. No moving when window will be opened or already open. But close cover immediately if time is after late down when closing the window.
@Herr.Vorragend is it possible, that the cover continues to shade after manual resets?
Very good question! I wondered about that also.
And as an addition: with the old version/event handling I always had the problem that if the shading condition were already met before the opening time (ie. opening time is 8 am, on the east side of the house the sun comes up now at 5 am and till 8 all shading conditions are already met), it would just open anyway and ignore the shading, that was supposed to happen.
With the newer versions now it got somewhat better ... it seems to recognize now when the open time comes that it should shade/the shading conditions are given. But it seems to me that it now says "well ... the cover position is already lower than shading position (it is of course as it is still closed/0%) so I don't need to shade" ... and thus it stays completely dark the whole day until manual intervention. Anyone else has seen this behaviour?
Hello regarding the Change log should be the issues fixed when the cover is still closed but the shading is already starting. But i have still the problem. My cover should open early at 7:20 and brightness. But the cover hasn't at 07:20 but brightness was already true. My Version : 2026.06.08.
And the shading start was already in pending because of an sunny morning.
Is there anything what i can provide to find the reason?
EDIT: Yesterday i deactivated sun shading feature and the cover has open today at 07:20 as expected. So in my Environment is still the problem when shading is already "active" but the cover is still closed.
Hi,
I’m using CCA for my blinds and noticed that when opening to 100% in the morning (time trigger), the tilt command causes the position to reset to 99% after the tilt waiting time, which I set to 75 seconds. Since the slats are already at their mechanical end stop at 100%, would it make sense to ignore tilt commands when the target position is 100% or 0%? This would avoid conflicts between position and tilt.
Thanks,
Joachim
I'm still fairly new to CCA and have a question about opening in the morning and closing in the evening—that part is fine, though I haven't been able to find where exactly I need to enter the settings if, for example, I want to close in the evening at “Sunset +25 Offset.”
Another thing I’d like to know—since I have several roller shutters that I’d like to partially close at a specific time, for example, when a certain azimuth or time is reached—is whether this is possible with CCA, and if so, how would I go about doing it?
Hello,
I have a question regarding the anti-locking feature.
I activated the ventilation to prevent it from closing when the window is open, and it works correctly.
However, I don't understand why, if I close the window during the day, for example, the cover starts to close. Could you help me resolve this issue? It happens every time I close the window; the cover closes.
Thank you in advance.
Maybe a solution could be an adjustable threshold, like ignoring tilt if the opening is above 95%. That way, the mechanical end position, where tilt would just try to re-open a bit, could do its job and be the final position.
I’m using the latest Shelly 2PM Gen4 with the latest firmware.
Hello, the option "shade cover only once per day" is broken since a couple of releases. Despite being activated, my covers are shading and opening multiple times a day.
Fix: The "shade the cover only once per day" option was effectively inactive for everyone who does not manually move their covers by hand. The daily guard allowed shading again whenever no manual change had happened since the last shading — and since that is always the case when you never touch the cover by hand, the guard never blocked a second shading. Covers therefore re-entered the shading position again and again throughout the day (and the repeated shading-end movements made the cover look like it was also opening multiple times). The guard is now purely calendar-based: once the cover has shaded today, it will not shade again until the next day Fix: The blueprint failed to import (YAML parsing error "expected <block end>, but found ?" at the 
trace: key) since the "Number of stored traces" setting was added. The trace: top-level key was indented by one space, which made it part of the preceding actions: block instead of a separate automation-level key. It is now correctly placed at the top level, so importing via the official button or the standard/raw URL works again (#532) Fix: When the shading conditions were already met before the opening time, the cover stayed closed all morning instead of moving into the shading position. At the opening time the handler correctly deferred to the shading execution, but the execution then refused to move the cover: its position check only drove the cover down to the shading position, while a cover that was still fully closed sits below the shading position (e.g. shading position 3 %, closed 0 %). As a result nothing happened — no movement, the shading state was never recorded, and the cover stayed stuck closed (and the slats never tilted into the shading angle). The shading-start branch now also raises a closed cover up to the shading position when the schedule wants it open (#530)
Feature: The "Reset manual override" setting now accepts multiple reset mechanisms at the same time. Previously the four options (disabled, at fixed time, after timeout, in position) were mutually exclusive; you can now combine e.g. Reset in position with Reset after a timeout as a safety net for when you forget to drive the cover back to the reset position. The first triggered reset wins. Existing single-value configurations continue to work unchanged. To disable all timed resets, leave the field empty (#522) Feature: The "Reset in position" mechanism now has its own "Dwell time at reset position (minutes)" input (default: 5 minutes), independent from "Number of minutes until reset manual override". This makes combining Reset in position with Reset after a timeout sensible — each reset can be tuned independently Fix: When a shading-start pending was armed before the opening time and the shading conditions were still met when the opening time fired, the cover opened normally instead of staying in shading — but only for setups using calendar-controlled opening times (or any opening trigger other than the early time trigger). The opening handler's "Opening skipped: Shading start pending" branch now correctly evaluates whether shading is still warranted, but on a calendar opening the weather forecast was never loaded, so the forecast-based conditions defaulted to false, "still warranted" evaluated to false, and the cover opened. The forecast is now loaded for every opening-related trigger (early/late time, brightness, sun elevation, calendar start), so the "defer to shading execution while still warranted" logic works regardless of which trigger fires the opening (#514)
Improvement: When a shading-start countdown was armed before the configured opening time (e.g. the shading conditions were already met at dawn), the maximum retry duration was counted from that early arming moment instead of from when the shading time window actually opens. As a result a large part of the configured "maximum duration for shading start retry loop" was consumed while merely waiting for the window to open, and the retry loop could abort with "Shading Start aborted: Timeout or invalid" shortly after the window opened — even though plenty of retry time was supposedly configured. The retry budget is now anchored to the start of the shading time window when arming early, so the configured duration applies within the window as intended (#524) Fix: When a resident left (presence on → off) or arrived while a window was tilted, the cover stayed in the ventilation position instead of opening fully. With the schedule set to "open" (bas=opn) and no shading/privacy active, ventilation is only a floor — the cover should open completely because no ventilation is needed at that point. The "Resident leaving: target VENTILATION (window tilted)" and "Resident arriving: window tilted → hold ventilation position" branches only checked the tilted sensor and drove to the ventilation position regardless of the effective target. They now also require effective_state == 'vnt', so when the base state is open the branch is skipped and the cover opens fully; at night (bas=cls) ventilation remains the correct floor. This matches the priority cascade (BASE=OPN before VENT) already used by the contact handler (#460, #513) Fix: When a cover was already open and the latest opening time fired, the cover was redundantly re-driven and its recorded opening time was overwritten with the late time (#495). This had been fixed before but was accidentally reverted by a later change; it is now fixed again and covered by a regression test so it cannot silently come back Fix: Briefly tilting a window during a shading start/end countdown could cancel the pending shading so it never executed. The ventilation handler for a tilted window reset the internal pending state; it now leaves the shading countdown untouched (same fix as for briefly opening/closing a window) Fix: Manual override (man:1) was triggered by tiny hardware position drift. Some covers report their position with ±1 % jitter; if such a drift happened after the drive-settle window (e.g. the cover slipped from 58 % to 59 % a few minutes after shading), the manual-position detection treated it as a manual intervention and locked in the manual override. With ignore_shading_after_manual active, this then blocked the shading from ending — the cover stayed in the shading position even after the sun left the facade. The detection now applies a dead-band: a reported position change only counts as manual when it exceeds the configured position tolerance. Drift within the tolerance is ignored (set the tolerance to 0 to restore the previous behaviour of reacting to every change) Fix: When a shading-start pending was armed before the opening time (brightness briefly exceeded the threshold) and the conditions then fell back below the threshold before the opening time, the cover stayed closed all morning. At the opening time the handler logged "Opening skipped: Shading start pending" and deferred to the shading execution trigger — but that trigger only ever drives into the shading position or retries/aborts, it never opens the cover. The result was a blind stuck closed despite the opening time having passed. The opening handler now defers to the shading execution only while shading is still warranted (start conditions still met, or independent-temperature mode active); when the pending is stale it is cleared and the cover opens normally (#514) Improvement: The reset timer of the "reset in position" option now uses the configured minutes directly, so the Home Assistant editor displays it correctly. Note: the "Error in describing condition" messages reported in #512 are a cosmetic Home Assistant frontend issue and do not affect how the automation runs 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) 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)This should be fixed now in the latest update.
Hi,
I'm using CCA for several covers on my ground floor and I have a use case I can't figure out how to handle cleanly.
My use case:
The problem:
When I close the covers on departure (via a direct cover.close_cover action), CCA detects this as a manual action and updates the helper accordingly (bas: cls, man: 1). So when I return, CCA no longer knows that the cover should actually be open or in shading position — it just keeps it closed.
What I'm looking for:
Is there a built-in CCA mechanism to handle this "away mode" scenario? I want CCA to "remember" what the correct position should be while I'm away, and automatically restore it when I get back home — without me having to manually reset the helper state.
I searched online before posting but couldn't find any discussion about this specific use case — apologies if it has already been covered somewhere in this thread.
Thanks!