☀️ Cover Control Automation (CCA) - a comprehensive and highly configurable roller blind blueprint

I have now checked this briefly.

A lot has changed in the latest beta updates since the version of 21 August. I am of the opinion that the error should not actually occur.

Even with Resisdent=On, the blind moves to the ventilation position.

Could you please test the latest beta?

Hi all,

which weather integration are you using for the weather forecast and the shading option? I’m using currently the integration from met.no, but the forecast is not so accurate for my region (Germany). It often changes to cloudy or rainy when the sun is shining and the shading should be further active.
Greetz
tukane

Hi, sorry but i have another question, the blinds don’t close at end of the day with the brightness settings. The trigger for brightness is executed, but the blinds didn’t close after the delay time. They close only after the time setting is triggered.
Did i miss something in the configuration?

Trace

Yes, the logic is different.
The brightness is not independent of the rest.
The cover is only closed between the periods. So between Early and Late.
This was chosen deliberately.

Brightness and sun elevation always only between the times

I use the DWD (Deutscher Wetterdienst) intergration from FL550:

1 Like

I’m not sure I can search in this thread, so sorry if this has been asked before.

How is this different from the Adaptive Cover integration?

Or is it a case of YACI? Yet Another Cover Integration :smiley:

I personally use OpenWeatherMap.
But for shading, I removed the weather conditions. The prediction was wrong too often. But also with all other integrations.

1 Like

HI im using the met.no forecast for my region (Region Hannover), i tested also the 2 from dwd and openweathermap, but they are all not perfect. I figured out, that the forcast from the dwd integrations are fixed for aboeut 6h, that could be sometimes to slow if weather changes!..For the actual weather the met.no is more accurate. At the end you have to test all of them and after 1 or 2 month yo have to decide which is the best in your place!

Both solutions have completely different implementation approaches. I really like adaptive covers.

I don’t feel like reading the descriptions to you now. Just try out what you like better. It depends very much on what you need.

New really huge update :grinning:

Comprehensive redesign of the contact control for lockout protection and ventilation as well as a modification of the shading control.

2024.09.04:
  - Major Update:
      - Complete redesign of the logic behind the contact sensors.
      - Splitting the contact sensors into "Tilted windows" and "Open windows"
      - Lockout protection removed from the automation options
      - Lockout protection can be configured individually
      - Please reconfigure contacts,  residents and manual override settings!

  - Major Update:
      - Complete redesign of the shading triggers.
        I have now separated the originally combined triggers again.
        And the waiting time is no longer taken into account in the trigger and also not as a delay in the action sequences.
        Instead, the new trigger time is now saved in the helper.
        This has the wonderful advantage that we can work with several shading triggers again, which do not reset and restart each other.
        Unfortunately, this makes things more complicated in support, as I now need traces for both triggers (pending and execution).
        But I also hope to have fewer customer service calls in the long term.
        In addition, you can now see traces again that were previously not available because they were cancelled directly in the for-wait time.

  - Updated: If you previously used the manual control reset at a certain time, you now have to reconfigure this feature once. I had to rename the variable is_reset_time to is_reset_fixed_time.
  - Added: Config check for schedule helper
  - Added: Sun shading can now be allowed even if a resident is present #131
  - Fixed: A delay is now also taken into account when the sun shading is ended #128
  - Fixed: When checking the end of shading, a True was always output if the weather conditions array was empty #133
  - Fixed: Prevent double triggering if early+late times are identical.

Breaking Changes:

Removed settings:

  • “Prevent the cover from closing immediately after deactivating the lockout protection” (prevent_close_after_lockout)
  • “Enable lockout protection” (auto_lockout_protection_enabled)
  • “Contact Sensor Entity For Ventilation” (contact_sensor)
  • “Contact Sensor Entity For Lockout Protectio” (contact_sensor_lockout)
  • “Prevent automatic closing due to the resident sensor” (prevent_closing_by_resident)

Please delete the following variables in the YAML code:

  • prevent_close_after_lockout
  • auto_lockout_protection_enabled
  • contact_sensor
  • contact_sensor_lockout
  • prevent_closing_by_resident
  • is_reset_time (replaces with is_reset_fixed_time)

=> Many thanks to the two testers darkm242 and tco95ttocs.

4 Likes

Hi, I did the update and adjusted everything. Activating the sun protection worked perfectly. But then the sun protection was stopped even though there was actually no reason for it. Did I miss something?

It is triggered more often again and then checked later to see whether the conditions apply. And in your case, the brightness was apparently below the value of 9000.

Yes, it has always been that way. The brightness sensor is behind the roller blind, where it still has 17LX when shaded. That’s why the Sun Shading Brightness End Value is 0 Lx.
So far this has never made a difference and the end of the shading was at 231° Azimuth End Value.

Now I have noticed that all the roller blinds that are supposed to go into the sun protection do so, but keep opening and after a while they go back into the sun protection.

open:

close:

open:

Please try the small update from today. This could be related to it.

1 Like

i got a similar problem today, updated yesterday to the new version and today nothing happens with my automations!
i add the traces from today for 2 of them, the latest one should be the trace for closing, but nothing happend!
cover 1
cover 2

Also the shading at the door i tested with the beta didn’t work. Cover is closed manualy to the shading position, i open the door nothing happend, closed it and open it again, still nothing happend! But the best part is, there is no trace to send!

Hopefully that helps

Oh i think i figured out, why it didn’t work, forgot to restart HA yesterday!

Could it be, that this line is not neccessary? Because they are still deleted!?!

I can still see the parameters in my automation.yaml. Nothing was automatically deleted for me.

What is the right intention for me now? Defective or functional? :smiley:

got it, had just one of them, so i overread it!

not sure;)…wait until lunch, than we will know :wink:

Hello, I did the update on September 4th, 2024 and I noticed an error in the Home Assistant protocol. I don’t know if this is relevant, nor have I checked whether everything works as usual

Logger: homeassistant.components.template.trigger
Quelle: components/template/trigger.py:64
Integration: Template (Dokumentation, Probleme)
Erstmals aufgetreten: 09:49:23 (90 Vorkommnisse)
Zuletzt protokolliert: 10:04:39

Error initializing 'template' trigger for 'Ga_Ro': TypeError: unhashable type: 'list'
Error initializing 'template' trigger for 'KU_Ro': TypeError: unhashable type: 'list'
Error initializing 'template' trigger for 'SC_Ro': TypeError: unhashable type: 'list'
Error initializing 'template' trigger for 'WO_Ro_Links': TypeError: unhashable type: 'list'
Error initializing 'template' trigger for 'WO_Ro_Rechts': TypeError: unhashable type: 'list'

1 Like