CCA doesn’t have a dedicated “at time X drive to Y %” input — that’s why you couldn’t
find the setting. Positions in CCA are always tied to states (open / close / shading /
ventilation / lockout). So there are two ways to get your intermediate position, depending
on what you actually want:
1. If the intermediate position should simply be the evening drive:
That’s just the Close Position — it can be any value (you’re already using close_position: 45), and the timing can be fixed or sun-based. What CCA does not
support is a two-stage evening close (first 70 %, fully closed later) — there is exactly
one up and one down movement per day.
2. If you want an additional, time-controlled intermediate position:
The intended vehicle for this in CCA is the sun shading, because only its start/end
conditions are freely configurable (fixed time via a condition: time in Additional Condition When Activating Sun Shading, or sun-based via azimuth/elevation) —
and the shading position is your intermediate position.
Since your shading is already used for heat protection at 30 %, you can still do it
without an extra automation — fittingly, your force-pause helper is already called rollladen_west_vorbeschattung, and exactly that construct can be replaced with
CCA’s own tools:
Alternate Sun Shading Position (shading_position_alt: 70 + shading_position_alt_entity): while the switch entity (e.g. a schedule helper or
your existing input_boolean) is on, the shading drives to 70 % instead of 30 % —
the cover is re-driven even while shading is already active. This does not count as a
second shading, so “only shade once per day” keeps working.
If the 70 % drive should happen at a fixed time independent of the shading
conditions: put a schedule helper on Force Activation Sun Shading via Entity
(auto_shading_start_force) — when it turns on, shading is activated without any
further checks. If the same helper is also set as shading_position_alt_entity,
the cover lands at 70 %. With auto_recover_after_force: auto_recover_enabled the
cover automatically returns to its target state when the schedule ends. This fully
replaces your current force-pause + extra-automation combination.
Alternatively, for condition logic instead of force: point the Custom Condition
Sensor (shading_custom_sensor) at a schedule helper or template sensor and add cond_custom to the shading START lists.
If, however, you really want a completely independent second movement (e.g. 100 % in
the morning, 70 % in the afternoon, 45 % in the evening — all independent of shading),
then the small extra automation honestly remains the right tool. In that case it should
keep setting the force-pause helper, as it does now, so CCA doesn’t interfere.
Glad to hear everything else is working well for you!
thanks for the detailed report — the two screenshots together actually explain the whole evening.
The restart behavior (shading at 19:47, opening again at 19:53) is a known issue — fixed in CCA 2026.08.25.
Here is what happened, step by step:
At the time of the HA restart, CCA’s status helper still had sun shading marked as active (more on that below).
The restart catch-up found that stored shading state and moved the cover to the shading position — that is your 19:47 entry “catching up after a restart or an outage, target: sun shading position”.
At the same time, the recovery correctly noticed that the shading end conditions were already met (azimuth 283.7° is far outside your 53–110° range) and armed the shading end.
One end waiting time later (default: 300 s — exactly your 5 minutes), the shading end executed: “sun shading is over, opening again” at 19:53.
Since CCA 2026.08.25, the restart catch-up no longer drives the cover into a shading whose end it just armed — it leaves the cover where it is and lets the shading end perform the one real movement (which is then usually no movement at all). Please update to 2026.08.25.
Side note: if you generally don’t want any catch-up movement after a HA restart, set the recovery option to outage instead of always — restarts then stay movement-free, and only real sensor outages are caught up.
The afternoon tilt adjustments (17:47 / 18:43, “slat angle re-checked”) tell us that the internal shading state was still active all afternoon — the slat tracking only runs while shading is marked active, so the tracking itself was consistent. The real question is why shading hadn’t ended around late morning, when the sun left your 53–110° azimuth range. Two possibilities:
Do you have “Independent Shading via Temperature Comparison” enabled (Sun Shading – Configuration)? On hot days that path starts/keeps shading independent of azimuth and elevation by design — and your dashboard shows both temperature conditions as met. The Deep-Dive card only shows the standard AND/OR conditions, not the independent path.
Otherwise, the shading end trigger edge may have been swallowed earlier that day (e.g. by an earlier restart or a sensor/cover outage right around the moment the sun left the azimuth range). The trigger only fires on the transition itself — if that moment is lost, the shading stays active until something re-evaluates it, which is exactly what the evening restart recovery then did.
To pin it down, it would help if you could post:
your CCA version,
your selections under “ Sun Shading - Configuration”,
a trace of one of the afternoon runs — easiest via the CCA Trace Analyzer: open the automation’s trace in HA, download the JSON, upload it there and post the result.
That analyzer message is the dispatcher’s fall-through: the run started, but no branch claimed the trigger. “All shading conditions met” isn’t enough on its own — the shading branch also needs the right trigger plus a few hidden guards. The usual suspects:
Did you press “Run actions” manually? A manual run has no trigger ID, so no branch can ever match — this produces exactly that message. CCA only acts on its own triggers.
Shading only arms when a start condition newly becomes true (false → true transition). If the conditions were already met before you saved/reloaded the automation, no trigger fires; any other event (window contact, presence, …) then falls through with this message. The trigger.id in the trace tells us which case you hit.
“Prevent shading multiple times a day” enabled and shading already ran today.
The cover is already within the position tolerance of the shading position — with tilt disabled, that skips the branch.
Stale helper state, e.g. shd:1 or a stuck pnd from yesterday (midnight reset missed because HA was down at 23:55). Please post the content of your input_text helper (Developer Tools → States).
Important: each shutter/automation needs its own helper. If your covers share one input_text, they corrupt each other’s state — please double-check this first, especially since several covers are affected.
To dig deeper, please share:
a fresh trace JSON (bump “Number of stored traces” in the blueprint so it doesn’t get evicted before you can download it),
the helper content (Developer Tools → States → your input_text),
the blueprint version you’re on,
and ideally enable the logbook option: the “No operational branch matched” logbook entry dumps trigger ID, effective state, position and all sensor states — exactly what we need.
good news: your scenario is supported — but not in the version you’re running (2026.07.30).
What happened: In your version, a manual move immediately cancelled the shading state (shd:0). That’s why the shading-end trigger at 11:59 was blocked at condition/6 — this condition only lets the “shading end” flow run while a shading is actually active (shd:1). There was simply no shading left to end. So CCA doesn’t expect man:0andshd:1 — the problem is that shd was already cleared hours earlier by the manual move.
The fix: Update CCA to the latest version. The manual-override handling was reworked: a manual move now only sets man:1 and pauses the automation — the shading state stays active. With your existing config (ignore shading after manual + 5 min reset timeout) your sequence then works out of the box:
Shading lowers the cover
You move it manually → position holds
After 5 min the override resets (man:0, no movement)
When shading ends, the cover raises — regardless of its position
One note: leave the new option “auto recover after manual reset” disabled — otherwise the reset would drive the cover back to the shading position after 5 minutes.
Yes, the design did change — and the behavior you observed has since been made opt-in (default off) again.
What changed (2026.08.02, PR #657 / #655): CCA now keeps tracking its intended
state (schedule, shading, window, presence) in the background while a manual
override is active, and when the override ended — including the fixed-time reset —
it immediately drove the cover to the target valid at that moment. That’s the
“restore” you saw. For shading-only instances the cascade’s resting state is “open”
by design (#553), which is why your covers opened after the 0:01 reset — reported
as #668/#677.
The correction (PR #669, releases 2026.08.22/23): New option “Return to
Target State After Manual Override Reset” (auto_recover_after_manual_reset), default: disabled — a reset now only clears the override again; the cover stays
put until the next regular automatic event, like before. Even when enabled, a reset
never opens a cover with no opening automation configured. 2026.08.23 also fixed a
leftover path where the fixed-time reset could still drive right after the nightly
23:55 reset (your exact midnight scenario), plus the stale base state of
opening-only/closing-only setups (#673).
Bottom line: the background state tracking stays (it fixes real bugs, e.g.
stale shading replays), but driving on reset is opt-in. Update to the current
release and leave the option disabled — then the reset just hands back control
without moving anything.
Most of what you’re asking for is already there — CCA stores its complete state in the input_text helper as JSON, and you can render it on any dashboard:
There are two ready-made examples in the repo: examples/cover-status-card-tile.yaml (a tile card with a status line like “ Shading Active”, “ Manual Hold — active since 14:32”, “ Shading pending — starts at 15:10”) and examples/cover-status-flex-table.yaml (a table showing all internal fields for several covers at once — great for checking whether you set things up right).
The helper fields answer your questions directly: shd = shading in/out, pnd + ts.due = a pending shading start/end and when it will fire, man + ts.man = manual override and when it happened, ts.opn/ts.cls = last open/close by the automation.
For a real log of “what happened and why”, enable the two options in the Logging section: “ Enable Logbook entries” writes one full entry per run on the automation, and “ Log decisions on the cover” writes a short plain-English line on the cover itself (e.g. “moved to 40% · …”), which stays visible in the cover’s history and device page. So if a movement came from CCA, you’ll see its line there; if there’s no line, it was a manual move — which CCA detects and marks as man: 1 (shown as “Manual Hold” in the status card).
A built-in “next drive up/down at HH:MM” entity doesn’t exist, because the exact minute isn’t predictable: within your early/late window, brightness or sun elevation decides the moment. But since you configure the times, a small template sensor can show today’s window, e.g.:
For shading, the exact planned time is available: when pnd is beg/end, ts.due holds the scheduled fire time (the example tile card already displays it).
2) School-holiday times for the kids’ rooms only
That works out of the box. CCA has separate workday / non-workday times plus a “ Sensor For Workday Today” input — and that input accepts anybinary_sensor (on = normal day, off = free day). So combine your Workday sensor with your school-free integration in a template sensor:
template:
- binary_sensor:
- name: "School day today"
state: >
{{ is_state('binary_sensor.workday_today', 'on')
and is_state('binary_sensor.school_free_today', 'off') }}
- name: "School day tomorrow"
state: >
{{ is_state('binary_sensor.workday_tomorrow', 'on')
and is_state('binary_sensor.school_free_tomorrow', 'off') }}
(Adjust the entity IDs to whatever your school-free integration provides.) Then, only in the kids’ rooms automations, set School day today as the workday sensor — on school-free days those covers use the non-workday times, while all other rooms keep the normal Workday sensor. Since every cover has its own automation instance, this is per-room by design.
Tip: also set “ Sensor For Workday Tomorrow” to School day tomorrow — it exists exactly for the school scenario: the covers close earlier on Sunday evening when there’s school the next morning.
I thank you very much for your help. I have the to visuals added to my dashboard, thats very nice. Thx. The rest comes to.
For now i have another problem. I set up the BP, the Blind goes down and up to the late times of non workdays. The blind should drive when sun goes down and up.
Hi, the latest version of Spook checker found this issue on automations created from this blueprint:
This automation uses the following conditions, which cannot be provided by any integration available to Home Assistant:
* \`{{
(is_up_enabled or is_down_enabled) and
not is_time_field_enabled and
not is_calendar_enabled and
not (is_brightness_enabled and default_brightness_sensor != \[\]) and
not (is_sun_elevation_enabled and default_sun_sensor != \[\]) and
not (resident_sensor != \[\] and
('resident_opening_enabled' in resident_config or
'resident_closing_enabled' in resident_config))
}}\`
I have a question:
I have an automation that raises the roller shutters when my phone alarm goes off. What is the best approach—should the automation open the shutters directly, or is it better for the automation to set a helper to “True” and then have the shutters opened via the “force” function in the blueprint?
Hi,
First of all thanks for all your work on this automation, I have been using it for the past 2 years and it has been awesome so far
I have a question that I think might have ben answered but I couldn’t find the answer myself :
When a cover is already fully closed, is it expected for shading to start ?
I experienced it this morning when the covers in the bedroom were still closed after the shading start time, the cover moved to the shading position instead of staying closed.
I was under the impression there was an option to control this (ie “Prevent shading if already closed”) but cannot find it, maybe I dreamed
Close Position — it can be any value (you’re already using
Alternate Sun Shading Position (
Custom Condition
Shading Active”, “
Manual Hold — active since 14:32”, “
Shading pending — starts at 15:10”) and 
Enable Logbook entries” writes one full entry per run on the automation, and “
Log decisions on the cover” writes a short plain-English line on the cover itself (e.g. “moved to 40% · …”), which stays visible in the cover’s history and device page. So if a movement came from CCA, you’ll see its line there; if there’s no line, it was a manual move — which CCA detects and marks as 
Sensor For Workday Today” input — and that input accepts any 
