Calculate hours between sun.elevation values possible?

123 · April 27, 2021, 5:41pm

They’re typically available as part of a python module which, unfortunately, cannot be imported into Home Assistant’s python_script (but you can if you use pyscript). Here’s one that simply relies on the math module (calculates elevation for a given time):

Python Sun Position for Solar Energy and Research

As for converting it into Jinja2, the calculations employ sin, asin, cos, atan2 which all exist in Home Assistant’s implementation of Jinja2. It does use rad, to convert degrees to radians, which isn’t available and would have to be computed “long hand”.

Mutt · April 27, 2021, 5:45pm

Long hand is easy X/Pi*180 etc.
But those calculations are the ones used by NOAA and therefore calculate ‘position’ from ‘time’

123 · April 27, 2021, 5:48pm

I wish I had enough time and interest to search the internet for the desired equation implemented in simple python so that it can be easily converted into Home Assistant’s Jinja2 …

But seriously, they’re out there in modules … which makes them inaccessible to Jinja2 or python_script.

petro · April 27, 2021, 7:34pm

@pnbruckner’s sun2 integration makes this calculation already for the current day.

123 · April 27, 2021, 7:42pm

Maybe I missed it but it doesn’t appear to have the ability to report the time when the sun is at a specified elevation (like the OP’s requested 24 degrees). The closest it comes to that is to allow one to specify an elevation for the purpose of enabling an binary_sensor when the sun attains that elevation.

I imagine the integration has all the necessary equations to provide “time at X degrees”, but it hasn’t exposed it to the user.

petro · April 27, 2021, 7:45pm

you can get that by using the binary_sensor portion, setting the elevation to 24. Won’t give to the time as a TS but it’ll have the on/off for that.

123 · April 27, 2021, 7:49pm

Isn’t that effectively what Troon’s example does using Trigger-based Template Sensors? It computes the difference between the two times after the second one has occurred.

petro · April 27, 2021, 7:50pm

It’ll be more accurate, but yes… it’s pretty much the same.

petro · April 27, 2021, 7:53pm

I do want to point out that one of the length of time sensors probably gives what OP is looking for without needing the angle.

Troon · April 27, 2021, 7:53pm

A way to reduce this further would be to also store the day before yesterday’s times, then adjust today’s estimate by the same amount as the previous difference.

So d0 = d1 + (d1 - d2).

123 · April 27, 2021, 8:01pm

I think the OP is looking for the period of maximum sunlight intensity from 24 to 24 degrees elevation. Closest length-of-time attribute the sun2 component has is daylight and that’s kind of far off because it’s from ~1 degree to ~1 degree.

petro · April 27, 2021, 8:02pm

astronomical_daylight is 18º to 18º, that ~~might be~~ is negative though

123 · April 27, 2021, 8:05pm

Astronomical dawn/dusk is 18 degrees below the horizon (maximum dark-sky). OP wants 24 to 24 above the horizon.

petro · April 27, 2021, 8:05pm

Yes, did you see my edits about 2 minutes ago?

123 · April 27, 2021, 8:07pm

I did after composing and submitting the post when the browser updated …

cpo · April 27, 2021, 8:26pm

You’re right about that. I surely underestimated the whole thing, when asking this question!

@Troon This is a marvelous idea! I think this is getting me as close as it could with a reasonable (at least for me) amount of code.

pnbruckner · April 28, 2021, 1:42pm

If you want to try a quick test, to see if this gives you the information you’re interested in, you could install my sun2 integration, and in this line:

github.com

pnbruckner/ha-sun2/blob/d466778d68aae71afae948efe7c811e893ddd27c/custom_components/sun2/sensor.py#L158


        return str(timedelta(hours=hours)).split('.')[0]
    except TypeError:
        return None


class Sun2PeriodOfTimeSensor(Sun2Sensor):
    """Sun2 Period of Time Sensor."""

    def __init__(self, hass, sensor_type, icon):
        """Initialize sensor."""
        super().__init__(hass, sensor_type, icon, 0.833)

    @property
    def unit_of_measurement(self):
        """Return the unit of measurement."""
        return 'hr'

    def _device_state_attributes(self):
        data = super()._device_state_attributes()
        data.update({
            'yesterday_hms': _hours_to_hms(data['yesterday']),

change the 0.833 to 24. Then configure the daylight sensor. It should give you the amount of time the sun is above 24 degrees for the day (and for yesterday and tomorrow. You could even configure the night sensor to give you the amount of time the sun will be below 24 degrees.)

I’m not sure, though, that it’s worth it to make this integration more flexible to accept an arbitrary number (kind of like can be done for binary sensors.) This is the only time I’ve heard anyone ask for something like this. But if a case can be made for adding this feature, I might spend some time on it.

Mutt · April 28, 2021, 5:46pm

Taras, I’ve studied this subject in detail and never seen of such, the thing I’ve ‘heard’ of it is your series of posts in this thread. For me to accept this without proof is akin to saying “Yeah drink this bleach and swallow this UV light bulb and lead, then we’ll turn to light on to cure your Covid-19” - It’s just not happening.

Just think about this for a moment.
At ANY time there are many points on the Earth where the sun is at a given elevation (-90° to +90°). Though for the two extremes there’s only one of each and they are antipodian.
But lets assume we are only interested in a ‘given point’ and only with a given elevation.
The ‘ring’ that the elevation generates forms a cone around the ‘given point’ and we must find where the path of the sun intersects with that cone.
So we need to know where the sun is and that it is on the cone and we can note the time.
For that to happen we need to know exactly where the sun is and that is dependent upon time.
The calculations for the sun position (including the ones you linked to) run something like this : -
From the time and date (UTC) we generate the Julian time and the Julian century.
From that we can calculate the Geometric Mean Long Sun Degree
AND we can calculate the Geometric Mean Anom Sun Degree (they are different)
Using the Julian century we can calculate the ecentricity of the sun’s orbit
From Julian century and Geometric Mean Anom Sun Degree we can calculate the Sun’s Equation of Centre.
From Geometric Mean Long Sun Degree and Sun’s Equation of Centre we can calculate the Sun True Long Degree

The list continues, here’s just the titles of the factors that can be derived from time that combine to interact to the positional result : -

Date
Time (past local midnight)
Julian Day
Julian Century
Geom Mean Long Sun (deg)
Geom Mean Anom Sun (deg)
Eccent Earth Orbit
Sun Eq of Ctr
Sun True Long (deg)
Sun True Anom (deg)
Sun Rad Vector (AUs)
Sun App Long (deg)
Mean Obliq Ecliptic (deg)
Obliq Corr (deg)
Sun Rt Ascen (deg)
Sun Declin (deg)
var y
Eq of Time (minutes)
HA Sunrise (deg)
Solar Noon (LST)
Sunrise Time (LST)
Sunset Time (LST)
Sunlight Duration (minutes)
True Solar Time (min)
Hour Angle (deg)
Solar Zenith Angle (deg)
Solar Elevation Angle (deg)
Approx Atmospheric Refraction (deg)
Solar Elevation corrected for atm refraction (deg)
Solar Azimuth Angle (deg cw from N)

Given that the target elevation is 24° the you ‘can’ completely ignore Atmospheric Refraction but Assuming you start at the end and work backwards, you have to use factors that you derive from time and there is no way to get round that.

You can not get an ‘equation’ that gives you time from a ‘position’ and an elevation, the best you can do is an algorythm using a series of ‘guessed’ times
The module that Phil is using ~~below~~ above does just this (as previously explained).

Do not make statements that go against accepted scientific knowledge without proof and you have provided - NO PROOF.

123 · April 28, 2021, 6:41pm

Your Gish Gallop has failed to suck me into debating the semantics of the definition of the word “equations”. If you thought I meant there’s a straightforward algebraic equation available, I didn’t.

There are existing “mathematical tools” for computing what the OP requested (which is the sum-total of my assertion). Most are in formats that are unavailable for templating or python_script due to aforementioned limitations.

Fun Fact: they scheduled the first moon landing at a time when the landing zone would experience long shadows (to avoid flat lighting and provide the most striking terrain-relief); it speaks volumes about what is understood and calculable (even off-earth).

123 · April 29, 2021, 1:35am

I found a few spare minutes to explore the astral package and found this:

astral.sun. time_at_elevation (observer: astral.Observer, elevation: float, date: Optional[datetime.date] = None, direction: astral.SunDirection = <SunDirection.RISING: 1>, tzinfo: Union[str, datetime.tzinfo] = ) → datetime.datetime

Calculates the time when the sun is at the specified elevation on the specified date.

Note

This method uses positive elevations for those above the horizon.

Elevations greater than 90 degrees are converted to a setting sun i.e. an elevation of 110 will calculate a setting sun at 70 degrees.

Parameters: * elevation – Elevation of the sun in degrees above the horizon to calculate for.

observer – Observer to calculate for

date – Date to calculate for. Default is today’s date in the timezone tzinfo.

direction – Determines whether the calculated time is for the sun rising or setting. Use SunDirection.RISING or SunDirection.SETTING. Default is rising.

tzinfo – Timezone to return times in. Default is UTC.

Returns: Date and time at which the sun is at the specified elevation.

There are probably other astronomical modules/libraries/packages that can do the same thing (and in many other programming languages) but I looked at astral because it’s what Home Assistant uses (in integrations like sun and, unless I’m mistaken, pnbruckner’s sun2).