a yes, sorry…
should it be like this then:
sunset_offset:
friendly_name: Sunset offset
entity_id: sensor.time, sun.sun
value_template: >
{{(as_timestamp(now()) -
as_timestamp(state_attr('sun.sun','sunset')))| timestamp_custom('%H:%M:%S', false) }}
not sure how id put all that in the act part of the automation…
Yep, that should do it.
cool, thanks ! btw you state the sensor is using UTC, while I am in CET…which is kind of an issue when calculating the offset 
Or is this recalculated in the backend?
The as_timestamp function takes into account the timezone for timezone aware times (i.e., timezone aware Python datetimes, or string representations of time that contain the timezone offset at the end), and assumes local for naive times (i.e., naive Python datetimes or string representations of time that do not contain the timezone offset at the end.)
Bottom line … as_timestamp('sun.sun', 'sunset') will produce the correct Unix Epoch timestamp.
If you’d like to see this for yourself, enter the following into the Template editor:
{{ now()|string }}
{{ utcnow()|string }}
{{ as_timestamp(now()|string) }}
{{ as_timestamp(utcnow()|string) }}
updatet and checked accordingly.
should have been this btw;
sunset_offset:
friendly_name: Sunset offset
entity_id: sensor.time, sun.sun
value_template: >
- {{(as_timestamp(state_attr('sun.sun','sunset')) -
as_timestamp(now()))| timestamp_custom('%H:%M:%S', false) }}
cool.
about the (now) trap, why isn’t this template hindered by that:
time_template:
friendly_name: 'Time'
value_template: >
{{ as_timestamp(now()) | timestamp_custom("%H:%M %d/%m", true) }}
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:
would this be the correct way to write that:
{% if as_timestamp(now()) < as_timestamp(state_attr('sun.sun','sunset')) %}
- {{(as_timestamp(state_attr('sun.sun','sunset')) -
as_timestamp(now()))| timestamp_custom('%H:%M:%S', false) }}
{% else%}
{{(as_timestamp(now()) -
as_timestamp(state_attr('sun.sun','sunset')))| timestamp_custom('%H:%M:%S', false) }}
{%endif%}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) }}
almost: before sunset it should give a negative time (sunset minus time) and after sunset a positive (sunset plus time)
my current template does that, but yours seems so much more sofisticated…
and yes, I might have been confusing… what I meant was the template should work per 24 day, and not per period between sunsets…
No problem.
Easy enough, just change > to < in the first if statement:
{% 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) }}
thank you very much, very nice indeed. One for the manuals!
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
I would think so, too. It should definitely be finding those entities and watching for their state changes.
It could be that those entities are somehow working differently themselves. See this topic for something similar.
right, thanks!
tested this:
{% set temp = states('sensor.rsd_temperature')%}
{% set wind = states('sensor.rsd_wind_speed')%}
{{(13.12 +0.6215*(temp|float) -
11.37*((wind|float)*3.6)**0.16 +
0.3965*(temp|float)*((wind|float)*3.6)**0.16) | round(2) }}
but that results in the same below zero… must check if something else went wrong somehow. Most of the time the jagti windchill is quite accurate
Ok, it was worth a shot. BTW, it would be simpler/cleaner to put the float conversions in the set statements:
{% set temp = states('sensor.rsd_temperature')|float %}
{% set wind = states('sensor.rsd_wind_speed')|float %}
{{(13.12 +0.6215*temp -
11.37*(wind*3.6)**0.16 +
0.3965*temp*(wind*3.6)**0.16) | round(2) }}
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.
just for info and completeness sake, here the revised sensor (2 variants that do work)
jagti_windchill:
value_template: >
{% set temp = states('sensor.rsd_temperature')|float %}
{% set wind = states('sensor.rsd_wind_speed')|float %}
{{(13.12 +0.6215*temp + 0.3965*(temp - 28.676)*(wind**0.16)) | round(2) }}
unit_of_measurement: '°C'
device_class: temperature
friendly_name: Jag/Ti Wchill
# https://www.meteo.be/meteo/view/nl/68771-FAQ%27s+over+het+weer.html?view=3268614
kmi_windchill:
value_template: >
{% set temp = states('sensor.rsd_temperature')|float %}
{% set wind = states('sensor.rsd_wind_speed')|float %}
{{(13.12 + 0.6215*temp - 11.37*(wind**0.16) + 0.3965*temp*(wind**0.16))|round(2)}}
unit_of_measurement: '°C'
device_class: temperature
friendly_name: Jag/Ti Wchill KMIAny 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.