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

Blueprints Exchange
, ,
507

Makes somehow sense! Thanks for all your checks and supports!!!

I also suffer on many Shelly Gen1 devices with interrupted connections (seems to be a known issue with the integration). On the log of this shutter you see a “reconnect” at 8.22 which is recognized as manual position change in CCA i would say. Nevertheless shading was activated at 8.31 (trace enclosed) and at 8.32 the log shows opened although it still keeps the shading position. Shelly integration these days sem to struggle.

Bildschirmfoto_10-5-2024_84129_homeassistant.local
Bildschirmfoto_10-5-2024_84129_homeassistant.local450×613 97.1 KB

Trace 8.22 with connection lost led to man. position change:

Trace for automatic shading at 8.31

Trace when status of Shelly (w/o user interaction) was changed acc log to open:

Shutter Config in CCA

alias: CCA-2-Beschattung_Seite VDB_Dachgeschoss
description: erstellt 22.02.24
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    shading_forecast_sensor: weather.openweathermap
    blind: cover.s25_dg_vdb_22
    auto_options:
      - auto_shading_enabled
      - auto_down_enabled
      - auto_up_enabled
      - auto_sun_enabled
      - auto_ventilate_enabled
    time_control: time_control_input
    cover_status_options: cover_helper_enabled
    drive_time: 20
    time_up_early: "07:00:00"
    time_up_early_non_workday: "07:30:00"
    time_up_late: "08:30:00"
    time_up_late_non_workday: "08:30:00"
    close_position: 20
    time_down_late: "23:00:00"
    time_down_late_non_workday: "23:00:00"
    workday_sensor: binary_sensor.workday_sensor
    position_tolerance: 1
    shading_position: 15
    shading_azimuth_start: 50
    shading_azimuth_end: 230
    shading_temperatur_sensor1: sensor.openweathermap_temperature
    shading_min_temperatur1: 13
    shading_weather_conditions:
      - sunny
      - partlycloudy
      - clear
      - cloudy
    check_config: true
    auto_global_condition:
      - condition: state
        entity_id: input_boolean.automatisierung_rollade_standard_automodus
        state: "on"
    shading_elevation_min: 0
    shading_forecast_temp: 19
    sun_elevation_up: -1.5
    sun_elevation_down: -2.6
    cover_status_helper: input_text.rolladen_status_inputhelper_vdb_dachgeschoss
    individual_config:
      - allow_shading_multiple_times
      - prevent_shading_end_if_closed
    auto_shading_start_condition:
      - condition: state
        entity_id: input_boolean.automatisierung_rollade_sonnenschutz
        state: "on"
    ventilate_position: 25
    ventilate_tilt_position: 25
    auto_ventilate_force: input_boolean.automatisierung_rollade_sonnenschutz_garten_seite_force
    check_config_debuglevel: debug
    shading_waitingtime_start: 0
    shading_waitingtime_end: 0
    shading_min_temperatur2: 0
508

sorry, should work now. Thanks!

509

Hi,
I have a small comprehension problem.
What do I have to tick to prevent a roller blind from opening at the end of shading if it has been moved to a lower position during shading?
Background: When our son is put down at midday, I trigger an automation that, among other things, moves the roller blind to the close position. Unfortunately, CCA opens the blind when the shading ends.
I have checked the box “Prevent the end of shading when the cover is already closed” - is that wrong?

510

I had deactivated Ventilation already and set open to 100/100, Close 0/0 and Shading 0/0. i have to set Close and Shading to 0/0 because with 1/0 for example my blinds doesn‘t close.

511

@Herr.Vorragend

It has just happened again. According to Trace, the shading was cancelled because the brightness level in the children’s room was too low. This is also true because I moved the roller blind from shading to closed.

image
image1170×1309 119 KB

512

i have a silly question about the waiting times!
the waiting start time means, that if all conditions are true, the cover will move later!
So if the time is set to 1h, and the all conditions ar true at 9am, do the cover will close at 10am rigth?
And teh same wit the end time! if all conditions for ending are true at 6pm the cover will open at 7pm right?

And during the day the automation will react only every hour equal which of the 2 values i set?

513

I‘m observing these behavior, too.
It feels like, there is something wrong or it differs from my expectations.
What you describe, meets my expectation. But I have something to add. If you have a waiting time of 1 hour, all your conditions must be true for the hole hour. If any condition became false in this hour, shading should not happen. That’s what my expectation and understanding is. A false condition let to a kind of retriever for the waiting time.

514

Force open not working
Hi there, I really love your blueprint. I’m already using it for my blades but are struggeling with my “Markise” shading. I want to force open when it rains and have defined a binary sensor for it already. The automation get trigged by the sensor but the Markisen is not opening. Do you have any idea? This is the trace: https://drive.google.com/file/d/1wE4nU86jMxNHyj783jhRKWf-n9FoiCG7/view?usp=sharing

515

today a curious thing happend!
i set the end time waiting to 30min!
All conditions where true, the cover closed normaly. At about 12:37 the second additional temp sensor gone below his min value. → so shading should end. Between 12:40 and 12:45 the temp sensor goes above his min value. So the cover should stay closed! BUT with the end time set to 30 min, the cover opens around 13:08.
And closed nearly 1 min later! This shouldn’t happened!!!
@Herr.Vorragend: So if the waiting timer ends and before the covers move (equal for start or ending), the conditions should be checked again, to avoid this! Maybe its still implemented, but than its not working correctly :wink:

516

That’s the behavior, I‘m investigating. I also think, that there is something wrong.

Edit:
It really seems like there is a kind of retrigger missing.
The automation ist waiting for the defined waiting time, but it ignores that during the waiting time the condition was going to true again.

This happens for me, when shading ends for the automation, but not for me :slight_smile:

Edit2:

Today it happend again while I was sitting on my desk. I grep the configuration and the trace. Maybe it could help.

My threashold for shading end is at 18.000lx with a waiting time of 900s. At 16:24 the cover was opend by the automation beause of the brightness sensor.
Thats indicates me, that at 16:09 the automation reached the shading end value.

image
image1390×349 6.13 KB

517

Could be that my Problems with blinds are solved when this PR is merged to hahomamatic.

@Herr.Vorragend can you implememt this as states in your blueprint then?

518

thats looks good, but the questions is now, should it be closed again, because the brightness rises again?

519

I think, it shouldn’t opened because of during the defined waiting time the brightnes rises again.

On the other hand, yes it should go to shading-position again. But it does not. The automation has not yet been triggered again since the cover went up. The brightness has continued to increase since then.

520

Until a few days ago, I had queried in the blueprint to see whether the status might be unavailable. However, this had some disadvantages.

I have now installed the condition elsewhere. This means that the status change should no longer be recognised. Upload will follow shortly.

(Although - to be honest - the Shelly integration is a bit strange).

Your last trace is the reaction to reaching the shading position. This is completely normal. Position 15 was recognised and triggers the automation. There I now check whether the movement was triggered within the “DriveTime + 60 seconds” of CCA. This was the case here and the automation was cancelled. Everything is OK. Everything is correct.

The fact that the status in your roller blind is set to “has been opened” is also completely normal. I have the same problem with Homematic. This is because position 15 still means open according to the HA definition. This is the HA status and I have absolutely no influence on it.

1 Like
521

Thanks for the trace.
CCA has cancelled because the force is still active.

Force is a final state that cannot be cancelled. Automation will never be able to override a force. So the force must be cancelled manually beforehand.

If you use force, you are responsible for getting CCA back on track.

I will sharpen up the description text in the next update.

1 Like
522

Sorry, but I can’t find your original post again. Did you delete it?

523

Hmm, now I’m wondering whether this is a bug or not.
The “Force Open” function asks whether general opening is activated at all.

This is the option “1 - :arrow_up_small: - Enable automatic daily cover opening”. And this is deactivated for you. You have only activated shading.

I change this in the blueprint and omit the check.
Update will follow shortly.

524

That is absolutely correct.
This should prevent the sun protection from being cancelled, as you have already moved to the closed position manually.

How should I understand this? Have you already tried this and does it work?

525

Then please send me the trace as well. Anything else would be guessing.

526

You’ll have to help me a little here. I am deeply immersed and have a few comprehension problems.

In your four trace files, there was one that is responsible for closing the blinds. The process was cancelled at the point where it checks if the blind was already closed on the same day. And that was the case here at 16:21. After that, it was probably opened again somehow. Later in the evening, CCA then cancels because multiple closing should be avoided.

Can you tell me what happened to you that day?
And I’m going to think again and ask myself whether the check is perhaps programmed incorrectly.