Then my guess is you have one of those blinds which don’t follow HA standard and the open/close action is reversed. The blueprint can’t handle that I think, but the adaptive cover integration (which uses the same logic) by @basbrus can.
I don’t think it’s that. I have the exact same shade on a different window facing south and it’s been working pretty well so far, it’s just the 90 degree windows that seem to not like things.
No idea what else it could be unfortunately.
I wonder if it has to do with the need to use the left/right field of view? The sun isn’t directly in front of the window, it’s off a bit. On the south facing window it gets the full brunt of it. But I’m not exactly sure how to tweak the left/right settings to test that.
Has it moved the blind at all?
ps. I also noticed you named your automation ‘Trigger: Set West Curtains Based on Sun Position - Office Shades’, I guess you meant east?
Yes, East, haha. I was creating automation for each shade and duplicating, I missed that.
It worked this morning, so kind of bizarre but I’m going to take the win and see how it does. I just saw it creep up right as I was typing this so maybe it just needed some time to think about what it did 
If you decide to update this, it might be cool to allow a template condition for Minimum Cover Position in addition to the Default Cover Height templating ability. As a use case: during Christmas season (which is a sensor for me) there are some windows that get decorations on the sill, my current automation I check if it’s Christmas season and then only close the shade to, say, 10% instead of 0% so it doesn’t mess with the decorations.
It might also be useful when doing day of the week changes without having to create multiple automations. I might never want them to close fully on the weekend when I’m not in my office, but when I’m in the office M-F and want the sun out of my eyes and off my screen then it’s quite handy. Right now I just have a duplicate blueprint automation to handle that using conditions.
The main focus of the blueprint/macro is to provide you the correct calculations for the position. Manual conditions are better managed by creating other automations and disable the blueprint when preferred. Because 1 blueprint can not cover all (edge) cases people want adjustments for.
On the other hand the linked integration in this topic provides a sensor with the calculated position. You could use that sensor within a single automation together with your personal needs to automate your blinds 
2 Likes
Multiple automations is what I’m doing now with conditions, and that works. One question @basbrus is the blueprint was based on your code and your Git link shows 1.0.3, the one I have is 1.1.2 and I’m not sure who-does-what. I’m assuming the 1.1.2 is a modification of your original, but the “add to my blueprints” goes to your secret Gist. I’m not sure how I ended up with 1.1.2 since I don’t see a post in the thread for it, but I did. Very cool automation, by the way, quite clever and really useful!
1 Like
Yeah @basbrus work is very impressive! He deserves all the credit for that, I only contributed the original template code for determining the position
1 Like
So is 1.1.2 the latest? I was seeing if there was an update but it takes me to the other original code that is 1.0.3.
This is the latest standalone blueprint auto-sun-blind/blueprints/auto_sun_blind.yaml at 67983aee8461e0ca5a316902afb1ab9f8c57c221 · langestefan/auto-sun-blind · GitHub
There is also an adaptive cover blueprint with version 0.0.3 but that only works with the integration.
Hi Stefan,
Thanks for a great post. I will try and use it with our almost horizontal awning. Have you found a calculation method for calculating h for other angles yet?
I will also need to add some if scenarios, where the awning is not used, if its shady or if there is too much wind. I have an anemometer in HA, which I could use for this. Gonna be interesting 
Hi,
Horizontal awnings can be setup with my custom integration that just has received a major update.
Even the angle perpendicular from the wall can be used to adjust for not perfect horizontal screens.
It also supports additional weather conditions in it’s advanced climate mode.
2 Likes
Thanks a lot!
When I try to add the integration I get the following error:
unsupported operand type(s) for +: ‘NoneType’ and ‘float’
Is that something I can fix? I run HA OS 12.0
That is unfortunate. I happen to notice the release packaged some old versions of some files.
This is fixed now with the v0.3.1 release, that should be available after restarting or updating the info in HACS.
1 Like
I just installed the component and also get an error on the 0.3.1 that is similar but not the same (I was going to open on git but it requires me to debug log this integration and gather a bit more info that I need to restart for, I’ll try to do that some time today):
This error originated from a custom integration.
Logger: custom_components.adaptive_cover
Source: helpers/update_coordinator.py:313
Integration: Adaptive Cover (documentation, issues)
First occurred: 7:04:23 AM (7 occurrences)
Last logged: 7:05:16 AM
Unexpected error fetching adaptive_cover data: cannot convert float infinity to integer
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 313, in _async_refresh
self.data = await self._async_update_data()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/adaptive_cover/coordinator.py", line 142, in _async_update_data
default_state = round(NormalCoverState(cover_data).get_state())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/adaptive_cover/calculation.py", line 129, in get_state
self.cover.calculate_percentage(),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/adaptive_cover/calculation.py", line 335, in calculate_percentage
return round(result)
^^^^^^^^^^^^^
OverflowError: cannot convert float infinity to integer
Looking at the code it probably has to do with the fact that I set my awning to 0 since I have no awning. I used the soffit on my roof for my awning and the error went away, it’s not really an awning but I suppose it could be treated as such.
That would indeed not work. The code assumes that the position of the horizontal plane is adjustable and therefore doesn’t account for a static plane like a soffit.
If the size is 0, the position becomes infinitely large to block out any sunlight which can raise that problem in python if you want to round it. In a next update I will add a minimal length to overcome the 0 length problem.
1 Like
There is also some sort of error 42 here - sorry. When I enabled developer mode on my Somfy control unit, then it suddenly appears offline, and I can’t get it back online. So I guess it will take a while before my awnings gets automated 