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.
I know this is a bit old but what I would rather do then triggering the automation every few minutes is having the altitude and the azimuth both as triggers and conditions.
This was you cover both scenarios @checking12 described so well. Both times will trigger and both times it will check for the other variable. Only if both match, it will actually trigger the automation.
And in the other times if the year where this does not happen, it won’t run because not both conditions apply.
I think it should be cut in 2 automations, the scheduled trigger is one I’m also not in favor of.
eg. One of the automations is disabled by default and the other one enables that automation when a first trigger happened.
So you’ll have a ‘altiftude triggered automation’ and a ‘azimuth triggered automation’. The latter will be at disabled state and the first will enable that one as soon as its triggered. So then the azimuth can just nicely trigger at right moment.
At night or what ever timing, you distable the ‘azimuth automation’ again.
Hopefully rounding off this series of necroposts, much easier (as is often the case) to follow Taras’s advice from earlier, and create a template binary sensor for when the sun is in the zone. This can now be done in the UI (Helpers, Template) with a state template of (for this example):
Currently I use manual entered helpers for the time to change state of the blinds.
I’d like to change to use elevation and/or azimuth, but I don’t like the idea that it is triggered somewhen and noone is aware when that would be. And home assistant continuously checking where the sun currently is, as if that would change surprisingly.
My idea is to calculate the time the sun will reach some elevation/azimuth (maybe maximum time of both conditions, am not sure by now). This value is the helper which I can show in some dashboard so that everyone can see in the morning when the blinds will go down (if the weather forecast for the day is sunny or the predicted max temperature is too hot). And maybe change that time (as it is the helper value) if that is wanted, maybe one would like to use sunlight some minutes longer.
This way the trigger for the blinds isn’t checked more than once. It is a fixed time. At midnight the time gets calculated and it isn’t continuously checked if some condition is fulfilled which will happen at a given time for sure.
Is that calculation (what is the time the sun reaches some value for azimuth/elevation) available using sun.sun already?
Edit: The discussion about this topic exists. Maybe sun2 helps, and the python package astral being used by Home Assistant provides a function for sun at elevation. It is not that exact, but for the blinds it will do.
