But more importantly, can anyone explain a use case wherein a 8 minute difference would make a significant impact on reaching the goal of the automation? Because I imagine a house across the street or clouds in the sky might have a more severe impact on sunlight hitting your home than the 8 minutes worth of sun movement mentioned. If you want true accuracy, buy a lux sensor.
1 Like
The problem is people put in feet instead of meters. And if youāre in e.g. Colorado and you put in 6800 as the value, your automatons are off by 13 minutes.
The field in the UI is misleading and does not specify units.
1 Like
But is it stating that it should be elevation above sea level, which is correct for other places, like temperature and weather.
It is just misleading for sun elevation.
HA is wrong here and so are smallfreak.
There is a long thread somewhere on the forum about it and we had to dive into the actual library for the sun calculation and the outcome was that the elevation is the one over the actually ground and not the one over the sea level.
I had the same idea as smallfreak back then, but I was convinced after a rather long decision about it and the diving into the calculations.
The UI is not correct, it should list āobserver elevationā instead of āabove sea levelā. Someone just needs to step up and fix the translation key and phrase in English. All I have been describing in my comments on here and discord, is how the equation in the astral library works. Smallfreak is on some tirade here and github trying to say the calc is wrong and HA is at fault.
Please calm down, take a breath! Nobody wants to attack you or the project.
Iām in no way accusing anybody of anything. Especially not āHA is wrongā. What made you think I was postulating that?
If the library that is used does not get me good enough results for the supplied value, then it might be because the two parties donāt agree about the used parameters or that (untold) assumptions have been made that do not fit the expectations. Everything may be fine within itās own domain, but when it does not match reality in the end, the domains may not overlap enough.
And I already DID say that I will look at the code to find out where the observed discrepancy about āentering elevation does make a big difference in sunrise calculationā and āastral does not even use elevation for calculating Sun positionā (as stated in the Astral docs) comes from. Maybe a misunderstanding in the Astral Doc. I didnāt make that one up, I just cited from their documentation.
If I enter a set of requested values and get a result that does not fit with real observation by a noticeable amount, than there somewhere is something that should be adjusted. This may be anything between āget the values with more precisionā (the entered position might have been wrong, the local horizon is not taken into account, ā¦), āask for other valuesā (clarify their meaning) up to āadjust the calculationā (or use a different library).
āJust ignore the asked value, start with zero and enter arbitrary values until it fitsā is however not the most user friendly solution. Especially if this advice is given in a discussion, far off the application, where most users never will arrive. At least the users should get referred to a āhow do I get the correct entry-values in the correct dimension that will result in a good fit between calculation and realityā right where you would expect it.
The fact that there obviously IS a confusion about the meaning of words and values is enough to see the need to enhance this. Itās nothing personal and does neither discredit you not the wonderful HA that I really loveā¦
Itās good and it might become even better and easier to use, if expectations match the results more closely. Isnāt that the goal we are aiming at?
Itās the iteration āTheory - Experiment - Observation - Verification - start overā that makes Science successful. No pun intended.
1 Like
Lets see, you initial post to me on github was:
That measure would make no sense if you donāt know the elevation above sea level too. Sunrise makes a big difference whether you are at the shore or atop of a mountain in a solar-panel equipped hut. A few meters āabove groundā will not.
And you ignored my response:
But it does, try it yourself and watch it change by minutes.
To me this tells me that you disagree. Compound that with the fact that you ignored my comments here and attempted to use the documentation as proof in your following post.
Iām trying to make it clear that Iām talking in relation to the code with facts, not assumptions. Iāve read and contributed to the code base, I knew exactly where to look for the sun code. I investigated that sun issue a number of years ago, which lead to my comments here and on github.
I am not defending the code, Iām explaining where the issue lies. So my final and parting words are:
If you have issues with the algorithm, take it up with astral. The only change that would occur in HA is a rename of the field in general settings.
This is incorrect. Please see Effect of Elevation from the Astral documentation. Specifically,
If what obscures you at ground level is the horizon and you are at a [sic] elevation above ground level then the times of the sun depends on how far further round the earth you can see due to your elevation (the sun rises earlier and sets later).
As noted, this does not affect calculations for āsolar elevationā. However, it is used for all methods that calculate when a āsolar eventā occurs. Ultimately, sunrise, dawn, etc. call time_of_transit, and shown below is where it uses the āobserver elevationā, which is either a distance above ground level, or a distance to an obstruction paired with the relative height of the obstruction to the observer.
Iām not an astronomer. Iām just the author of the āSun2ā Home Assistant custom integration. My integration, as well as HAās built-in Sun integration, rely on this astral package. I have no idea how it works, just how to use it.