While not in the FOV the automation should set the position to Default Cover Height.
Solar elevation is already checked in combination with FOV. Tracking is only done if elevation > 0 degrees. This is essentially the same as checking sunrise/sunset.
True. I understood it yesterday evening.
But sometimes (maybe bathroom) you want the cover to close and stay closed.
Edit:
So maybe it would be useful to have a setting for each window (I do one automation / window) with âmax azimuthâ âmin azimuthâ (which should be usually already defined by fov) and additonal the elevation (for maybe a hill like in my situation; I just define it >284° azi and <30° elevation == stop automation) and what it should do outside of that (close cover, open clover, set it to X%).
2 Likes
Yep that was also my idea.
We already discussed it here: Automatic blinds / sunscreen control based on sun platform - #30 by langestefan
I will check tonight if I can implement it.
the openstreet map shows my bei my backyards windows the 316 degress, is this correct?
because my backyard cover doesent move, only one time to 95% open and the whole window was in the sun.
What number is your house and which direction is it pointing?
Just for reference, this is how to measure it, where the red bar is the window:
1 Like
here is a better picture the house number is 21
the front is to the street, there i have covers too, i set there 135* i think it works, but the backyards covers doesnt move.
Thank you for your time and help.
If I understand your picture correctly youâre off by exactly 90 degrees. The azimuth angle is measured perpendicular to the window. Itâs also often called the normal angle of the window.
1 Like
Yep thatâs exactly correct!
*Oh btw you should input an angle in range (0,360) as if it was on a circle. Thatâs an issue with the compass. So your angle of 405 should be 405-360 = 45 degrees @htpc2308
oh okay, thank you for your hint, i will test it tomorrow. Thank you 
A few posts above I had asked if you can template the âdefault_heightâ?
default_height: |
{% if now().strftime('%H%M') <= "18:30" %} 100 {% else %} 0 {% endif %}
this should be no problem because its a automation based on the blueprint or?
Thats the point. If we can add another trigger (like sunrise/sunset) we can close/open windows with the same automation which we use for the sun protection. Underwise we may net multiple automations.
I noticed an issue with the default_height setting in combination with the change_treshhold.
I set the default_height to 100% and the change_treshhold to 15%. Now my cover was opened at 89%. I would expect that the cover opens fully when the sun is out of the window. But because it doesnât fit the threshold it stays at 89% after the sun is out of the window.
I configured now 1 automation with 5 cases.
min/max azimuth each side (on/off on the corners) and last case deactivates everything till 8:00 am.
Iâm new to hassio so ⌠I maybe could combine everything more and currently my automation page is a mess (categories would be great) 
Version 1.0.2 of the blue print is now available via the button!!
-
The threshold cannot prevent to reach the set default height anymore if the threshold is to high relative from the current state to reach the default.
-
It adds a template as default_height to override the default_height set by the slider.
This could be helpful to add conditions to when the blueprint should run or to change the default height based on own preferences.
The outcome of the template should be any value between 0 and 100.
4 Likes
as a idea, its possible in HA to check if a person pressed or switched a button or switch or cover, for example you can say when after 18:00 oclock a person activated or moves the cover than deativate the automation. This code should do this, it reconigze every interaction with a switch or button as a human when its done over a logged in user over the app / UI, or over example a voice command. When for example a automation triggers the switch / button / cover the condition is not true.
condition: and
conditions:
- condition: template
value_template: "{{ trigger.to_state.context.user_id is defined }}"
- condition: template
value_template: "{{ trigger.to_state.context.id != none }}"
- condition: template
value_template: "{{ trigger.to_state.context.parent_id == none }}"
- condition: template
value_template: "{{ trigger.to_state.context.user_id != none }}"
I have seen this before and I get the idea but I donât know if there is an elegant way to integrate it into the blueprint, as it does not listen to triggers for the cover entity. Perhaps @TheFes has an idea.
1 Like
@htpc2308 I like the ideas you give to implement. 
But in my opinion the blueprint I have build based on @langestefan 's code is to have basic functionality based on the sunâs position.
Adding (advanced) options for edge cases makes it harder to setup for others and I donât always have the spare-time to add things and debug them.
I guess itâs better and less cumbersome to add an automation yourself that listens to cover changes and toggles the blueprint automation.
PS; with the newly added default template selector you are able to set conditions when the sun is not in front of the window and change the default to closed instead of fully open.
3 Likes
First, thanks a lot for this great idea and blueprint! It was long awaited, that somebody took a look at this! 
And it seems to work quite well (canât say for the long run, just using it since the day before yesterday).
But, you know there is always a but, please donât bloat that nice blueprint up too much. It is always nice for people to have something that fits perfectly to their needs, but most of the time it is not the best for the product (blueprint) itself. It should be usable for the majority of people. If something is missing, there is always the way to enhance the automation generated from the blueprint, but for the average Joe it only gets more complicated.
Thanks for taking this into account!
PS: Ah, I see you already answered that, thanks a lot!
2 Likes