Hi @Eimeel,
I tried that but it told me the version you recommended was already installed.
I am (yet) not familiar with editing blueprints.
Can you please help me how to edit the blueprint and locate the correct section to comment-out?
As there is no update function for blueprint you have to options:
a) Just delete the blueprint and re-install
b) open the file in the blueprint order, delete everything and copy&paste the code from GitHub.
The correct setion to uncomment is still mentioned at Extensive roller shutter control including shading (brightness, sun position, temperature, forecast) - #69 by Eimeel
Hi @Eimeel,
please help me. I deleted the automations and the blueprint and installed it from the link above. I then edited the blueprint and mine ends with line 1081:
What am I doing wrong here?
Oh, wow. Seems that importing blueprints is killing some line breaks. Sorry.
So it’s lines 826-832
- or:
- condition: template
value_template: '{{ state_attr(blind, ''current_position'') | int(default=101)
== ventilate_position }}'
- condition: template
value_template: '{{ state_attr(blind, ''current_position'') | int(default=101)
== 0 }}'
But if you delete these lines and something strange is happening: I won’t provide any support for this.
Hi @Eimeel,
I commented the lines out with a leading #.
At least this morning the roller shutters opened as expected.
Thank you!
Hi Eimeel, first of all: thank you for this blueprint!
I’ve justed started testing it and there’s a problem. I’m testing with a door having a shutter outside and and an opening sensor. Up and down is working without issues in the mornings and evenings. When shutter ist up during daytime and I open the door, all is fine. When I close the door, the shutter closes to 0%. That’s strange behaviour. Here’s my config:
id: '1701160626332'
alias: 'Beschattung: Büro'
description: ''
use_blueprint:
path: jmerifjKriwe/automatic_blinds_shading.yaml
input:
blind: cover.beschattung_buro_empfanger
shading_blinds_position: 45
shading_outdoor_temperatur_sensor: sensor.temperatursensor_temperatur
shading_min_temperatur: 24
brightness_sensor: sensor.illumination_average
shading_sun_brightness_in: 10000
shading_sun_brightness_out: 5000
forecast_temp: 24
door: 'true'
brightness_down: 20
brightness_up: 80
time_up_early: '07:30:00'
time_up_early_non_workday: '08:00:00'
time_down_early: '16:00:00'
shading_elevation_min: 7
shading_elevation_max: 90
shading_azimuth_in: 185
shading_azimuth_out: 315
shading_min_temperatur2: 24
ventilate_position: 100
auto_shading: true
window_sensor: binary_sensor.fenstergriff_buro_offen
Trace:
Any ideas? 
Yes, I do
It’s because of this:
- alias: Blinds - closing after ventilate
and:
- condition: trigger
id: "t_bc_4"
- condition: template
value_template: "{{ auto_ventilate }}"
- condition: template
value_template: "{{ state_attr(blind, 'current_position') | int(default=101) == ventilate_position }}"
- condition: template
value_template: '{{ (window_sensor != [] ) and (states(window_sensor) == ''off'') }}'
I’m only able to guess which state the automation currently has. And I use the current_position for this.
So the quick fix for you is to change ventilate_position to 99.
But I have to find a real fix for it. Which is quite quick if I would duplicate code but I don’t like this idea so I have to think about it.
Works for me. 
Thanks!
1 Like
@Eimeel 
many many thanks for this great blueprint.
I understand that you made it complete for your use cases and you are not going to extend it anymore.
The good news is that your code is well structured and pretty easy to understand. And that helped me to apply some amendments which I needed:
- variables for open_position and closed_position. In some rare cases I don’t want the shutter to close or open completely, e.g. to leave some space for the cat to enter via the door on the balcony
Hence I introduced a closed_position, and set it to e.g. 44% - a variable position_tolerance which helps in case that the cover.set_position command doesn’t work exactly. e.g. it puts the shutter not exactly on 44% but on 45%. I applied the tolerance to the conditions that check the position of the shutter. at least my shutters need sometimes a tolerance of 1-2%
Thanks again for this great and handy blueprint! 
@Lupo what is the erroneous change of the shutter? if it is a small variance of some percent you might consider introducing a ‘tolerance’ in the conditions.
- condition: template
value_template:
"{{ (state_attr(blind, 'current_position') | int(default=110) <= closed_position + position_tolerance)
and (state_attr(blind, 'current_position') | int(default=110) >= closed_position - position_tolerance)}}"
please notice in the code snippet that I’ve introduce variables for open_position and closed_position as well. and I set the default to 110 to avoid overlaps with tolerances
Thank you
Well, we can add new functionality as long as it make sense and it is not bloating the code (which would make it very complicated to test).
I can add your changes if you like as they seems to make sense - and I guess your are not the only one who wants to define open and close positions 
1 Like
I would also love if you could add the suggestions by @nicknol. I also have the use cases of roller shutters that should not completely close (in my case kids that don’t want it too dark or bath room which shouldn’t be totally black at night).
If you don’t want to be involved here too much or feel like this is too much of a burden I could also put it in my github somewhere so others could collaborate (with proper attribution of course).
As you can see in the changelog we already implemented this enhancement
2 Likes
My use case is rather simple - I want to automate driving up and down of my roller shutters just on sunset and sunrise while respecting time_up_early, time_up_early_workdays, etc. I don’t do any shading based on e.g. brightness / azimuth etc. stuff. Also used to do this with ASC on FHEM
Am I correct that simply driving up / down based on sunrise/sunset is not implemented? If it is implemented, could you point me on how to configure it?
You are right, it’s not implemented.
Feel free to take this blueprint as a template and adjust to your needs.
I forked this blueprint a long time ago because I also wanted to incorporate a few individual requests. Eimeel and I had a good and long conversation here.
My fork is mostly the logic of him. But of course I’m in the fortunate situation of not having to pay attention to backwards compatibility. So I renamed all variables. I also installed the sun control.
But there is a very important note: Since I have adopted a lot of logic, I have some procedures that I have not checked in detail myself. I had a lot of naive ideas. But Eimeel was always able to convince me that his approach make sense. He is much deeper into the matter. And I’m just playing around a little.
Currently I haven’t published my fork yet. But I can upload it tomorrow.
@Eimeel i have one conceptional question in setting up the automation.
coming from iobroker and using the adapter shuttercontrol i was used to work with groups (eg “Wohnbereich”, “Schlafbereich”…) which included several shutters.
Within each “group” i had the option to set auto_down auto_up sunprotect for each shutter which gave a lot flexibility.
I am now thinking how to set this up with your blueprint.
OPTIONS
- 1 automation for each shutter (lot of administration work)
- 1 automation for each shutter-goup (could only set
auto_downauto_upsunprotectfor whole group?) - other apporaches?
how do you use it for yourself?
BR, Johnny
Well, our house has 21 windows and I created 1 automation for every shutter It is not that much work as you can copy an automation and adjust for every shutter.
But for sure you can create cover groups within Home Assistant and use 1 automation for every cover group.
Important: with my blueprint a cover group will be handled as if the group is one shutter. The group will not be split in several different shutters. Meaning if you e.g. create a cover group of two shutters and one shutter is at position 0 and the other one at position 100, the group will have position 50. If you define closing position as 0 (=default) and opening position (=100) nothing would happen here.
Consider me interested
I still think a common project on e.g. github would make sense, I could also contribute a little. Maybe together we can develop a good ASC alternative for HomeAssistant
1 Like
I strongly suggest to start this using python script or creating an integration. An all-you-wish blueprint for shutter control is hell to debug.
But may I ask to discuss all this via PN or in another thread? Cause otherwise it will confuse people
1 Like