Cover Control Automation (CCA) - Intelligent Automation for Blinds, Awnings & Shutters | Calendar, Sun Shading, Force Functions

[Herr.Vorragend]

There's a built-in mechanism for exactly this — use the Force Close function, not a direct cover.close_cover.

The reason your approach doesn't work is that a direct cover.close_cover produces a position change that CCA reads as a manual intervention (man: 1), which suppresses the automation. CCA's Force functions are separate from manual override and were designed for exactly this kind of "drive somewhere now, then return to normal automatically" scenario.

Setup:

1. Create an input_boolean, e.g. input_boolean.ground_floor_away.
2. In each ground-floor cover's CCA automation, set that boolean as Force Immediate Closing via Entity (in the Force functions section).
3. Set Automation options → "Seamless control with automatic recovery" to enabled (auto_recover_after_force).

Behaviour:

• On departure → turn the boolean on. All covers close immediately. Internally CCA records this as a force-close (frc: cls), not a manual override. The correct background target (open / shading / closed, based on time + sun) keeps being tracked the whole time you're away.
• On return → turn the boolean off. CCA's force-disabled handler automatically repositions each cover to its current correct state at that moment — open, shading, ventilation, or closed, depending on the time of day, sun position and window contact. No manual helper reset needed.

So you never touch the helper yourself: Force Close + auto-recovery is the supported "away mode". You can wire the boolean to your presence detection (person/zone) so it's fully automatic.

One note: use an input_boolean (or any on/off entity) as the trigger — not the cover.close_cover service — since it's the force entity state that CCA watches.

[tco95ttocs]

short question to the cover-status-flex-table:

What does "ts.due" and "ts.arm" stand for?

[MartyBr (Martin)]

@Herr.Vorragend

Force Immediate Closing via Entity (in the Force functions section).

Hi, I'm currently incorporating your tip into my automations. I've created the Boolean value and set "Force Immediate Closing via Entity (in the Force functions section)."
However, I can't find the setting to enable "Seamless control with automatic recovery" (auto_recover_after_force) under Automation options.

Thanks
Martin

[lmmalouin]

Hi,
I have setup a simple sun elevation trigger, nothing else and it does not work. I can see it is triggered at the correct time (sunset, sunrise) but nothing happens. The configurator validator gives me no error but the trace analyzer gives me this:

Am I missing something?
Thanks!

[paschdan (Daniel)]

So I have the latest version, and have setup shading by azimuth and elevation. When a cover is opened, when it is within the shading range, the manual override kicks in. I have setup a manual reset after 5 minutes. After those 5 minutes the midnight reset branch 11 kicks in, and the cover stays open, instead of shading again.

If you want, I can add traces.

alias: Beschattung_kz
description: ""
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    blind: cover.kinderzimmer
    auto_options:
      - auto_shading_enabled
    close_position: 0
    sun_elevation_up: 5
    check_config: true
    shading_azimuth_end: 365
    individual_config:
      - allow_shading_multiple_times
      - prevent_shading_end_if_closed
      - prevent_opening_after_shading_end
    shading_azimuth_start: 176
    shading_waitingtime_start: 5
    shading_position: 16
    shading_waitingtime_end: 68
    shading_weather_conditions: []
    shading_elevation_min: -90
    shading_forecast_temp: -50
    ignore_after_manual_config:
      - reset_manual_detection
    shading_sun_brightness_end: 0
    drive_delay_random: 0
    sun_elevation_down: -90
    cover_status_helper: input_text.caa_kinderzimmer
    check_config_debuglevel: error
    ventilate_position: 17
    time_control: time_control_disabled
    sun_time_duration: 30
    drive_time: 27
    reset_override_config: reset_timeout
    reset_override_timeout: 5
    open_position: 100
    auto_down_force: input_boolean.testcca
    shading_start_max_duration: 3600
    shading_end_max_duration: 3600
    auto_recover_after_force: auto_recover_enabled
    shading_conditions_start_and:
      - cond_elevation
      - cond_azimuth
    shading_conditions_end_or:
      - cond_azimuth
      - cond_elevation
      - cond_forecast_weather

[holunder]

I think I still didn't get the whole manual override topic.
Therefore I'd like to ask a simple question:
If I've no option activated in ignore_after_manual_config does that whole manual override functionality does anything? Does then any other config in this area matter?

[phips2996]

@phips2996

Brightness Hysteresis – redundant when Start/End are separate values?

Hi @Herr.Vorragend

quick question about the shading brightness config:

We already have separate Start (e.g. 35000 lx) and End (e.g. 25000 lx) values, which by themselves create a 10000 lx dead band. Adding a Hysteresis on top just widens that band further.

For the temperature sensors the hysteresis clearly makes sense – they only have a single threshold. But for brightness with two thresholds, the hysteresis feels redundant.

Is there a use case I’m missing, or could this parameter be removed for the brightness case?

Thanks!

Can anyone help me out here? The Hysteresis for Brightness just doesn't make sense for me.

[Avalon (Daniel)]

@Herr.Vorragend could it be that there is a bug in CCA 2026.06.16 ?
I have the Option set that shading should not happen while Resident is present but today shading started on all covers while they were still in resident mode...
I saw in the table that shade is on and status is resident but they still moved to shading mode.

[Herr.Vorragend]

Yes, you're right — this is a confirmed bug, and it's now fixed (will be in the next release).

What happened: With "Allow sun protection when resident is still present" disabled, the shading intent was correctly stored without moving the cover when the conditions were met during resident presence — that's why you saw shade = on and status resident but no movement. However, the separate shading-tilt adjustment (which re-angles the slats as the sun rises) was missing the resident check. So when a tilt trigger fired, it tilted the slats into the shading position anyway — making the covers look like they entered shading mode despite the resident being present.

It only affected covers with slat/tilt control (venetian blinds), which is why it hit all of yours.

Fix: The shading-tilt step now respects the resident "allow shading" setting just like every other shading movement.

Thanks for the detailed report — shade on + status resident was exactly the clue that pinpointed it.

[Avalon (Daniel)]

@Herr.Vorragend thanks for the quick update!
I think it was already discussed here but could you add this option somewhere in the Future:

In the ventilation options section:

• Checkbox: End ventilation before sunrise when resident mode is on.
  (Takes Sunrise Sensor from Home Zone)

When this option is checked and the window is tilted so that the cover goes into ventilation mode and the resident mode is on, the ventilation is ended before sun rises even when the window is still tiled (for sleeping rooms and nightly ventilation without letting light in in the morning).

[Herr.Vorragend]

I'd rather be cautious with new enhancements right now. They often cause their own problems, and in many cases in recent months, it has been hard to fully understand the dependencies.

Could you please create an issue on GitHub to track this idea? That way, we can keep it from getting lost. We'll figure it out from there.

[Herr.Vorragend]

Hi Martin,

the setting you're looking for is not under Automation options — it lives in the same section where you already set the force-close entity: Force Features.

There it's the first option in that section, called:

Return to Target State After Force Disable

The description of that option contains exactly the "Seamless control with automatic recovery" wording you remember (auto_recover_after_force). To enable it, set it to:

Enable Automatic Return to Target State

So in short:

1. Open the Force Features section.
2. Set "Return to Target State After Force Disable" to Enable Automatic Return to Target State.
3. Right below it you'll find your "Force Immediate Closing via Entity" input — both belong together in that one section.

Best regards

[Herr.Vorragend]

Thanks for the details. This is expected behavior plus a config issue, not a bug in branch 11.

What's happening

1. The timeout reset doesn't re-drive the cover. "Reset after X minutes" only clears the manual flag (man: 0) and runs your optional reset action. It does not move the cover back into the shading position. So after 5 minutes the override is gone, but the cover stays where you left it (open).

2. No shading trigger re-fires. Shading-start triggers only fire on a FALSE→TRUE edge of the azimuth/elevation conditions. The sun is still inside the shading range, so the condition is already TRUE → no new edge → no restart. With your values (azimuth_end 365, elevation_min -90, forecast_temp -50) shading never ends on its own either, so there's no "end → restart" cycle. Nothing re-applies the 16% position.

3. Branch 11 runs at 23:55, not right after the 5 minutes. The midnight reset triggers on now() >= 23:55. Because shd is still 1, it clears it. It's just the next event that touches the helper after your manual open — not a consequence of the timeout reset.

Config note (important)

Your YAML carries option values that no longer exist in the current blueprint and are silently dropped:

• ignore_after_manual_config: reset_manual_detection → not a valid value. So ignore_shading_after_manual is not set, meaning the manual flag doesn't actually block shading at all.
• individual_config: allow_shading_multiple_times → no longer exists (now prevent_shading_multiple_times).

Please re-open the automation in the UI and re-select the options from the dropdowns — these come from an older version.

Bottom line: the timeout reset just hands control back; it doesn't actively restore shading. Without a fresh trigger edge the cover won't return to shading on its own. Happy to look at your traces to confirm.

[MartyBr (Martin)]

Hi @Herr.Vorragend,
Thanks a lot for the info. I’ve set it up that way, and it works perfectly.

Best regards

Martin

[Herr.Vorragend]

Hi, your trigger works fine. t_close_5 firing only means the sun crossed your closing threshold; it doesn't mean the cover will close. The "No Branch matched" in the trace means the closing branch's conditions weren't met.

Key concept: in CCA, sun elevation/brightness are not standalone closing triggers. They're conditions evaluated inside the time window.

Two things to check:

1. "Automatic Closing" must be enabled in the options. The #1 cause: people set sun thresholds but forget to enable the closing feature itself.
2. For pure sun control with no schedule, set the time control mode to "disabled". Otherwise the sun threshold only acts within the closing window (default 16:00–22:00). Which is also why a sunrise event never closes.

Tip: enable the logbook option to see trigger.id, effective_state and why no drive happened on each run.

So you're not missing anything on the trigger side. Just the closing feature toggle and/or the time-control setup.

[Herr.Vorragend]

ts.due and ts.arm in the CCA Helper JSON

Documented in the FAQ — Shading Pending Phase

ts.due — "due time"

The scheduled fire time of the armed pending trigger.

When shading is waiting (pnd: 'beg' or pnd: 'end'), this holds the Unix timestamp at which t_shading_start_execution (or t_shading_end_execution) is expected to fire. On every retry it is updated to now + waitingtime.

• ts.due == 0 when pnd == 'non'

ts.arm — "armed at"

The start timestamp of the current retry sequence — i.e. when the pending was first armed.

It is set once when the pending phase begins and preserved across all retries. It serves as the anchor for the shading_start_max_duration / shading_end_max_duration budget check: "how long have we been trying?"

• ts.arm == 0 when pnd == 'non'

---

Field	Changes on…	Resets to 0 when…
ts.due	Every retry (now + waitingtime)	Pending clears (pnd → 'non')
ts.arm	First arming only	Pending clears (pnd → 'non')

In short: ts.due = when is the next attempt? — ts.arm = when did we start trying?

[Herr.Vorragend]

No, this is not a bug — it's by design.

The manual override system is an opt-in feature. If no option is activated
in ignore_after_manual_config, the automation always takes full control:
manual moves are detected and tracked internally (man: 1), but they never
block any automation action.

You need to activate at least one option (e.g. Ignore closing after manual)
to make the override actually suppress automation triggers after a manual move.

Summary:

• No options active → automation always wins, manual override has no effect
• Options active → automation respects your manual intervention for the
  configured action types

[Herr.Vorragend]

You're here on 2026.06.08, and what you're seeing is issue #530, which was fixed in 2026.06.14.

What happens:
The shading conditions are already met before your 07:20 opening time (sunny morning), so a shading-start pending is armed (pnd:"beg" in your trace). At 07:20 the opening handler correctly defers to the shading execution instead of opening the cover normally.

But in 2026.06.08 the "Start Shading" step could only move the cover down into the shading position. Your cover is fully closed (0 %) while the shading position is 50 % — i.e. it sits below the shading position. So none of the drive branches matched:

• Consider lockout → window is closed
• Start Shading → position is below shading, no matching branch
• Save shading state for the future → needs effective_state == 'cls', but after opening time bas='opn'

→ Dead zone — the cover stayed closed. That's exactly why disabling the shading feature made it open normally.

Fix:
This is already resolved. The shading-start step now also raises a closed cover up to the shading position when the schedule wants it open. Please update to the latest version (2026.06.20) and it will work.

After the update the cover will move to your shading position (50 %) at opening time on such sunny mornings — not fully open. That's the intended behaviour when shading is active.

[Herr.Vorragend]

Hi Dominique,

That's actually expected behaviour, not a bug.

The ventilation / anti-locking feature is only a lower limit ("floor"). It
stops the cover from moving further down while the window is open/tilted —
but it does not override the target the automation calculates from the
schedule, brightness, sun or presence.

So when you close the window, that floor disappears and the cover goes to its
real target state. If it closes, the automation already wanted it closed at
that moment (base = closed) — typically because:

• the closing time has already passed (most common),
• a brightness- or sun-based closing condition is active, or
• shading is active.

The open window simply "masked" that the schedule already wanted the cover down.

What to check: your closing time, any brightness/sun closing condition, and
the bas value in the helper (if it's cls, the schedule wants it closed).
Enabling the logbook shows exactly which branch fires when you close the window.

In short: ventilation only blocks closing while the window is open — once you
close it, the cover follows the schedule again. Nothing is broken.

[Herr.Vorragend]

Hi René,

happy to help — both are doable. One important point first: CCA does not control evening closing via a minute offset like "Sunset + 25 min", but via the sun elevation (degrees). It feels unusual at first, but it's more flexible.

1) Closing in the evening "at sunset (+x)"

There is intentionally no "Sunset + 25 min" field in CCA. Instead:

1. Automation Options → enable
   • Evening Closing (auto_down_enabled)
   • Sun Elevation Control (auto_sun_enabled)
   • Time Control (keep it on — the time fields just set the boundaries)
2. Sun Elevation Settings:
   • Sun Elevation Mode = Fixed
   • Sun Elevation Value For Closing The Cover = the threshold in degrees:
     • 0° = exactly sunset
     • negative value = later (sun lower below the horizon). "Sunset + ~25 min" roughly corresponds to −2° to −3°, depending on season/latitude.
3. Time Control (section Time Control): Time For Drive Down – Early is the earliest possible closing time, … – Late is the guaranteed fallback (e.g. if in summer the elevation never drops low enough). So the sun trigger only fires within this window.

In short: you map your "+25" wish via the elevation degrees, not via minutes.

2) Partially closing several roller shutters at a specific time / azimuth

Yes, this is possible — it's exactly the Sun Protection / Shading feature (auto_shading_enabled).

• It moves the cover to a defined partial position (Shading Position, e.g. 50 %) as soon as the configured conditions are met.
• As a trigger you can use, among others, the Sun Azimuth (within configured range) — i.e. "when the sun enters a certain azimuth range, move to the partial position". That matches your "at a certain azimuth".
• A pure clock-time trigger ("at 14:00 to 50 %") is not directly provided — but since the azimuth correlates with the time of day, the azimuth range represents exactly that "point in time". Optionally combinable with elevation, brightness and temperature.

How to: enable Shading → in the shading-start conditions select Azimuth (and optionally Elevation) → set the azimuth range + desired Shading Position + waiting time. Since this is configured per blueprint automation, you can create a separate instance per shutter (or per group with the same orientation) with a matching azimuth range.

Helpful docs: the Time Control Guide and the Dynamic Sun Elevation Guide.