correct. at 25 October the cover should close when azimuth is ~ 143 in my case
I just realized I used the wrong number for the west azimuth in my post above. It should have been 270 not 180. I fixed it.
you don’t need the date. you need the elevation. Which is what your date calculation is giving you.
on Oct 25th the azimuth/elevation coordinates are such that at the azimuth of ~143 degrees the elevation is low/high enough that the sun touches something that you don’t want it to.
since you already have it working doing it the hard way there isn’t any reason to change it but just realize what it’s actually doing.
2 Likes
Exactly! But when you create a template sensor and call it “My Azimuth Sensor”, it actually has become azimuth 
1 Like
I don’t understand, why your cover should close at different azimuths throughout the year, as it will always shine in your room as long as it is within rectangle, no matter the season.
The only explanation I can think of is:
- You are ignoring elevation
- Personal preferences, which are hard to automate
To make things more complicated you should also consider inside temperature and target temperature (you might not want to block the free heating by the sun), cloud cover (no sun, no need to cover) and windspeed for an outside cover.
2 Likes
First I thought so too, because I couldn’t believe that there is no sun in the room today at an azimuth of 143°.
But I found a website on which I was able to roughly reproduce it. Also have a look to Thessaloniki at Google map in 3D view. Almost every house has eaves, awning and balconies, which might matter.
Today, May 20th, azimuth 143°: if your flat is (1) or (2) there is no sun shining through the windows.
A couple of hours later:
May 20th, azimuth 172°:The sun shines approx 80cm into the rooms.
And now at October 25th, azimuth 143°:
Even the neighbours below you will have some sun in the rooms where a balcony is above:
The website of this simulation.
You have to upload your own building model.
ps
Lat 40.65747
Lng 22.92498
1 Like
That’s exactly the case here.
1 Like
Fantastically useful website.
I had to manipulate the model a little to get it to work properly, but it has helped a lot.
1 Like
In the first two pictures the border would be the elevation not the azimuth. You cannot just use the azimuth and leave out the elevation.
If you have additional objects, blocking the sun, you would need additional points, to form a more complex shape then a simple rectangle.
that’s right 
So
In October the cover should close at azimuth 144 and elevation of 29. In May the cover should close at azimuth 173 and elevation 71. Lets assume that these points are the min and max numbers for azimuth and elevation.
How can I adapt these numbers in the below part of the automation?
entity_id: sun.sun
# window left
above: 143
# window right
#below: ???
value_template: "{{ float(states.sun.sun.attributes.azimuth) }}"
- condition: numeric_state
entity_id: sun.sun
# window bottom
above: 29
# window top
#below: ???
value_template: "{{ float(states.sun.sun.attributes.elevation) }}"
Of the first two pictures, only the second is interesting because today the sun reached the living room floor first when at azimuth 173°. The 143° and its elevation doesn’t matter today.
IMO it’s okay how Makis is doing it.
He uses calculated azimuth values for the moment when the sun hits a certain point on a certain day of the year.
He could also calculated the exact time when the sun hits this point at a certain day or the elevation at that point/time of day, it does not matter.
IMO it does not work.
Today this elevation would have been reached at 8:56h and the azimuth at 12:30h.
But the sun striked your room floor at >13:20h
1 Like
That is the part which confused me, but I couldn’t explain. The site you found explains it much better than me, in a trustfully way too
I doubt there is an easy way of doing it.
1 Like
You know…the more I think about this the more I think that using a comparison to the rectangle can’t work. And for the reasons I gave in my explanation post above (without realizing it until now) - the sun doesn’t just shine straight out in front like a flashlight. It shines out in all directions like a point source.
And it’s light path thru the rectangular window will trace an inverted arc (mirroring the trajectory of the sun) as the sun moves thru the sky that gets higher and lower thru the year.
we are trying to model a flat plane (a rectangle) of a window against a spherical trajectory of the sun that is always changing throughout the year. The rectangular model is just to simplistic.
I’m really thinking that @Makis original template is the reasonable solution since it seems to be working for them.
unless of course someone can talk me out of that again. 
It’s conceptual, and, as I said the Sun is not a point, but the idea is there…
It all depends on the reference point inside the house I spoke earlier.
Take:
For the same time, same azimuth, depending on whether P1 or P2 is the reference point, the sun is bothersome or is it not. And THERE is where elevation comes into account.
It’s not a point but it acts as one thru a window or any other aperture.
EDIT:
Actually it is a point. just a REALLY REALLY BIG one. but far away…
I agree, but it works almost perfect here - Germany, N 51° - (and maybe further north) on a “normal” window of 2.4m x 4m, pointing to 199°, with no awning, eases or balcony above and because the largest elevation would be 61.98° at June 21th. The shadow length (the depth the sun beams will get into the room) for an object of 2.4m height, is still 1.25m.
Whereas it might be more complex at N 40° where the shadow is 0,71m and the max. elevation 73°.
So if there is a small ease or a balcony above, there would be no sun in this room, at June 21th.
Yes and this what Makis has done. Assuming both points are bothersome at different times, he calculated the azimuth for them.
He calculated an azimuth at a certain date/time which is equivalent to an evelation at a certain date/time.
In HA he could use either or just use a start date and time and add/subtract a certain amount of minutes to/from it every day.
Nah, geometry speaking a point has no dimension, it can’t be “big” 
1 Like