I’ve tried the Sun2, it give results in hours, not the time. So that is a problem.
Next_rising and next_setting still shows appr. 2 minutes too late (GMT+1, central europe, Slovenia,)
Close. sun2 uses the same package that sun.sun, and other sun related items in HA, use, specifically astral. I should know because I’m the author of sun2. If the data is wrong, then you need to take it up with the authors of the astral package. 
Yes, HA’s location elevation is entered in Settings → System → General, in the Elevation field. The elevation can change the results, but probably very slightly, like maybe seconds, or fractions thereof. I haven’t tested to see. I’ve always just set my elevation correctly.
First, zones do not have an elevation parameter, only latitude, longitude & radius. For HA’s built-in sun related calculations, only HA’s main location configuration matters. That’s the elevation already mentioned, and latitude & longitude, which are set (via the GUI) in Settings → Areas & Zones → Zones → Home.
Yes, sun2 allows to configure one or more locations (latitude, longitude & elevation), but uses HA’s config values (discussed above) by default.
Exactly!
The differences may be partly due to slightly different values for latitude, longitude and/or elevation. But it’s also possible that the algorithms used in the astral package may, just by their nature, return slightly different results than what some weather service uses. Let’s hope a weather service, with their super computers, can do a better job of calculating these values (for a particular, given spot on the globe) than some python package running on potentially very slow home computers. 
I’m not sure what you mean. By default, in the GUI, yes, it does show such and such hours before or ago. That’s how any entity with a device_class of timestamp is shown. That’s a GUI thing, not the entity itself. It’s state is a datetime in UTC (converted to a string, of course), and its yesterday, today & tomorrow attributes are python datetime objects in the local time zone:
1 Like
So here is another issue, the elevation shown in the sun.sun is wrong.
It shows 15.26m for my location
Now my elevation is 192 m or 629.9213 ft
Can I over write that value in the state?
That’s the elevation of the sun, not you. It’s in degrees, not meters. If you monitor it over time, you’ll see it will change as the sun rises and falls.
Thanks a lot for this detailed explanation!
1 Like
Hello all!
Since the above discussion took place, I’ve learned something about the elevation value used as input to sun & sun2, so some of my related statements above are not entirely correct.
It turns out the astral package (that both integrations use) requires the “observer’s elevation above ground level at the specified location”.
However, HA describes the elevation general system option as “Altitude above sea level in meters. Impacts sunrise data.”
I never questioned HA’s definition of this value and just assumed it was correct. After all, it had been this way for years. However, after getting much feedback that the sunrise/sunset values (and others) from sun2 (& sun) were a bit off, and noticing it myself for quite some time, I finally decided to look into it.
It is explained in more detail here, but as I said above, the elevation should be the observer’s elevation above ground level, not sea level. In most cases I would think the correct value is zero (or maybe 1 or 2 m to account for how tall you are. 
)
I changed the elevation in my system to zero and sun & sun2 started returning values that agreed with many other sources (weather apps, etc.)!
Note, though, that other integrations besides sun & sun2 use the elevation general system option and may require it to be altitude above sea level as HA defines it. I haven’t looked at them all, but at least one seems to be this way, which is met.no. Fortunately, that integration saves a copy of that value in its config entry, and can be changed independently via its CONFIGURE button. Not sure about any others.
2 Likes
Well that’s weird, because I have my HA elevation set to 115m.
The sun.sun integration says the sun will rise at 06:47:01 tomorrow.
The Australian Bureau of Meteorology integration says 06:47… oh wait I have the same elevation specified in that integration. 
Their mobile app (using my current location) says 6:50.
So after changing my elevation to 0 and restarting sun.sun says 06:49. Which is closer.
Time for a documentation PR?
I would have done that myself if the situation wasn’t as complicated as it may be. Like I mentioned, other integrations use this value, and some may require altitude above sea level (e.g., like met.no seems to.)
Probably requires an issue created, but I’m not up to that task.
Sounds like a good old fashioned CF
1 Like
Dear sun2- und sun-development-team,
thank you very much for all your effort. I do make a lot of use from sun.next_rising.
I’m rather sure that the “elevation” field should not be taken into consideration for sunrise & co time determination.
At my place this makes the timestamps about 3 minutes off.
But… as @pnbruckner mentioned, other add-ons/integrations use the elevation value. I’ve double checked with met.no - they do use the elevation for calculation. So is there any way to either have a second elevation value for sun.sun (“elevation difference to ground from the specified coordinates”) or not take it into account at all.
Or maybe you do have an even better solution?
I’m running 2024.3.3 and the problem still exists.
Kind regards
I use met.no myself and they do use the elevation, but it is not the elevation from sea level, but the elevation of things around you that delay the sunrise, but this might also be what you meant. It is just a bit hard to figure out from the context.
Elevation definitely should be taken into account when calculating sunrise, sunset & related values. It’s the definition & usage of HA’s System Setting that is in question.
FWIW, my Sun2 integration no longer uses that elevation value. See this doc page for details.
1 Like
Hello dear @pnbruckner,
thanks for the reply, you’re absolutely right - the elevation should be taken into account - but in a usable way ;).
Since other add-ons might use the elevation as the “elevation above sea level” and not “elevation above ground on the home coordinates”, I cannot decide what is the better solution for me right now.
Your sun2-documentation is perfectly clear, thanks for that.
Thanks and have a good day.
Well, neither elevation above sea level or elevation above ground is correct here.
It is the elevation of obstacles around you that alter you horizon.
That doesn’t make much sense though. A 10 meter wall just next to you covers your horizon much more than a 2000 mountain that’s several kms from you. Not too mention the mountain may only be in the way of sun for party of the year. How would that work with just one value?
Besides, the examples in this thread show later sunset with higher entered elevation value.
Read the links that are in the thread.
And yes it is a bit confusing and I hope I got it somewhat right here.
Otherwise please correct me.
If you are standing somewhere and you are 100m above sea level and everything in the horizon where the sun rise are also 100m above sea level, then the equation works.
But if there is a mountain or a highrise where the sun rise, which makes that obstacle higher than 100m above sea level, then it does not work anymore.
You are on a circle from the center of earth that are sea level + 100m, but the horizon is sea level + 100m + the height of that obstacle.
That means the circle you should be on to be on level with the horizon is sea level + 100m + the height of the obstacle, so in fact you are below the horizon and there need to set the height value lower.
The value you have to set it lower will not be equal to the height of the obstacle, but lower.
This is because we are on a sphere and the further away the obstacle is the more of it will actually be below your horizon line.
Hi @Fanful: In my case the sunrise time (sun.sun attribute next_rising) that the sun-integration reports is too early (about 3 mins) because of “elevation” 540 meters.
It should be 05:07:02 but sun.sun thinks it will be 05:03:51 because of the 540 meters elevation that I entered, thinking it will be the “above sea level” value.
What I have learned from here is that the elevation field is somewhat misleading respective has no good description to what it means.
Obviously obstacles will affect when the sun can still reach you or not. I’m not disputing that. But it’s not something that can be adjusted with a one single value and I don’t think the elevation value in HA is meant for that, at all.
Also in reality the Earth is not a perfect sphere (or even ellipsoid). So, in fact, 100 m above the sea level doesn’t mean the same distance to the center of Earth everywhere.
Yes, exactly because it turned out sun.sun already takes into account the elevation of the specified geographic location and then incorrectly applied the elevation from settings, on top of it. At least if what was written in this thread was correct. This means that to get precise results you would have to set elevation to 0.
The elevation value in HA is not meant for that, but that is how the astral library used in the sun integration is using it, so that is the problem.
Setting the elevation to zero will give you the time the sun will hit the ground at where you location is set. (the upper sun in my picture below)
If you are a tall person, then the sun will hit you before, so you sunrise is earlier (the lower sun in my picture below)
I know it is not the sun that is moving in space, but that is an illustration of how we see the sun move.
The taller you are the higher the elevation value in the sun integration have to be.
As you said the world is not a perfect sphere.
So here is a mountain now.
Normally your sunrise would be the lower sun, but the mountain is an obstacle that blocks that.
You sunrise will therefore be much later at the upper sun.
Your personal elevation have not changed only the surroundings.
You could make a tangent line to the perfect sphere in that picture and then you can see that in order to get the top of your purple stick “figure” down to that line, then you will have to lower your elevation value.
The mountain is quite tall, but because the sphere is round and it is somewhat distant, then you do not have its entire height blocking the sunrise, only a smaller part.