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

Blueprints Exchange
, ,
2797

thats why i asked before if i should update it :slight_smile:

how should i update ? i have to take the new version and manual give all parameter for all shutter? or can we automate that?

2798
1 Like
2799

To be honest, I’m waiting for someone who’s already programmed the cover control as an integration. It’s getting a bit ridiculous, really, just how much is crammed into that blueprint, and I’m becoming less and less on board with it.
That’s also one of the reasons why I don’t implement every feature straight away.

The blueprint has become too powerful. Far too complex. And you’ve got more flexibility in a proper Python module.

2800

There is this: Smart Cover Automation - new custom integration.

I haven't found the time to give it a proper test though.

1 Like
2801

@Herr.Vorragend You've accomplished a lot with CCA and I salute you for it from the depth of my heart. It's remarkable what can be achieved with a blueprint. However, when I looked at my own home and how I wanted to keep it cool during the hot days (my initial motivation for looking into cover automation) I found that I preferred a solution that is - from a software engineering perspective - more manageable (aka, easier to maintain). The lack of manageability is what turned me off CCA. At the same time, the lack of (apparent) quality and stability turned me off Adaptive Cover, the one existing integration many seemed to be using.

So I started my own integration, which has grown and matured a lot in the short time of its existence (less than a year): https://ha-smart-cover-automation.helgeklein.com/

I'm very open to constructive feedback. I have implemented nearly all feature requests and fixed all bugs that have been reported. If you're interested, please try out the integration and report anything and everything you find via GitHub Issues or the discussions area of the repo.

1 Like
2802

Oh, wow. I hadn’t heard of that before.
But I do know that another developer is currently working on a solution as well.

I think it’s great when there are several alternatives. Looks good, Helge.

2803

I'd forgotten about Adaptive Cover. There is a fork too, Adaptive Cover Pro.

1 Like
2804

Thanks so much for the comprehensive information, this is great. For now I think you're right that using the dynamic mode with an offset (trying out -4° first) is the place to start and that will likely achieve what I want here.

It's also interesting that you mention the weather-dependent options available when using a lux sensor, it's likely that I wouldn't use it in this way but at some point might play around with it as a condition for Sun Shading (preventing closing the cover when it's not very sunny outside). With the current weather in London, this is not a worry :sweat_smile:

2805

Hi, @Herr.Vorragend

I spoke too soon ... yesterday evening the cover closed again - even though the window was open/tilted

  • window closed, cover closed automaticaly at earliest closing time 22:00 (expected)
  • opened the window manually, cover moved to ventilation position at ~22:12 (expected)
  • windows still open, at about 22:38 the cover closed completely (unexpected!!)
  • at 22:43 I opened the cover manaully to 60% Position and it kept open the whole night

I would like to provide the traces .... but how?

EDIT: the trace analyzer pointed out: Trigger / t_manual_position / Cover position changed manually / cover.knx_interface_shutter_kueche
I will do some investigation first what may happen on the knx bus .... because there was no manual change ...

Thanks
Andreas

2806

Thank you very much for the detailed reply.

To match my requirements I now removed the Force-Shade Option from my CCA automation and instead created an Activate_Force_Shade and a matching Deactivate... automation that sets CCA into Force_Pause and activates a scene that drives the cover into shading position.

Thx again for your great blueprint!

2807

just a quick add-on question.
would it also work, if i just set
shading_start_max_duration = 43200 (=12h)

2808

All Clear - there was an unapplied change in a GA :frowning:
I will continue to monitor …

Thanks
Andreas

2809

Thanks a million for a) the in-depth explanation and b) fixing the issue. :folded_hands::folded_hands:

And no, I don’t prefer the cover to stay fully open while the window is tilten and shading is needed.
The blueprint does exactly what I was after. (of course, after applying the new version)

Cheers :smiley:

1 Like
2810

Hi, I have the same problem. Is there any workaround?

2811

Short answer: no, unfortunately — for two reasons.

1. You can’t actually set that value. The input is capped at 14400 s (4 h) (number selector with max: 14400). The UI slider stops there, and a hand-edited 43200 in the automation YAML fails selector validation when the automation is (re)loaded. So the realistic maximum is 4 hours.

2. Even conceptually, it’s only a partial substitute. Your idea does point in the right direction: as long as the pending is alive, the execution re-checks all conditions — including the blocking gate — every shading_waitingtime_start seconds (default 300 s). If the gate clears within the budget, the next retry tick starts the shading normally and shd: 1 gets written. So a bigger budget really does extend the window in which a late-clearing gate is still caught.

But there are three catches:

  • The background tracking still never gets fed. While the gate is blocking, the helper holds shd: 0, pnd: 'beg' — force recovery and the resident handler only look at shd == 1, they never consider an armed pending. The retry loop only compensates indirectly: the next tick (≤ 300 s after the gate clears) catches up — provided the shading start conditions (sun azimuth/elevation, brightness, temperature) are still met at that moment. If the gate only clears after the sun has already left the configured azimuth range, nothing happens. So “12 h budget = full-day coverage” doesn’t hold.
  • You never buy more than “until the evening” anyway. The budget only counts inside the shading time window, and the closing trigger always discards an armed start pending (documented design decision). The midnight reset cleans up at the latest.
  • Side effects: one automation run every 300 s for hours (trace/logbook noise), and while pnd: 'beg' is armed, no new start triggers are armed and the opening handler behaves differently (defer logic).

Bottom line: with the allowed maximum of 4 h it’s a usable workaround if your gate typically clears within a few hours after shading conditions begin. But it’s not equivalent to the real solution: it only keeps the active retry alive longer instead of persisting the shading intent as state — and that stored shd: 1 is exactly what force recovery and the resident handler depend on.

1 Like
2812

Hi, thanks for the kind words and the detailed report!

TL;DR: The 27 ms gap between the two telegrams is not the actual problem — and suppressing the second telegram based on that gap would be the wrong fix. What matters is where the status telegrams land relative to CCA’s existing “settle window” for manual detection. There are already two knobs that should solve this for you: drive_time and the Tilt Wait Mode.

How manual detection works in CCA

The manual detection has three layers of defense:

  1. Trigger stability: t_manual_position / t_manual_tilt carry for: 60s — they only fire after the attribute has been stable for 60 seconds.
  2. Settle window: a manual change is only accepted when now > <last CCA action> + drive_time + 60. The timestamp is written after every CCA drive, so everything that happens within drive_time + 60 seconds of CCA’s own movement is treated as an echo of that movement, not as manual.
  3. Dead-bands: position_tolerance and tilt_position_tolerance filter out small jitter.

Two telegrams arriving 27 ms apart are practically always on the same side of that window. The reason only the second (tilt) one bites is different: the position change gets absorbed (the HA KNX integration simulates the position during travel via travelling_time, so the position status telegram at the end of travel only confirms a value HA already shows → delta ≈ 0), while the tilt value only jumps when the status telegram arrives — typical for KNX venetians: CCA commands e.g. tilt 50, the actuator reports the real slat angle (0 % in your screenshot) after the travel ends. That delta is larger than any sensible tolerance, so t_manual_tilt fires — if the end of travel falls outside the settle window.

What to try (no blueprint change needed)

  1. Increase drive_time (:timer_clock: Cover Drive Time). It must cover the full time from CCA’s command to the last status telegram (travel time + slat run + margin), not just the raw travel time. This input exists exactly for this case.
  2. Set the Tilt Wait Mode (:counterclockwise_arrows_button:) to “wait until movement stops” (wait_idle). CCA then waits for the cover to finish travelling before sending the tilt command, and the internal timestamp is written after that — so your status telegrams land safely inside the settle window, almost independent of drive_time.
  3. Check tilt_position_tolerance — but note it only helps against small jitter, not against 0↔50/100 swings.
  4. Make sure the travelling_time_down/up values in your HA KNX cover config match reality, so HA’s simulated position agrees with the status feedback.

To confirm the diagnosis, could you enable the logbook option (enable_logbook) and post the logbook entry / trace of one occurrence? It shows the trigger.id — it should be t_manual_tilt — plus your drive_time value and Tilt Wait Mode setting.

Why I wouldn’t add an “ignore tilt within 1 s of position” filter

  • Home Assistant doesn’t see telegrams, only attribute changes. The pattern “tilt change shortly after position change” also occurs on every genuine manual movement via a KNX wall switch (the actuator always reports both status GAs). Such a filter would swallow exactly the manual interventions the detection is supposed to catch.
  • The gap between the two telegrams isn’t the discriminating factor — their position relative to the settle window is. The filter would aim past the symptom.

If it turns out your total feedback latency genuinely exceeds what drive_time can cover (the slider currently maxes out at 180 s), let me know — raising that limit would be a small, safe change. But I’d expect option 1 or 2 above to solve it.

2813

Hello,

During hot weather, I use ‘Manual Override’ mode to prevent the shutters from closing when it gets dark or when the time falls within the last hour of the closing schedule.

My question is: what should I do if, in the children’s bedroom, I close the shutters for their afternoon nap at 2 pm and open them again at 4 pm? The shutters won’t close again after the reset time of 00:01, will they?

2814

Yes, your assumption is correct. Reopening the shutters at 4 pm does not cancel the manual override — it renews it (the man flag is set again with a fresh timestamp). With “ignore closing after manual” enabled, the scheduled evening close is therefore blocked, and the reset at 00:01 only clears the override flag without moving the cover. Since that day’s closing trigger has already passed, the shutters stay open for that one night. The next evening everything runs normally again.

Suggestions — each cover has its own blueprint instance, so you can configure the children’s room differently:

  1. Use “Reset per timeout” (e.g. 3–4 h) for the children’s room instead of the fixed-time reset — the 4 pm override then expires before the evening closing time.
  2. Or enable “Reset in position” with the open position — moving the cover fully open then resumes automatic control after the dwell time.
  3. For the hot-weather use case itself, consider a force-open entity (e.g. an input_boolean “heat mode”) instead of manual override — it blocks closing reliably while switched on, and the cover returns to the correct state when you switch it off.
2815

Hi @Herr.Vorragend
at first: Thank you very much for CCA! It’s the main reason I started HA years ago and has helped me a lot!
Just a short hint from my side:
As a long-time user I am really concerned about your code quality the last months. I know AI is making a lot of stuff much easier and you can care about edge cases in CCA much better. But maybe you should take the time to check the code and make sure everything is working before publishing it and only one update a week or so? Yesterday there have been 7! uploads on one day, each one including it’s own changelog. How am I supposed to read through all of that and maybe breaking changes for my system when I am only updating every 1 or 2 weeks? Today my house woke up when all blinds where opening at 5:30am because the “Time Control” checkbox magically unchecked in one of the updates (not good for the Acceptance Factor!). I was on 2026.07.13 V3. Now I see there is V7 already. Don’t misunderstand my concerns please. I am still very happy about grateful for your work. I would never be able to do something like that on my own. I think I need to let my AI check the changelogs and how it affects my system in the future.

2816

For the most part, those were all pull requests from another developer yesterday. And features were added, not just bugs fixed.

The ‘Time Control’ changeover took place back in May. Yesterday I simply removed the backwards compatibility because I was doing other ticket creators a favour.

I’ve been using ClaudeAI for a few weeks now just to keep on top of support at all.

I do understand what you mean. There really were a lot of complex updates yesterday. And the volume of AI-generated text descriptions is already enormous. But that certainly doesn’t mean the code quality is poor. It’s just that we could develop it on the DEV branch first.

That certainly wouldn’t have prevented your issue with the timing, though.