Use Sun2 instead of the builtin sun sensor.
Edit: Looks like the builtin sun can actually do it here. Maybe it was just the automations that caused issues when the before sunrise and after sunset was used as a trigger. Well, I still stick to Sun2 
Hmm I’m not sure.
I’m wanting to keep it as simple as possible…
All i want is…
If sun down - show time till next rise (with icon)
If sun up - show time until next sun set (with icon)
The original code I had worked fine but just didn’t accommodate for different time zones (BST)
Made an amendment to the original code and just subtracted 60mins off the time…
{% if is_state("sun.sun", "above_horizon") -%}
{{ (as_timestamp(state_attr('sun.sun', 'next_setting')) - as_timestamp(now())-3600) | timestamp_custom('%Hh %Mm %Ss') }}
{%- else -%}
{{ (as_timestamp(state_attr('sun.sun', 'next_rising')) - as_timestamp(now())-3600) | timestamp_custom('%Hh %Mm %Ss') }}
{%- endif %}
You’re going to have the same issue you had with my first post… my second template fixes it. That’s the one you should be using as it will be the most accurate.
1 Like
To be more clear with the warnings I posted, they will all have the caveats that are listed in this thread. It’s how templates work, it’s not the template that’s the problem.
Templates with now in them only update on the minute. Templates also only update when referenced entities update.
All templates posted here, yours, mine, etc will all have the same problems you see. The second template I posted will be the most accurate and will not require extra math when dst changes
1 Like
I have no idea what’s happening here haha…
I have another sensor that is looking at the “above_horizon” which works fine…
As soon as the “sun set time” hits, this sensor triggers (as it controls my lights automations)
But weirdly, when I want the above (which is a similar IF statement) - there’s a little lag before the sensor actually updates.
So at the minute of sunrise/set, this sensor updates instantly…
- platform: template
sensors:
sun_up:
value_template: >-
{{ is_state("sun.sun", "above_horizon") }}
icon_template: >-
{% if is_state("binary_sensor.sun_up", "on") %}
mdi:weather-sunset-up
{% else %}
mdi:weather-sunset-down
{% endif %}
For some weird reason, this appears to have a several minute lag before it updated
{% set t = now() %}
{% set next = [ state_attr('sun.sun', 'next_rising'), state_attr('sun.sun', 'next_setting') ] | map('as_datetime') | reject('none') | sort %}
{% set next = next | reject('<', t) | list | first | default(t) %}
{{ (next - t).seconds | timestamp_custom('%Hh %Mm %Ss', False) }}
I’m assuming its because you don’t realize that it’s the next setting and that doesn’t get calculated until after the current setting happens. Sunsets and sunrises shift by upwards of 3 minutes per day. It’s not lag, it’s the next rise or setting.
But the times update instantly?
As picture above, it was the state (above_horizon) that didn’t update, thus gave wrong output…
Once changed to ignore the state, the next rise did change to the following day/time (13/12/2022 - 08:14), but the sensor only showed the next sunset thus around 24hours.
Sorry, I’m obviously clearly missing something, just threw me off a little when the sensor showed 24hours, then 4 minutes later updated to the actual next rise rather than set.
The times on the attributes are not changing and you’re assuming they are. You’re going to see 20 hours or -4 minutes in the window when the new sunset or sunrise hasn’t been calculated. Your old template and my first template will show -4 minutes. The new one I posted will show 20 hours.
1 Like
Sorry, you can totally ignore me whenever, you’ve already gave me the solution haha…
I’m just trying to wrap my head around it…
The next sun set = 2022-12-13T15:45:24.944105+00:00
So I would expect to see the sensor showing around 5 hours (until that time)
Once passed that time, I would expect the sensor to automatically swap to the “next_rising” which is tomorrows date… (so sensor should show around 18hrs?)
‘2022-12-14T08:15:02.618527+00:00’
What I feel is happening, is once past the “sun set”, the “next_setting” is updated and the sensor pulls that time for a short period (so shows 24 hours for a couple of minutes)
This is what I’m struggling to understand?
The new template simply has this as order of operations. Keep in mind, in this example the sunrise is at 05:41.17.
- now() forces the template to update at 05:41.00.
- Sun rise occurs at 05:41.17. The Template is not updated.
- now() forces the template to update at 05:42:00.
- now() forces the template to update at 05:43:00.
- now() forces the template to update at 05:44:00.
Somewhere between 2 and 5 the new attribute will be caculated and the attribute will be updated which will force a template update.
1 Like
This makes sense now, thanks!
Awkwardly this one works on time (unsure why!) Help with Template Sensor (Hours until Sun Rise/Set) - #20 by 91JJ maybe it’s a little more to do with returning the actual time rather than turning on/off a sensor? (if that makes sense)
Yes, it is. There’s no time in that template, it just works off the sensors state.
1 Like
ahh that is why!
Would it be possible to use that sensor to prompt the time sensor to update?
Either way, it makes sense what’s happening now… Thanks for being so patient
We did that and it was still out of sync… You aren’t understanding that the next sunrise and sunset that you’re trying to display is not calculated when you think it is.
1 Like
Oh I am…
I literally hit send on that message then realised what I was saying! Sorry.
So yes, if you’re calculating just a sensor its ok, but when you go to times, the “seconds” could… will… cause issues along with the timing of all other sensors updating (creates a ‘knock on’ affect)
Very useful to know, this helps with several other sensors I have that have “minor bugs”.
Useful for future people too.
You could just use what @WallyR mentioned, which is the sun2 custom integration that solves a lot of these odd problems with sun.sun.
1 Like
I like the idea, however, I’ve been stung many, many times by over complicating something by using custom integrations… for a later date to either;
a) Fix the original issue (e.g. sun.sun)
b) Migrates the custom integration with HA (e.g. sun2 replaces sun.sun)
I can cope with a couple of minutes lag as it’s only a visual.
The problem with both points 1 and 2 is that they would be massive breaking changes. That’s largely been the hold up for fixes on this integration for some time. Not to mention, the developers want to move sun.sun more in line with existing entity structures as well. Which is a whole different list of breaking changes. No one has been willing to take on that responsibility.
1 Like
I thought I would have a look at the raw code see what was going off… Think I’ll avoid it now.