Good morning, all. The dang sun is killing my eyes here in the window between certain morning times since my monitor faces the window. Finally, I decided to look into it. I used suncalc.org to ascertain that I should close the shades at azimuth 120.50 and re-open them at 137.50. However, I only see trigger options based upon elevation.
I reviewed sun triggers and only see elevation as an option. I see that using the ESRL link for elevation calculation we’re looking at 17.33 to close and 29.84 to reopen.
automation:
- alias: "blinding sun so close the shade"
trigger:
- platform: numeric_state
entity_id: sun.sun
attribute: elevation
below: 29.84
above: 17.33
I’m curious if there’s a best practices to blend these two so that it’s based upon certain times of the year where the sun is at a certain place in the sky? I don’t see anything about adding azimuth values to triggers or conditions.
Thanks! Okay, so this is what I came up with. Any errors spotted? I’m kind of lost as to whether to use azimuth or elevation as the trigger vs. condition.
Well, think of the angles it enters your window. Azimuth is the horizontal component, elevation the vertical. Elevation point changes during the year, so trigger moment would move during the year. Azimuth will determine more fixed moment when sun could come around the corner.
Yeah I’m a fool as I can’t envision it. Certain times of the year this is a problem (fall and spring in the last couple of weeks before or after daylight/standard time changes). Essentially, in my bad mind, it may not matter which is the trigger vs. condition since they both have to be true to encompass the problematic result? I considered an additional condition of 0900 to 1015 which would narrow down the time where it occurs as well. Happy for suggestions to be as accurate as possible.
Create a Template Binary Sensor whose template computes when the sun enters and exits the desired “zone” (the position in the sky identified by elevation and azimuth). When it enters the zone it reports on and when it exits the zone it reports off.
Your automation can use a State Trigger to monitor the Template Binary Sensor when it changes state from off to on.
The first step is to identify the coordinates of the desired “zone”.
no , dont worry. It’s just one of those things. Had time to play with it before, same problem. the elevation of 17 for example could happen in summer way before azimtuh =120 (lets say 100). Then condition azimuth 120 would prevent fromt triggering.
BUT when azimuth increases, elevation increases and sun would enter your window area, automation wouldnt run.
So if you turn it around azimuth reaches 120 and elevation just 16.9, it would also not trigger. And few minutes later, sun enters your window again.
In the end, you have 2 areas that need to overlap to get this working. This is in line with Taras approach.
Other solution would be a time trigger and put both as condition. So between 900AM and 1030, trigger every x minutes (what ever you deem usefull) and have azimtuth and elevation as condition. Then both conditions need to be true and you have the feature you;re looking for.
Thank you both for the insight. I’ll play around and see. Maybe get @checking12 solution going first and then go onto @123 solution.
Templates are so far beyond my knowledge it isn’t even funny; but I’ll Google and read on them as well as I can see where it is more efficient maybe to do that.
I thought that the default is “or” on conditions so I defined it with the “and.” Apparently, “or” is default for triggers and “and” is default for conditions. Damn I did so many with “and.”
Shitttttt. I missed condition: to start it. Lord. What a horrible round this was.
