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.
Hi can someone post the updated config in full.
I’m getting a syntax error:
# Next sunrise or sun set
- platform: template
sensors:
sun_rise_or_set:
value_template: >-
{% 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) }}
icon_template: >-
{% if is_state("binary_sensor.sun_up", "on") %}
mdi:weather-sunset-up
{% else %}
mdi:weather-sunset-down
{% endif %}
Post the error too.
It usually contains the location to look for the error.
reverse the reject('none') and map('as_datetime')
{% set t = now() %}
{% set next = [ state_attr('sun.sun', 'next_rising'), state_attr('sun.sun', 'next_setting') ] | reject('none') | map('as_datetime') | sort %}
{% set next = next | reject('<', t) | list | first | default(t) %}
{{ (next - t).seconds | timestamp_custom('%Hh %Mm %Ss', False) }}