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

Blueprints Exchange
, ,
2501

Thanks for the detailed observations.

Scenario 1: Manual opening from closed state

open = 0 → open = 0
close = 1 → close = 0 :white_check_mark:
manual = 0 → manual = 1 :white_check_mark:

The reason open stays at 0 is that your cover didn’t reach the configured open_position threshold. The blueprint checks if the cover is:

  • Within the open_position tolerance range, OR
  • At the fully open position (100% for normal covers, 0% for awnings)

If neither condition is met, the position is considered “unknown,” so the blueprint sets:

  • open.a = 0
  • close.a = 0
  • manual.a = 1

Check your settings: What’s your configured open_position value, and what actual position does your cover reach when you manually open it? If there’s a mismatch (e.g., cover stops at 95% but open_position is set to 98%), that would explain this behavior.

Scenario 3: Manual opening from manually closed state

open = 0 → open = 1 :white_check_mark:
close = 1 → close = 0 :white_check_mark:
manual = 1 → manual = 0 :question:

About manual.a changing to 0:

Looking at the blueprint code, when detecting a manual open operation, it should always set manual: { a: 1 }. So theoretically, if it was already 1, it should stay 1.

If you’re seeing it change to 0, this might indicate that the cover actually triggered an automatic action from the blueprint (not truly manual). The manual flag is only cleared when:

  1. The blueprint itself moves the cover (automatic action)
  2. A reset timeout occurs
  3. A fixed time reset triggers

To diagnose: Check your Home Assistant trace logs for this automation. Look for the stop message at the end - it should say "Manual Open detected" if it was truly recognized as manual. If it says something else, that would explain why the flags are different.

2502

With the current version 2026.01.11, I still have the problem that in the morning, when the window is tilted and then closed, the roller shutter opens instead of closing.

2503

I’ve analyzed both traces and identified the root cause of the issue. The problem occurs because of an outdated helper status from the previous day.

What I found in the trace:

On Sunday, January 12, 2026 at 04:42:36 (when the window was closed):

  • Trigger: t_contact_tilted_changed (window changed from tilted to closed)
  • Helper Status at that moment:
    • open: {a: 1, t: 1768156201} ← This timestamp is Saturday, January 11, 2026 at 18:30:01
    • closed: {a: 0, t: 1768145374} (Saturday 15:29:34)
    • vpart: {a: 1, t: 1768156201} (Saturday 18:30:01)

What happened:
The automation saw helper_status.open = true and helper_status.vpart = true, so it executed the “Window closed - Return to open position” branch (line 5288-5335 in the blueprint), which opened the shutter instead of closing it.

The Critical Issue:

On Saturday evening at 18:30:01, something set the open status to 1 (enabled). This is problematic because:

  • At 18:30 in the evening, this should be during closing time, not opening time
  • Your configured times show:
    • time_down_early: 16:00:00
    • time_down_late: 19:30:00
  • So at 18:30, the automation should be in the closing phase

1. What happened on Saturday evening at 18:30:01?

  • Do you have a trace file from Saturday evening around 18:30?
  • This would show us what trigger caused the open status to be set

2. Window timeline on Saturday:

  • According to the trace, the window was tilted at 17:58:14
  • Then at 18:30:01, both open=1 and vpart=1 were set
  • Question: Did the automation open the shutter when you tilted the window at 17:58? Or was there another event?

Could you please provide a trace from Saturday evening (ideally between 17:55 - 18:35)?

2504

I’m a little surprised by your question.

You’re asking why the helper switches to “open” when the roller blind is moved to 100%. Or am I misunderstanding something? That’s completely normal.

Unfortunately, I can no longer access the trace. Could you please re-upload the file?

When it comes to ventilation mode, there are almost certainly several trace files involved. Before, tilt (vpart), full ventilation, etc. Unfortunately, I then have to fight my way through all these files.

2505

here they are…

2506

I’ve analyzed all three traces and found the root cause of why your cover opens instead of closing when you close the tilted window in the morning.

What’s Happening

The problem occurs in Trace 3 (5:49 AM):

  • When you close the tilted window, the automation detects open=1 in the helper status
  • This tells the automation to return to the “open position” after ventilation ends
  • So the cover opens to position 100 instead of closing

The Real Issue

The helper status shows:

  • open: { a: 1, t: 1767551401 }
  • vpart: { a: 1, t: 1767551401 }

The timestamp 1767551401 converts to:

  • January 4th, 2026 at 23:56:41 (11:56 PM, the previous evening!)

This means open=1 was set the night before while the cover was in ventilation position (20). This is unusual because:

  • The cover stayed at position 20 all night (correct for ventilation)
  • But the helper status indicates it should return to “open” (position 100)
  • These two states don’t match!

Questions for You

To understand why this happened, I need to know:

  1. What happened around 11:56 PM on January 4th?

    • Did you manually move the cover?
    • Was there any other automation running?
    • Did you open/tilt/close the window?

  2. Do you have traces from that evening (January 4th, between 10 PM and midnight)?

    • These would show exactly what triggered the open=1 status
    • Probably not. But could you reconstruct the problem?
2507

Sorry, please ignore the traces from January 4. I don’t have any more traces from that date. In my opinion, the problem is the same as with yesterday’s traces. I provided the requested traces earlier.

2508

:rocket: CCA 2026.01.12 - Window Tilted Closing Time Fix

  • Fixed incorrect open status when window is tilted during closing time: The “Window tilted - Move to ventilation position” branch (inside BRANCH 1: CLOSE) now correctly sets open=0, close=1 to reflect that this is a closing action redirected to ventilation position. Previously, it incorrectly set open=1, close=0, causing shutters to open instead of close when the window was closed in the morning after being tilted during evening hours.

Thank you very much, darkm242.
With your traces, I was able to find and fix the error.

2509

Scenario 1 and 3:
Open_Position was 100. Closing Position is 0. I done it manually! until the endpositions where reached!

I have 2 trces for the opening, one at 9:58 when i close the cover via UI and at 9:00 when the statushelper was set after a check for opening!

2510

Thank you. PayPal is on its way.

2511

Oh dear! Don’t put me under pressure. It might not work out in the end, though. Thank you very much.

2512

:rocket: CCA 2026.01.12-02 - Next fix

  • Fixed shading state persistence: The shading state is now correctly saved to the helper. Previously, this state was lost, preventing the cover from directly entering shading mode when opening the following morning.
2513

Then please provide me with the traces.

But please write a brief note explaining what should have happened and when. I can’t tell from your post at 8:53 a.m.

Thank you very much.

2514

i uploaded 3 traces (times are in the filenames!) :

  1. manual close at 8:56 AM with setting the correct statushelper
  2. manual open at 8:58 AM without setting the statushelper
  3. wrong statushelper was set at 9:00 AM
2515

Dear tco95ttocs,
I think it’s great that you at least named the files.
But how am I supposed to know which trace belongs to which scenario above? Because here, the lists 1-3 are no longer identical to your description a few posts above.

It takes me a lot of time to link the traces to the error descriptions every time. It would be best if you could identify:

Scenario x:

  • What happened?
  • What should have happened?

Now to your new list:

1) manual close at 8:56 AM with setting the correct statushelper

I don’t need to check anything here if everything is okay, right?

2) manual open at 8:58 AM without setting the status helper

Why manual=1 was not set?

I analyzed the trace file and found the reason why the manual flag wasn’t set when you manually opened the cover.

The code in the blueprint is responsible for detecting manual position changes. It will only set manual=1 when all conditions are met. In your trace, condition 5 failed:

- "{{ as_timestamp(now()) > helper_json.t + drive_time | default(90) + 60 }}"

This condition checks whether at least drive_time + 60 seconds (default: 90 + 60 = 150 seconds) have passed since the last helper update.

  • Last helper update (helper_json.t): 1768204569 (2026-01-12 07:56:09)
  • Manual trigger time: 07:58:19 (approximately 130 seconds later)
  • Result: 130 seconds < 150 seconds → Condition FAILED

This condition prevents the blueprint from incorrectly classifying its own automated movements as “manual.” The blueprint waits drive_time + 60 seconds after any action it performs before it will recognize a position change as “manual” again.

Or in short: You manually controlled the roller blind immediately after a CCA roller blind movement, and CCA declared it as a separate movement. Could that be the case?

3) wrong status helper was set at 9:00 AM

What exactly is “wrong” here? Open=1 was set because CCA lowered the roller shutter. This overwrites your manual intervention. And that is correct.

2516

Hi Mathias,
this question has come up quite often.
I haven’t implemented a 100% solution for it.
I have to ask myself whether I really want to represent every individuality in the blueprint. There are countless tickets for wind protection, frost protection, rain protection and more. See GitHub issues - even the closed ones. :slight_smile:

And it will happen that at some point everyone will want to use individual sensors for this.

I originally built in the Force functions for this.
What’s missing is that you can’t control a fixed position.
Unless you misuse the ventilation for this purpose.

The idea isn’t gone. But right now, I need more stability in the blueprint again.

2517

This request has been made many times before. But I feel uncomfortable about having to integrate every sensor as an external sensor as well. I did this for the sun elevation, but not for the position values.

I would then have to duplicate everything. That would be absolute overkill in terms of usability.

But if you like, you could log it as an issue on GitHub. Maybe I’ll give it another try.

1 Like
2518

ah…sorry i was in hurry…so if i see it right, the wrong statushelper occured, because i was to fast :D…i mean this scenario will normaly never happen i think! i will test it on friday…

2519

Hey @Herr.Vorragend absolutely great Blueprint, I switched from “Adaptive Cover” Integration to your Blueprint last week and so far its straight forward, stable and all the integrations I want are already built in (ventilation, additional actions, etc.).

Just two questions:
I am running Somfy Covers and the bridge can only control 10 Covers at once, then runs into soft limit and needs a few seconds to “breath”… I thought splitting my covers up with the “Fixed Drive Delay” Option should do the trick but as an example, when all covers should open at 08:00 it seems that still all covers get triggered at once and the fixed delay is getting ignored. Am I missing something?

And regarding Cover & Tilt Positions, do they really all have to be unique or between which values does it matter and does it even matter between Position and Tilt Positions?

2520

Thanks for the information. I fully understand that it will never be possible to account for every possible situation :slight_smile:
Meanwhile I test an idea I just had. Duplicate the automation and set the condition to prevent running the whole automation. In one automation I check for my boolean=true, the other automation checks for boolean=false
Lets wait and see… I report back…