Hi everyone,
I’m wondering if it is possible to template a sensor which is calculating a duration in hh:mm between two elevation points based on sun.elevation.
What i’m trying to get, is the hours/mins between when the sun rises above 24 degress in the morning and when its going below 24 degrees elevation in the evening.
Has anyone an an idea?
Thanks a lot.
if you want to get the info for yesterday that would possible.
but if you want it for tomorrow then you can’t since HA doesn’t have that data in any sensors.
Ah, thank you.
I was under the impression, that this a value that is computed like next.sunset.
This data is available in the morning, despite it hasn’t happened yet?
I would like that for the actual day, quite the same like with “hours of daylight today” but only based on sun.elevations.
PS: how would i template such a sensor (for yesterday?)
You’d need to set up two template-based trigger sensors:
template:
- trigger:
- platform: numeric_state
entity_id: sun.sun
attribute: elevation
above: 24
sensor:
- name: "Sun above 24 deg"
state: "{{ now() }}"
- trigger:
- platform: numeric_state
entity_id: sun.sun
attribute: elevation
below: 24
sensor:
- name: "Sun time above 24 deg"
state: >
{% set t = now()|as_timestamp - states('sensor.sun_above_24_deg')|as_timestamp %}
{% set h = (t/3600)|int %}
{% set m = ((t-(h*3600))/60)|int %}
{{ "%02d"|format(h) }}:{{ "%02d"|format(m) }}
Untested, but that should give you an hh:mm-formatted string between the sun going above 24° and dropping below it again. Results will be undefined until an up-down cycle is complete, and if you live far enough north/south for the sun to fail to breach 24° elevation on any day, all bets are off. The previous day’s value should be reasonably close to the subsequent day.
The first trigger simply records the time when the sun’s elevation crosses from below to above 24°; the second triggers when the sun drops below 24° again and records the elapsed time from the previous trigger, with some formatting to turn seconds into hh:mm.
Is the goal to predict what the time difference will be for the current day or to report what it was?
In other words, do you want that value calculated at the start of each new day, reporting what the time difference will be, or do you want the value calculated after the sun has already decreased to 24 degrees in the evening? The first predicts the time, the second reports it after it has happened.
The ideal case would be that:
OK, that’s what I thought; you want it to predict the time difference for the current day.
The challenge here is that there is no existing template function that can report the time when the sun will be X degrees above the horizon. It would have to be calculated from scratch using appropriate equations.
Thank you very much!
I will try this. Even when it is for yesterday’s data, it will give me an good enough value for today, as two seusequent days differ only about 4 mins in length at my location…
I guess your requirement for predicting today’s time was fairly flexible. 
Just tried it using NOAA’s calculator. For London, yesterday’s duration above 24 degrees was 3m 10s shorter than today’s, and we’re at a relatively quickly-changing part of the year.
Yeah, it would be sooo much easier if only HA had a sensor type to predict future events (like: when_do_i_win_the_lottery), wouldn’t it? 
I’m interested in the mentioned data (not the lottery, i mean the “solar_powering_daylight_length”), but not enough to do something from scratch (at the moment this is beyound my astronomical knowledge).
So i will try to live with yesterdays data (i.e “you didn’t win the lottery”) 
Thank you for your thoughts!
Now where have I heard that before…? 
They were indeed.
Within an accuracy of 5 mins i’m happy.
As @Troon says there are calculations available (I also use the NOAA ones) but getting that into a Jinja2 template requires all sorts of dubious trigonometric functions. It also eveluates for a time, so you’d need to iterate through the day. The sun component does exactly this to ascertain when critical elevation ‘landmarks’ occur. So you’d be better processing this as a side task in python or something.
I did a spreadsheet for these sorts of calcs and it takes about 6 minutes to run through a full year.
This is a sample for Madrid : -
Capturing the transitions the day before, and re-using them the following day is MUCH easier (but wrong as noted by yourself)
No, i was just curious about the length of daylight when the light is sufficient to REALLY power the panels (meaning 500W up to 8kW). The panels work as soon as there is daylight, but we speak about 20 to 500 Watts here.
Yes, that’s what i gonna try (Thanks to @Troon).
It’s okay with me (knowing to add/substract some minutes for the actual day).
As i said, it’s more out of curiosity and perhaps to see and compare the output of the panels in spring/summer and "power"daylight length in comparison to outside temperatures (i.e efficiency of the panels).
But a big thank you for your efforts! It still amazes me, how much one can learn from asking questions and listening to the people that are willing to give answers
So for today i learned: no future predictory sensors in HA (so far) and there are days in London (i’m in Berlin, but that’s about the same regarding the sun, minus the fog 
), where the sun never rises above 24 degrees!
Well, 90 - 24 - 23.436 = 42.564°
so any latitude beyond 42.564° will have at least 1 day a year when that doesn’t happen
[corrected]
90 = perpendicular solar axis
24 = desired elevation
23.436 = variations (tropic of cancer and capricorn) introduced by axial tilt
No, we didn’t say that, we said that ‘elevation’ is calculated from a ‘time’ (UTC)
Every ‘landmark’ (solar attribute value), elevation in this case. Has to be calculated either by linear iteration or using binary division - Both are complicated algorithms (Hell, just the positional calculation is difficult. You can’t work ‘back from a position’, you have to ‘guess’ a time, get the result and then adjust your ‘guessed time’ according to your error)
The sun.sun component does just this for solar noon/midnight, dusk/dawn, sunrise/sunset but that’s it.
It’s calculated just after the last occurance of each for the next occurance of each.
There is a sun2 component developed by @pnbruckner that gives you more but 24° elevation is a bit arbitrary - everybody would want something different.
As an example I ran the elevation calcs with a target of 24° elevation from a fictitious place 0° longitude and 42.564° latitude (-42.564° would be very similar but I’m less familiar with a southern hemisphere analema) note how the times ‘bounce’ on the winter solstice (Dec 21)
Same numbers but southern hemishere : - just what you’d expect really
Sorry, i just was kiddin’ around (nodding to the “when_will_i_win_the_lottery”-sensor).
Your explanations regarding this matter are very enlightening. I’m intrigued to dive into this a bit.
(Damn. i just woke up this morning and wanted to now, how long the “solarpowering” daylight lasts at my location 
)
I don’t see the connection between predicting the sun’s elevation and a lottery; one can be computed, the other cannot (unless it’s a rigged lottery). Equations do exist for computing the time when the sun’s elevation will be X degrees at a given location on the Earth (or other planets and moons). It’s just that those equations don’t exist as a handy function in Home Assistant.
Given that you don’t mind if the result’s accuracy is off by a few minutes, Troon’s example is probably the easiest way to compute it using what is currently available. If you wish, you can reduce the template to this:
state: >
{% set t = now().timestamp() - states('sensor.sun_above_24_deg')|as_timestamp %}
{{ t | timestamp_custom('%H:%M', false) }}
Sorry, of course you are absolutely right! I just was oversimplifying this “what happens in the future” thing and mixing things that doesn’t have to be mixed.
Just had a long work day and wanted to add something “lighter” to perhaps smile about.
Will do. Thank you.
I’d be very interested to see such a calculation, [As a hobby] I do shading for windows given certain bounding criteria, designs for sundials (both horizontal and vertical) and have never come across such. Indeed, when I asked Phil how he calculated such, he suggested the iterative methods.
Though an Electrical Engineer I have been asked professionally to do weir flow & height calculations (one way calcs) and similarly submerged venturi (drowned orifice) calculations (again one way)
The above would save me considerable headaches.