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

Hello everyone, I would like to introduce you to my roller shutter blueprint:

Cover Control Automation (CCA)

Open your Home Assistant instance and show the blueprint import dialog with a specific blueprint pre-filled.

My GitHub Project

This is a comprehensive and highly configurable blueprint that can be used for the following basic purposes:

  • Opening and closing the roller shutters (depending on brightness, sun-elevation and within time windows)

  • Ventilation feature (Currently for two-way sensors)

  • Resident feature: keep the cover closed if resident is asleep

  • Complete flexibility in almost all parameters:

    • Fixed drive delay and random drive delay
    • Waiting time duration for triggers
    • Position tolerance
  • Each feature can be activated or deactivated as required. Not only through a switch in the blueprint, but also through dynamic conditions outside the automation. Condition examples:

    • If, for example, your blinds on the upper floor only close automatically and are not opened via the automation, you can also enable the blinds to be opened during this time by activating a vacation mode boolean.
    • If you have visitors or a party, you may not want the blinds to close. This can be easily configured using a party mode boolean.
    • If, for any reason, you want to pause the activation of shading or the ending of shading, this can be controlled via a shading boolean.
    • If you want to suspend the entire roller blind control for a short time, perhaps because maintenance work or window cleaning is being carried out, this is possible with just one Boolean.
    • Are the roller blinds on side doors normally only opened by the automation system and never closed because you don’t want to lock yourself out? But on vacation, the blinds should still be closed. This is how the conditions work.
  • Extensive automatic sun shading with many different setting options:

    • Sun azimuth
    • Sun elevation
    • Solar irradiation/Light intensity/Illuminance
    • Weather Conditions
    • Two different temperature sensors (compare thresholds for indoor and/or outdoor sensors)
    • Not only the current temperature, but also the temperature forecast can also be taken into account.
  • Added the option to save the current status in a helper. This has the advantage that the roller blind can also be in other positions and the automation can still be executed. And manual interventions are not constantly overridden with every trigger.

This was originally a fork of Eimeel’s blueprint automatic_blinds_shading.yaml.
Note: My blueprint is not compatible with Eimeel’s original. I have used his basis, but my variables are completely different from his design.

General information
  • If multiple criteria (e.g. temperature sensors and/or azimuth and/or elevation) are defined, shading will not occur until all criteria are met.
  • It is not possible to execute this automation manually!
  • In order to have extensive flexibility here, different sensors are used. But there is also the possibility to define a resident of the room,
    so that e.g. the cover does not go up in the morning, although the resident is still sleeping.
  • If you want to use sun elevation and/or azimuth it’s strongly advised to use sun.sun. And please make sure your sun.sun entity is enabled!
Important configuration notes
  • time_up_early should be earlier than time_up_late
  • time_up_early_non_workday should be earlier than time_up_late
  • time_down_early should be earlier than time_down_late
  • shading_azimuth_start should be lower than shading_azimuth_end
  • shading_elevation_min should be lower than shading_elevation_max
  • shading_sun_brightness_start should be higher than shading_sun_brightness_end
  • open_position should be higher than closed_position
  • open_position should be higher than ventilate_position
  • closed_position should be lower than ventilate_position
  • shading_cover_position should be higher than closed_position
  • shading_cover_position should be lower than open_position
  • resident is only allowed to be on/off/true/false
  • cover must have a current_position attribute

I hope you have lots of fun with this version.


Changelog - (Full Changelog on Github)

2024.01.29-01:

  • Updated hints
  • Fixed one resident condition (thx to Eimeel)
  • Added version number to json (thx to Eimeel)

2024.01.29-02:

  • Added: Implemented configuration check to perform some basic checks (idea and code by Eimeel)
  • Added: Cover Drive Time
  • A few logic changes

2024.01.29-03:

  • Added config check for sun attributes
  • Fixed: Wrong trigger condition while closing

2024.01.29-04/2024.01.29-05:

  • Updated descriptions

2024.01.30-01/2024.01.30-02:

  • Fixed and extended config check
  • Fixed closing condition. Wrong fix yesterday. Back to the origin. Will check this later.

2024.02.01-01:

  • Minor Layout changes
  • Removed commented out code
  • Fixed closing-condition
  • Fixed cover status helper initialisation and still make the first cover drive possible

2024.02.02-01:

  • BREAKING CHANGE: Please reconfigure/rename the variables close_position and shading_position in your blueprint config.
    Old: closed_position - New: close_position
    Old: shading_cover_position - New: shading_position
  • Added tilt positions for open, close and ventilation

2024.02.03-01:

  • Strict separation of the two brightness sensors. The previous problem was that the shading sensor used the same values to open or close the blinds as the normal sensor. Depending on the sensor (different edge, slope, median, filter, etc.), incorrect triggers occur.
    Important: If required, please register both brightness sensors.

2024.02.03-02:

  • Opening the blinds only until time_down_early. Otherwise, overlaps may occur if the brightness values are not set correctly. Avoid bouncing the blinds.

2024.02.06-01:

  • Added: Helper length validation
  • Comprehensive JSON changes / Now multidimensional JSON
  • Roller blind movements can now only be executed once a day when the helpers are used.

2024.02.07-01:

  • Fixed weather.get_forecasts: The response from the service is a dict with the target entities as keys

2024.02.09-01:

  • Streamline the code
  • Added option to enable time control via external schedule helper
  • Added more options for manual time control (drive up - late on non-workdays / drive down early and late on non-workdays)
  • Possible breaking change: You should reconfigure the times in your CCA automations!

2024.02.12-01:

  • Allow input_boolean as contact sensors.
  • The state of the contact sensor can be true/on or false/off
  • Fixed time control bug

2024.02.13-01:

  • Fixed potential bug when opening via time control

2024.02.15-01:

  • Fixed timestamp comparison bug
  • Faster checking for manual position changes

2024.02.18-01:

  • Fixed: Schedule open/close-bug
  • Fixed: Next try - faster checking for manual position changes
  • Separate ventilation from lockout protection
  • Added own lockout protection feature
  • Removed door/window chooser (contact_cover_place)

2024.02.18-02:

  • Fixed: Problems with helper json

2024.02.19-01:

  • Added: External trigger to force opening or closing. Useful for Antifreeze, RainProtection or WindProtection.
  • Fixed: Still timing problems occur when recognising manual drives
  • Added: Additional actions for open, close, ventilation, shading start and shading end
11 Likes

Placeholder

nice, thank you!

Happy Release Day :slight_smile:
Thanks again for all the work you put in.As a shift worker, I am very happy about the resident mode. But what I’m missing is an additional block that doesn’t open the blinds, for example during school holidays or weekends.

Hi Loi, you can control all of this via the conditions.

But you should be able to achive this by using the resident mode, shouldn’t you?
As it’s an input_boolean is just for this, you can create an automation and define however you want.
Or am I missing your point?

You’re right about resident mode. But I only have one presence detector in the bedroom and if it doesn’t recognize me or my wife, the shutters open. It is easier not to open the shutters on certain days. @Herr.Vorragend gave me the tip about the Additional Conditions For Opening The Cover and I’m going to test that now :slight_smile:

I see. But still I would prefer to use this with resident mode. Create a new input_boolean and set to true on all days you don’t want the shutters to open.
Guess it’s easier than dealing with additional conditions.

1 Like

Oh dear… you’re so right. I didn’t even think about this possibility. Thank you.

1 Like

I just started to use this blueprint but luck is not yet on my side.
in my application i want to use the blueprint just for shading in combination with screens i have installed in my home.

Regardless of what i try i cannot make this blueprint control my screens for shading alone.

I made sure to:

  • Configure a cover to control
  • selected the shading option (6) as only enabled option)
  • under the shading option i’ve set the:
  • start and end azimuth (65/220)
  • the start and end elevation (6/90)
  • i’ve set 0% as the setting to close the screen for shading (this is when my screens are fully closed)
  • i’m using the default weather forecast conditions and made sure the forecast entity exists

triggering the automation manually or wait for sun elevation and azimuth to become true, no dice.

Must be something obvious i am doing wrong but i cannot seem to find out what.

HELP! :slight_smile:

You need to post your configuration.
And - as stated in the documentation - it’s NOT possible to manually trigger this blueprint.

1 Like

i’ve testet the blueprint with the following config:

it went down at 17:00 pm although i set sun_elevation_down: -10.2 wich should have been after 5pm!?

anything i’m doing wrong or a bug?

alias: "Rolladen: Isabella Tür"
description: >-
  fährt nach Sonnenauf- /untergangszeiten, aber nur innerhalb des Fensters (7-9
  Uhr)

  Beschattung ab 18 Grad
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    shading_forecast_sensor: weather.openweathermap
    blind: cover.rolladen_bella_tur
    time_up_early: "07:00:00"
    time_up_early_non_workday: "08:00:00"
    time_up_late: "09:00:00"
    auto_brightness_options: auto_brightness_disabled
    sun_elevation_up: 0
    time_down_early: "17:00:00"
    sun_elevation_down: -10.2
    drive_delay_fix: 5
    drive_delay_random: 0
    position_tolerance: 5
    shading_azimuth_start: 158
    shading_azimuth_end: 258
    shading_forecast_temp: 18
    workday_sensor: binary_sensor.workday_sensor

Could be a bug. Stay tuned.
@Herr.Vorragend see PN

Btw: “fährt nach Sonnenauf- /untergangszeiten, aber nur innerhalb des Fensters (7-9 Uhr)” ist not completely right. It’s opening between 7-9 but closing 17-22.

yeah i know, my description is not yet final, as the blueprint ist still under evaluation :wink:

Could you please check whether “sun.sun” and the elevation attribute even exist? If not, a default value is assumed which makes the condition apply.

I hadn’t even thought of such an application. But from the code it should even be possible.
So I need your config to get an impression.

In the worst case, we need a screenshot of the trace.

alias: SCREENS - Woonkamer groot
description: ""
use_blueprint:
  path: hvorragend/cover_control_automation.yaml
  input:
    blind: cover.woonkamer_groot
    auto_options:
      - auto_shading_enabled
    auto_global_condition:
      - condition: state
        entity_id: input_boolean.screen_automation_bypass_woonkamer_groot
        state: "on"
    shading_cover_position: 0
    shading_azimuth_start: 65
    shading_azimuth_end: 220
    shading_elevation_min: 6

This is my current configuration. Thanks in advance for wanting to look at this :slight_smile:

yes, it exists:

One short question:
Could you please show me the state of: input_boolean.screen_automation_bypass_woonkamer_groot?

If automation should work, the conditions must be true or empty. These are conditions and not blockers.