(deprecated) Extensive roller shutter control including shading (brightness, sun position, temperature, forecast)

This blueprint is deprecated.
Please have a look at the great CCA https://community.home-assistant.io/t/cover-control-automation-cca-a-comprehensive-and-highly-configurable-roller-blind-blueprint/680539

.
.
.
.

Hello all,

I have extended my old Blueprint for controlling roller shutters a bit and also added a practical function for shading.

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

So now a roller shutter can be controlled depending on:

  • brightness value
  • working day / non-working day
  • Resident of the room
  • time window (earliest, latest)
    morning and evening.
    A ventilation mode is also supported if the shutter belongs to a window/door with a corresponding sensor.

For shading are supported:

  • Sun position (azimuth and elevation)
  • Brightness value (possible independently of the upper one)
  • two temperature sensors (e.g. outdoor and indoor temperature or differential temperature sensor)
  • Temperature forecast sensor

Christmas mode is also supported (do not close in the evening if certain criterion is given)

Feel free to try it out. Works for me with >20 shutters without problems.

Link to GitHub Gist: automatic_blinds_shading.yaml · GitHub

Sorry to say: but the blueprint is quite complete for me, so I won’t add new functionality. If you need additional conditions, triggers, whatever feel free to fork.


Changelog:

2023-09-13: First release
2023-09-18: fix closing bug with brightness_sensor. small clean-up.
2023-09-26: trying to fix the deletion of forecast attribute in HA 2023.9
2023-09-29: fixed an issue with closing in case brightness_sensor2 is not defined
2023-09-30: changes:

  • BREAKING: fix for workday_sensor. Please re-select your workday_sensor
  • add: temporary_disable_shading to temporary disable the shading automation
  • add: selector for temperature sensors
  • change: better handling of optional sensors for shading
  • change: better handlung of optional brightness sensors
  • add: new input shading_waitingtime_out to have different waiting times for shading in and out
  • change: fix for forecast_temp in case of optional sensors not defined

2023093002:

  • deleted: t_1 trigger as it became useless
  • add: usage of min_version metadata
  • add: current version added to description

2023100101:

  • change: shading_waitingtime and shading_waitingtime_out will be ignored if shading is triggered by temporary_disable_shading

2023100201:

  • improved description of ventilate_position
  • add: new boolean auto_ventilate for ventilation mode
  • change logic for ventilation mode
  • fix: corrected a copy&paste error with shading_outdoor_temperatur_sensor for shading in

2023100401:

  • fix: corrected an issue with auto_ventilate (on) and auto_down ((off)

2023100501: @Herr.Vorragend code contribution :slight_smile:

  • add: new condition weather_conditions which can be used if a forecast sensor is defined. So if you don’t have a brightness sensor it can helps to shade only during good weather conditions.

2023101301:

  • fix: corrected an issue in case of not defined optional forecast sensor

2023111001:

  • deleted: testing stuff as it just bloats the code
  • add: tags for shading and optional options
  • add: emoji for better identification of related options
  • changed: better formatting of blueprint description
  • improved: binary_sensor as inputs in all cases where currently only input_boolean is allowed
  • fix: add filter-entry for inputs

2023112301:

  • fix: brightness_sensor should only be used for opening if brightness_sensor2 is NOT defined

2023120701:

  • fix: using weather.get_forecasts instead of weather.get_forecast (due to HomeAssistent 2023.12.0)

2023120801:

  • fix: if resident is going to sleep (sensor switches to TRUE) we need to close the blind regardless of current overwrite closing (adv_blind) state

2023120802: @nicknol code contribution :slight_smile:

  • add: open_position and closed_position so you can use other positions as 100 and 0.
  • add: position_tolerance in case your shutter is not reporting 100% accurate positions

2023120901:

  • fix: closing after ventilation is working again

2024010201:

  • New: blind can now also be a cover.group. Thanks to @Gifford47
  • New: shading_tilt_position is available to get better sun protection in case your blinds have slats. Thanks to @kreuzundkwer
  • Fix: better code formatting
  • Fix: using shorthand form
  • Add: if closed_position == 0 we use cover.close instead of cover.set_cover_position
  • Add: if open_position == 100 we use cover.open instead of cover.set_cover_position

2024010301:

  • Fix: adv_blind and resident are now using on/off and true/false

2024012501:

  • New: test_config implemented to perform some basic checks
17 Likes

Hi, thanks for you blueprint. I tried to use it but nothing happens. I tried to run with a minimal setup, so only screen, and sun azimuth+elevation configured, but then I still see ‘Check if blind moved above 99, so seems to be open for some reason’

1 Like

Can you show me your blueprint config?
And regarding azimuth+elevation, where are you from?

“Check if blind moved above 99, so seems to be open for some reason” is only trigger, if by this:

platform: numeric_state
entity_id: cover.your_shutter
attribute: current_position
above: 99

So I guess you just moved your shutter to be opened. Or your shutter is sending a trigger periodically.
Maybe you just have to wait some minutes until the azimuth of the sun is moving and therefor the sun sensor is triggering.

I tried to manually run with an open screen and a closed one.

This is my sun:

elevation: 32.79
azimuth: 203.44

This is my config:

description: ""
use_blueprint:
  path: jmerifjKriwe/automatic_blinds_shading.yaml
  input:
    blind: cover.screen_juna
    shading_blinds_position: 52
    shading_azimuth_in: 115
    shading_azimuth_out: 306
    shading_elevation_min: 10
    auto_shading: true
    ventilate_position: 100
    shading_min_temperatur: 18
    shading_min_temperatur2: 19
    shading_sun_brightness_out: 10000
    shading_waitingtime_out: 30
    shading_sun_brightness_in: 30000
    shading_waitingtime: 30
    testing: normal
    auto_down: true
    auto_up: true
    window_sensor: binary_sensor.lumi_lumi_sensor_magnet_aq2_opening_2
    door: "true"

Honestly opinion? I had previously implemented my cover controsl via NodeRed. My dependencies are quite complex. A few months ago I switched to YAML. Including the shading. And I created a blueprint for myself (https://github.com/hvorragend/ha-blueprints/blob/main/blueprints/automation/cover_shutters_control.yaml).
In terms of style, I wanted to change my blueprint and make it clearer. But cover threads have been becoming more and more present here in the forum for some time now. But no solution came close to what I wanted.

Until I found your blueprint. I’m not actively using it yet, but I’m super excited about it. Absolute enthusiasm. Thanks alot.

Can I also make feature requests? But I still have to check in detail what I’m personally missing. You are super. Thanks so much.

2 Likes

Oh, it looks like your are a German, too?
We’re both from the Fhem forum, right? I supported CoolTux at AutoShuttersControl back then.

@Herr.Vorragend yes, I used FHEM until last year and so for sure my blueprint has been created with ASC in mind. But I guess it’s slightly different in some details.
I’m open for feature request but I can’t promise that I will include every request as I don’t want to put too much complexity in the blueprint. It should handle most ideas already - sometimes you just have to think outside of the box :wink:

@Appesteijn your configuration seems to be ok. You are not able to manually execute the automation. The reason is that I heavily use trigger_ids to find the right scenario and thus manually execution is just ignored. This means you have to wait at least shading_waitingtime after a trigger - and within this shading_waitingtime you shouldn’t change anything :slight_smile:
Maybe you can have a look at the Home Assistant debug section and check the traces to find the issue? I guess it’s something trivial.

In your script at line 423:

  - platform: numeric_state
    entity_id: !input shading_sun_sensor
    attribute: elevation
    above: !input shading_elevation_max
    id: "t_so_4"

Shouldn’t the ‘above’ be a ‘below’?

Nothing is triggered, I see nothing in the logs or traces. Any more tips on how to debug further?

No, above is correct. The t_so_x triggers ate for shading out. So in case elevation is above the defined max, shading should stop.

Can you double check that you selected the right sun sensor? Default is sun.sun

I will do a test with your configuration tomorrow.

@Appesteijn I just tested with your configuration and faked a trigger via developer tools and voilá it works:

Can you update to the current version?

I updated the blueprint. Once reloaded, all screens immediately started to close. So that is good.

Problem I currently have is that I would like to take my outside light intensity (lux) as a trigger to open and close the shades (this works correctly), but the automation also uses this sensor for brightness_up and brightness_down, but then in opposite order.

So during the day shading_sun_brightness_in is used to close the shades when the sun is present, but then during the evening ‘Brightness down’ is triggered (because ‘brightness_sensor’ is 0 lux) and the shades come out again.

Should I just disable ‘Auto up’ and ‘Auto Down’? And only use ‘Auto shading’?

This is my config:

  input:
    blind: cover.screen_juna
    shading_blinds_position: 0
    shading_azimuth_in: 115
    shading_azimuth_out: 310
    shading_elevation_min: 10
    auto_shading: true
    ventilate_position: 100
    shading_sun_brightness_out: 10000
    shading_sun_brightness_in: 20000
    shading_waitingtime_out: 60
    shading_waitingtime: 60
    door: "true"
    window_sensor: binary_sensor.lumi_lumi_sensor_magnet_aq2_opening_2
    brightness_sensor: sensor.weatherstation_light_lux

I’m not sure if I understand your issue correctly.

In case of closing at the evening the code regarding brightness is:

              - or:
                - condition: template
                  value_template: "{{ ( (brightness_sensor == [] ) and (brightness_sensor2 == [] ) ) }}"
                - condition: template
                  value_template: "{{ ( (brightness_sensor != [] ) and (states(brightness_sensor) | int(default=brightness_down) <= brightness_down) ) }}"
                - condition: template
                  value_template: "{{ ( (brightness_sensor2 != [] ) and (states(brightness_sensor2) | int(default=brightness_down) <= brightness_down) ) }}"

In your case the second condition would be true. And default for brightness_down is 10.
So it means bellow 10 we are checking for several closing scenarios.

Aaaah, I think I understand your case.
Cause there is this check:

        - if:
            - condition: template
              value_template: "{{ ( (window_sensor == []) or  ( (window_sensor != []) and (is_state(window_sensor, 'off') ) ) ) }}"

If your window is open (= window_ sensor == on) then the idea of my automation is that you want to ventilate. And for ventilation it’s doesn’t make sense to close the blind completly. Thus the blind moves to ventilate_position and your defined ventilate_position = 100 (open).
Could this be the solution? Maybe just set ventilate_position to 50 to check if that could be the root cause.

I think I’m using your blueprint not entirely like your meant it.

I only have shades, no shutters. So I only want to lower them to keep the sun out. The shading part of the blueprint takes care of that very well. I don’t want them to close during the night.

I also have two windows that open to the outside and at these locations I don’t want the shades to lower when the windows are open. I thought the ventilation part of the blueprint would prevent that.

I currently have this config:

    blind: cover.screen_juna
    shading_blinds_position: 0
    shading_azimuth_in: 122
    shading_azimuth_out: 310
    shading_elevation_min: 10
    auto_shading: true
    shading_sun_brightness_out: 8000
    shading_sun_brightness_in: 18000
    shading_waitingtime_out: 60
    shading_waitingtime: 60
    window_sensor: binary_sensor.lumi_lumi_sensor_magnet_aq2_opening_2
    brightness_sensor: sensor.weatherstation_light_lux
    temporary_disable_shading: input_boolean.screen_juna_open
    auto_down: false
    auto_up: false

And use two external automations.
One that checks if the window is open and toggles the input_boolean.
The second that checks if it rains or is windy, opens the screens and then also toggles the input_boolean.

Ok, guess I understand it now.

Currently I am testing a new version, in this one I have added an additional switch (auto_ventilate) and also I rebuilt the code a bit to improve the ventilation logic.
But I have to test it during this day and night. So if everything is ok, I will upload it tomorrow.

@Appesteijn ok, new version is online.

Many thanks for this great Blueprint. It covers nearly all I need.

One question to the temperature sensor1

    shading_outdoor_temperatur_sensor:
      name: (Optional) Shading temperature sensor1
      description: 'Only for shading: This is the main temperature sensor. (Here,
        for example, the current outdoor or indoor temperature can be used as a criterion).
        selector: entity: domain: sensor This sensor does not have to be defined if
        the shading is to take place independently of it.'
      default: []

I expected something like this:

    shading_outdoor_temperatur_sensor:
      name: (Optional) Shading temperature sensor1
      description: 'Only for shading: This is the main temperature sensor. (Here,
        for example, the current outdoor or indoor temperature can be used as a criterion).
        selector: entity: domain: sensor This sensor does not have to be defined if
        the shading is to take place independently of it.'
      default: []
      selector:
        entity:
          domain:
          - sensor
          multiple: false

Am I wrong?

In addition to the shading cover position I would like so set a tilt position. Therefore I first defines a new input

shading_tilt_position: 
      name: Shading tilt position
      description: "Only for shading: To which tilt position should the cover be moved for shading?"
      default: 50
      selector:
        number:
          min: 0
          max: 100
          unit_of_measurement: "%"

then defined a new variable

shading_tilt_position: !input shading_tilt_position

and then added it next to the set_cover_position

- if:
                  - condition: template
                    value_template: "{{ testing == 'normal' }}"
                  then: 
                    - alias: "Moving the blind to cover position"
                      service: cover.set_cover_position
                      data:
                        position: !input shading_blinds_position
                      target:
                        entity_id: !input blind
                    - alias: "Moving the cover to cover tilt position"
                      service: cover.set_cover_tilt_position
                      data:
                        position: !input shading_tilt_position
                      target:
                        entity_id: !input blind
                - stop: "Stop the automation"

Is this the right way?

Regarding the temperature sensor, can you re-check your version? I think I fixed this with 2023100901.

And the position for calling cover.set_cover_tilt_position seems to be right, yes. But I don’t know if you also have to correct the tilt_position if you drive up and down. Could be necessary that you have to add the call to some other places.

Hi, thanks for your greate blueprint. I also come from FHEM (ASC). I would like to automate SOMFY shutters (RTS) using your Blueprint. The SOMFY shutters interpret the positions as follows:

  • top: 0
  • bottom slats not completely closed: 100
  • bottom completely closed: 200
    In FHEM-ASC, you could (or had to) specify this explicitly in an attribute. Is this taken into account by your Blueprint, or where can I set this?

Yes, this is again one of the things why I don’t add new features for the Blueprint :slight_smile:

As I had to learn, there are so many different variants, all slightly different. To store the necessary flexibility, I would have to define a number of other inputs and also more triggers. And also the conditions would need a few more and additional IF queries and and.
This makes it hard to maintain and also insanely complicated in debugging.

That’s why I decided against new features.

For slats there is no special logic implemented.
For your case you would have to look at the calls to cover.open_cover and cover.close_cover and replace them accordingly.

My blueprint has version 2023100501.You are right, in version 2023100901 the bug is fixed.

I’m going to test the tilt_position.

Thanks for your help!