OK, so it sounds like the button controlling the boolean idea is out…
for another idea you could turn the automation ‘off’ at midnight, etc. then have another automation to turn the blind position control automation back ‘on’ when the blinds first move in the morning based on a change of position.
hm, that’s actually a very clever idea @finity , thanks!!
I realised one thing which could also work, I just don’t know how to set it up…
Shelly is capable of calling a URL at the event of the physical button press, I think this could be the perfect solution… what I would need to be able to solve now:
Am I somewhat right? Wish I could solve this on my own 
You’ve moved beyond my ability to help at this point.
I have nothing to test anything with.
Once you figure out how to turn on the boolean everything else past there is fairly basic so you should be able to work it out.
no worries at all my friend @finity !!
I’ll read on, and if I manage to solve it I share it with you!
@finity , look what I’ve found out after a lot of googling!! Turned out there was some development in the Shelly integration, and now I have built in sensors for the button states!!!
These sensors are disabled by default, that’s why I was not aware of them before (dunno why though), but look, I have two physical button state sensors per shelly, one up and one down :):):):) (gomb = button in my language)
This is where I’m gonna pick up this topic after I’m back from vacation…
Hi there, the ground you guys @Guesswho620 and @finity have covered is mind boggling awesome.
Any chance of one of you posting the full config? From using your code I cant get it to work, its still way over my knowledge level in HA, Im still stuck with lots of individual automations, and no shading.
Like @Guesswho620 I got plenty of roller shutters and have em grouped to 4 automations to open and close them depending on sun.sun elevation and lux. That kind of leads to funny situations for the terrace doors etc like beeing outdoor and the rollers come down, with no key. 
.
See here. I asked for help: Trying to get 4 shutter automations into one and shading like in FHEM
But no shading is done right now. Still got time to fix this. And yes the WAF is my biggest concern too, as we come from FHEM where there was a template, a bit awkward to setup, but working perfectly for the roller shutters, how ever in 5 years I never got to a usable front end, and we dont have switches for the sonoff tasmota controlled shutters.
Cheers Manne
I don’t have any of that used in my config. It was a completely intellectual exercise on my part.
but the solution was marked for one of the posts above so you could probably start there.
absolutely, I will do that, and make @finity 's masterpiece public, later today when I’ll have some time to collect, do some privacy cleanup on the code, and post it here.
I want to enhance it a bit later on - where I most probably will ask Finity’s help again, becasue he was suggesting this enhancement before, but I didn’t have a reliable method to use - to introduce the human or wife factor into the automation: disable the automation for a predefined amount of time (1-2-3 hours) when a shutter control button on the wall is pressed. Previously I didn’t have a reliable method to intercept these button events, but with the recent changes in Shelly integration they are consistently pushed to HA real time, which is great and brings new abilities to me.
i kind of got it working, after finding that my sensor had an other name 
as was used in your code… embarrassing
now my test shutter moves.
you may want to clarify which part of your code relates to what compass direction of the windows.
I still would like to upgrade this amazing code to add the shading depending on each single window specs and general conditions if or if not to shade.
I am working on the math for calculating the percentage of the shutter position.
But since this issue here is closed, could we may continue in my initial question to this issue?
If anyone is interested, it’s possible to reduce this:
position: >
{% if state_attr('sun.sun', 'azimuth') | float < 80 %}
0
{% elif state_attr('sun.sun', 'azimuth') | float >= 80 and
state_attr('sun.sun', 'azimuth') | float < 170 %}
100
{% elif state_attr('sun.sun', 'azimuth') | float >= 170 and
state_attr('sun.sun', 'azimuth') | float < 220 %}
{{ (((-2 * (state_attr('sun.sun', 'azimuth') | float ) + 440) / 10) | int) * 10 }}
{% elif state_attr('sun.sun', 'azimuth') | float >= 220 and
state_attr('sun.sun', 'azimuth') | float <= 250 %}
0
{% elif state_attr('sun.sun', 'azimuth') | float > 250 and
state_attr('sun.sun', 'azimuth') | float <= 300 %}
{{ ((( 2 * (state_attr('sun.sun', 'azimuth') | float ) - 500) / 10) | int) * 10 }}
{% else %}
100
{% endif %}
to this:
position: >
{% set a = state_attr('sun.sun', 'azimuth') | float(0) %}
{% set values = { 80: 0,
170: 100,
220: (((-2*a+440)/10)|int(0))*10,
251: 0,
301: (((2*a-500)/10)|int(0))*10 } %}
{{ values.get(values.keys() | select('>', a) | first, 100) }}
Correction. Added missing closing brace to final template.
It’s right if you want it to behave differently from the original version (because your version produces different results).
Copy-paste this into the Template Editor and experiment with it:
{% set a = 230 %} {{ a }}
The original version:
{% if a < 80 -%} 0
{% elif a >= 80 and a < 170 -%} 100
{% elif a >= 170 and a < 220 -%} {{ (((-2*a+440)/10)|int)*10 }}
{% elif a >= 220 and a <= 250 -%} 0
{% elif a > 250 and a <= 300 -%} {{ (((2*a-500)/10)|int)*10 }}
{% else -%} 100
{% endif %}
Revised version:
{%- set values = { 80: 0,
170: 100,
220: (((-2*a+440)/10)|int(0))*10,
251: 0,
301: (((2*a-500)/10)|int(0))*10 } %}
{{ values.get(values.keys() | select('>', a) | first, 100) }}
Your version:
{%- set values = { 0: 0,
79: 100,
170: (((-2*a+440)/10)|int(0))*10,
220: 0,
250: (((2*a-500)/10)|int(0))*10,
301: 100 } %}
{{ values.get(values.keys() | select('>', a) | first, 100) }}
You seam to know your coding stuff 
I was wrong, deleted my post.
Would you help including some more variables into the code?
What do you want it to do?
Currently the shading is done by azimuth, on fixed values from the guy who started this.
But actually shading should be done by a lot more variable, especially calculating the position of the roller shutter. I work on the calculations and variables right now, but I am by no means able to transfer the calculation into code.
Its more like,
With all that the calculation of the shading position of the roller shutter is just math.
and from that, one could code a code that just needs the values of the window to run shading all by its self with out big fiddeling. and does the shading in a way the acceptable sun streake inside is never exceeded, but the shutter is maximal open at the same time. who wants to live behind shutters is the idea here.
Those calculations (algebra) and the flow chart i could do, but i cant do the coding.
and beyond that, one may wants to prefer a awning thats mounted over the window if its not raining or windy or the awning wont cover enough of the window.
or has a roof window at an angle
or has shading by other objects and only requires shading in other azimuth degres.
and my want that it closes/open on dusk and dawn, probably on two steps, like pre open, open and pre close and close, depending on lux
and as well, one may want to asses the cloud level and the forecast temp and indoor temp or if an AC is running etc. pp
it would get quite complicated.
Here are all the variables I think would be likely needed.
User input mainly, but also some sensor values.
First we need these global variables:
now we need window facts for each window.
First we need some code that puts that all into perspective.
Then we need an automation, that runs every time the azimuth changes 1 full degree and considers all these values to come to a conclusion for the roller shutter or awing of each window and sets their cover.set_cover_position and then move on to the next one. Rinse and repeat.
The algebra part is pretty straight forward:
Wall thickness + indoor window sill + acceptable sun stake - position of roller shutter in the wall = one part of the triangle (a)
The other one (b) we get with
tan(alpha) * a = b
where alpha is the elevation
b is the position inside the full window height for the roller shutter to archive good shading by the owners specification.
so we could easily calculate a percentage from that.
100 / windows height * b = % to be closed (x)
Now we need to calculate the roller shutter position, we got a no shading value (c), probably 98%, and a full shading value (d), probably at about 15% so we have
c - d = e (100% distance from no to full shading)
e * x + c = roller shutter position in %
Now we need to calculate from what elevation on the roller shutter could be fully open. but this could also be entered by the user, since there could be a balcony or a roof eaves that shades the window in a different way than just the wall and its thickness.
What do you say @123 doable?
of course we need a variable block for global and each window and some automation that would consider the rest of the global variables like the temps and clouds and so on.
I think I got the algebra for the opening position inside this string
edit says: forget about this, the formula is all wrong, im working on it in the thread linkt with the 4 in 1 automation to posts further down. The solution will be there when I am finished with the roller shutter stuff.
set a = #deviation from vertical if e.g. roof window
set b = #height of window in mm
set c = #width of wall including inside window sill in mm
set d = #acceptable width of sun streaks (AWS) in mm
set e = #depth of the shutter from outside wall
set f = #start shading in % of roller shutter
set g = #fully shaded in % of roller shutter
set shutter_shading_pos = ((tan('sun.azimuth' + a) * 0,01 * (c + d) * b * (f - g)) + g)
I say you should start a new topic because this one was solved a long time ago and your requirements are substantially different. By starting a new topic, it’s more likely to attract fresh eyes to it.
yes, sir
Not to mention that it was a decent amount of work to get the original automations to work with just the azimuth vs shutter positions for 4 groups of shades.
by my count you’ve added about 60 different variables into the mix. I doubt anyone is going to want to tackle that.
If you get all the math worked out then I’m sure someone can convert it into a working template.
Good luck.
I have my elevation2shutter pos calculation in combination with parts of your azimuth code running on one test device (I have a baby diaper changing table that moves up and down to be stored away thats working with a roller shutter motor and is therefore able to resemble a roller shutter) right now, iits all totally messed up, but I’ll get it to work. Probably just did some silly stuff integrating all the calculations into one formula. I just start with an elevation follow today, and then build from there.
what really would help would be a code that simulates a days sun movement so I have sensors for azimuth and elevation to bind the code to that simulat 24h of elevation and azimuth inside 10 minutes. so I could see if my code does what i want it to do, but dont have to wait the whole day.
got some recommendation how to make that happen?