I have extended my old Blueprint for controlling roller shutters a bit and also added a practical function for shading.
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.
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)
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
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â
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.
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.
@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
@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
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.
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â?
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 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.
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.
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.
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: "%"
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
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.
