Yes, good call.
The Sun component actually seems to be buggy. It doesn’t actually switch to “Below horizon”. I watched it closely around the sunset time. There was a countdown to the sunset, but it never switched to “below horizon” after it ran out - see the screenshot. The state of the Sun entity is still “above horizon” now, 10 minutes in. Location in Settings-General is set correctly, time of sunset was correct too.
Maybe that’s why my original setup didn’t work. I’ve redone it with “elevation < 0” as per @qoheleth, which works as expected.
Which version of Home Assistant are you using? Is it the latest one (2021.6.0)? Sorry. You specified the version in your first post.
I just switched from 2021.5.5 to 2021.6.0. I employ below_horizon in an automation’s condition and it has worked correctly in all versions (including 2021.5.X).
condition: "{{ is_state('sun.sun', 'below_horizon') }}"
The behavior you’ve reported is unusual. This evening I’ll check sun.sun in the UI and see what it reports (but I suspect it will say “Below horizon”).
UPDATE
The sun has set here and Home Assistant reports the sun entity is below_horizon (as expected).
Yup, and that’s why most experienced HA users don’t (or rarely) use it.
It eventually switched to below zero but there was like a 15m delay. The automation I originally wanted works great with “do when sun elevation < 0”
Thanks all.
I’m not sure where the 15 minutes comes from. The sun moves, on average, 15 degrees per hour so in 15 minutes it would move just less than 4 degrees or, put another way, the sun moves about 1 degree every 4 minutes.
Since the sun covers about 0.5 degrees of arc, the time it takes for it to “move” from center to edge then would only be about 2 minutes.
Anyone else have an idea why the sun.sun would be running 15 minutes late?
There must a missing clue here because it makes no sense that it works with “do when sun elevation < 0” but not with “do when below_horizon”. The two values represent an attribute and the state of the same entity (sun.sun). What Stoovie has reported implies the two values can be out of sync by as much as 15 minutes and that seems implausible. Given that it cannot be reproduced, there must be a missing piece to this puzzle.
Agreed. I’m at a loss to figure out some logical reason.
I think the “sun below zero” and “elevation < 0” work the same way and do work, I just picked the latter as it was suggested first.
The delay was there though, yes. I didn’t time it precisely but I know it was more than 10m. I would think that entities like this that do not work by polling and are pure math (aren’t they?) would update more often.
Also, do you guys have any idea why the second variant from my original post “time condition” always failed as well?
The sun integration does its calculation periodically according to a variable time interval. Around sunset and sunrise, the interval is shorter, meaning it recalculates more frequently. Outside of that, it recalculates less frequently. All this to say that at sunrise/sunset the interval is (normally) nowhere as long as 10-15 minutes.
On a typical system, you can go to Developer Tools > States > sun.sun and watch the changes to its elevation attribute. I would advise doing this around sunrise/sunset when they are more frequent otherwise you may have to wait more than a minute or two.
Anyway, because I can’t replicate the problem you are experiencing, and have no idea why you are getting this anomalous behavior, I’m in no position to offer any more advice. Good luck.
1 Like
I know this is an old topic but i just had the exact same problem as OP.
And the UX should be changed in the way that it is only possible to choose the working combinations of after and before sunrise and sunset.
Right now you can choose both and you are not able to delete one of the options. you have to use dropdown to switch to an other condition amd back again to delete the options.
I hope you understand what I mean.
otherwise i could provide an screeenshot.
i will try it now with an OR condition and 2 sun conditions for night time.