Next_rising and next_setting still shows appr. 2 minutes too late (GMT+1, central europe, Slovenia,)

Configuration
21

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. :smile: )

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
22

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. :man_facepalming:

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?

23

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.

24

Sounds like a good old fashioned CF

1 Like
25

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

26

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.

27

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
28

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.

29

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.

30

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.

31

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.

32

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.

33

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.

34

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.

35

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.

perfect sphere
perfect sphere2304×1296 88.6 KB

As you said the world is not a perfect sphere.
So here is a mountain now.

imperfect sphere
imperfect sphere2304×1296 75.2 KB

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.

36

You misunderstood me. Even excluding terrain elevation, Earth is not a perfect sphere. Meaning the sea level is not the same distance to the center of the Earth everywhere.

And if course mountain close to you affects when the sun can reach you. But a mountain to the north will have no effect, mountain to the east will have an effect for sunrise, but not sunset and so on. How do you suggest a single setting of elevation would help mitigate this?

37

I did not misunderstand you.
The elevation above sea level or ground have no relevance here.
It is an elevation relative to the ground on that particular spot.

And the obstacle have to be on the horizon blocking the sunrise.
Mountains to the north have no effects.

I have no clue how a single value should handle both sunrise and sunset, but that is how the astral library works.

38

But what exactly is “ground level” depends on what I mentioned, that’s why it matters. Though I would expect the difference isn’t really meaningful in most cases.

Except when you calculate sunset. And the direction of sunset (and sunrise) changes a lot during the year (at least far from equator). So the same mountain could be in the way in January, but not in June. But ok, I give up on this discussion.

39

While I do appreciate the scientific discussions and the drive for perfectionism, these discussions always puzzle me. The former Product Manager and Business Analist in me always immediately starts asking the questions: What is it your end goal: the thing that you are trying to accomplish, and how accurate does the solution need to be to fulfill the goal?

If the goal is to determine do something about the brightness of the sun at some point in your home, would a lux sensor not fulfill that goal better? It will compensate for the elevation of your home, the floor you are on (inside even for the window positions), the varying hight of mountains and other objects around you, the weather conditions, the relative size of the sun (depending on how far away it is from your home), the angle at which the sun rises to go from totally hidden to fully exposed, solar eclipses, Elephants standing on the mountains in the wrong spot at the wrong time and what not.

Also, is the two minutes difference that much of a deal for the automation you are building, or is the value you are comparing to even right, or accurate enough, in the first place? My initial thought would be the sun and sun2, even with wrong elevations, will work out just fine if accuracy does not need to be to the second. I do use sun2 (it is great) but I do not really care if it is a couple of minutes off. My automation would probably have a small margin built in anyway for good measure.

40

There is not really much discussion, because it is dictated by the astral library and I agree with you.
It is not perfect!

Sun2 is just better than Sun now, because you actually have a chance to make some corrections when using Sun2, because it is detached from the elevation value in the HA settings.
If you are using Sun, then you need to correct you elevation value in the HA setting, but that might change other things too, like GPS values, weather forecasts and so on.