That’s because template sensors that don’t use the manual entity specification (i.e., the entity_id config parameter) and don’t contain any entities in the template that can be automatically extracted will update on every state change in the system. And since you have sensor.time defined, which causes a state change every minute, this particular template sensor will consequently be updated every minute. But…
There is a fairly recent change that I happened to notice that will change that behavior. See PR #17276 and PR #17319. This will cause this type of template to only update once at startup, and more importantly not for every state change in the system.
Interestingly, there is also another change coming that will add a service to manually force an entity to update – see PR #17278.
So, bottom line, it works now, but won’t work soon.
a yes, I’ve seen these PR too.
thanks for listing them here so meaningful. Guess some will need the entity_id in the value_template, like these discussed here. Other might benefit from the manual updating.
As said in the PR comments, some suffer from serious timing issues, and indeed these are very frequent in my logs, so I expect a great benefit.
please let me get back on the template for the offset:
apparently the offset doesn’t work as I hoped after all, since the above template now (after todays sunset) shows the time to the next sunset, while I would have hoped it to show the time passed after todays sunset.
{{(as_timestamp(now()) -
as_timestamp(state_attr(‘sun.sun’,‘sunset’)))| timestamp_custom(’%H:%M:%S’, false) }} does show that, but is wrong when evaluated at a moment before todays sunset.
Guess I need them both:
when now() is before sunset use:
{{(as_timestamp(state_attr(‘sun.sun’,‘sunset’)) -
as_timestamp(now()))| timestamp_custom(’%H:%M:%S’, false) }}
when now() is after sunset use:
{{(as_timestamp(now()) -
as_timestamp(state_attr(‘sun.sun’,‘sunset’)))| timestamp_custom(’%H:%M:%S’, false) }}
well that was sooner than expected… see the second Time sensor. Updated to 0.81.0b2 today… which is a huge step forward, and much more responsive. breaking change though.
Now you’ve got me confused again. I asked if you just needed the template to work between sunset and midnight and you said yes:
But now it looks like you want it to work all during the day. And I’m also confused as to what you want it to show.
I’ll take a stab and guess you want it to show the relative time to today’s sunset, such that before sunset it shows a positive time (i.e., how long it is before sunset), and after sunset it shows a negative time (i.e., how long it’s been since today’s sunset.) Is that it?
If so, how about this:
{% set nw = as_timestamp(now()) %}
{% set ss = as_timestamp(state_attr('sun.sun', 'sunset')) %}
{{ '- ' if nw > ss }}{{ (nw - ss)|abs|timestamp_custom('%H:%M:%S', false) }}
all of a sudden my windchill template is horribly off, could this have to do with that change too? I would have thought these entities are enough in the template itself?
jagti_windchill:
value_template: >
{% set temp = states('sensor.rsd_temperature')%}
{% set wind = states('sensor.rsd_wind_speed')%}
{{(13.12 +0.6215*float(temp) -
11.37*(float(wind)*3.6)**0.16 +
0.3965*float(temp)*(float(wind)*3.6)**0.16) | round(2) }}
unit_of_measurement: '°C'
device_class: temperature
friendly_name: Jag/Ti Wchill
tanks, much cleaner indeed. btw, the float operations were only necessary because at startup it would generate errors about not being able to multiply float by int (from memory here, not exactly that probably).
It always gave a correct value though. Now seems truly off, so maybe the weather sensors changed, ill have another go.
Any chance of an updated version of that? The test for > or - doesn’t seem to work anymore. Probably a python3 change? I get a unknown error in the template editor and TypeError: unsupported operand type(s) for -: 'float' and 'NoneType' in the log.
That template assumes the use of my custom sun component. If you’re not using that then as_timestamp(state_attr('sun.sun', 'sunset')) will return None since normally sun.sun does not have a sunset attribute.
Thanks Although the normal sun.sun has next_setting, so as_timestamp(states.sun.sun.attributes.next_setting) works as well. That’s how i ended up with the next_setting initially. I thought i can access the “Next setting in x hours” info that’s on the (normal) sun popup, but couldn’t get it to work. Your solution is more precise
I don’t know what you’re trying to do with the information, but just be aware that the next_setting attribute changes at sunset. So for most of the day it indicates when the sun will set today. But at sunset it changes to tomorrow’s sunset. In some use cases that may be fine, but in many it’s not, which is the whole reason I came up with my custom sun component. It provides a sunset attribute which stays constant the whole day and indicates today’s sunset, even if it has already occurred.
Man, that’s what i like so much about home automation in general, you realize there is so much more under every stone you turn. For me, i was simply thinking about an automation to hide the offset at sunset since i deemed the information useless after the sun has set. Of course it makes sense for different applications than my narrow use case. I’m using it simply to show on a card how much sunlight i have left to go on a run/ride.
I’m trying to do something similar but much less complicated.
I’m simply want to change the offset if it’s a sunny day or not.
I’ve already made a helper binary sensor that determines if it’s sunny or not.
I’m just not sure how to change the offset using that binary.
This is my automation so far, it always erases my logic for the offset so I think I need to do this another way. I’m not sure.
see the second Time sensor. Updated to 0.81.0b2 today… which is a huge step forward, and much more responsive. breaking change though.
Although the normal sun.sun has next_setting, so 
