understand that… 
what I can’t grasp though, is if I check, let’s say 45 minutes after the previous sunset, I could use the template which calculates using the next sunset, and show me +00:45:00
Sorry, I don’t understand what you mean.
probably my bad. glad you’re helping here.
What I am trying to establish is at any given moment, to read the offset to the previous sunset of that moment, and not the offset of that moment to the next sunset.
Ah ok now I understand. My template works for times before sunset but not after.
Maybe at midday each day store the sunset time in an input_datetime and use that in the template.
yes, have to give something like the a thought.
Maybe that could be a nice addition to @pnbruckner s custom component, will asl about that.
thanks for helping me!
trying to ‘record’ it 
If I understand correctly, you want to trigger an automation some amount of time after sunset. Of course, if the offset was constant you could just do:
trigger:
platform: sun
event: sunset
offset: '00:45:00'
But I believe you’re looking for a way to use a dynamically calculated offset, and unfortunately sun.sun’s next_setting attribute changes at sunset to tomorrow’s sunset.
You could use my CC with the sunset attribute enabled. This attribute is constant throughout an entire day, changing at midnight. As long as the calculated offset doesn’t go past midnight, you could do something like:
trigger:
platform: template
value_template: >
{{ (as_timestamp(state_attr('sun.sun', 'sunset')) + N_SECONDS)
|timestamp_custom('%H:%M') == states('sensor.time') }}
where N_SECONDS would be some expression that evaluates to the number of seconds you wanted the offset to be.
Would this work? Or do you need the offset to possibly go beyond midnight?
HI, thanks!
Yes, what I am trying to accomplish is this:
lets say sun sets at 1800 hours. My light_level sensors switches in at 18.45 and turns on the lights. Id like to template that positive offset of 45 minutes from the sunset automatically.
I can do the same with the sun angle on each moment of the day:
value_template: >
{{ '%+.1f'|format(state_attr('sun.sun','elevation')) }}
Hope to be able to do something like that for the offset.
example automation to do that:
data_template:
message: >
{{as_timestamp(now()) | timestamp_custom("%X") }}: Parking is set and safely lit
while Solar angle is {{states('sensor.solar_angle')}} and Offset is {{template_offset}}
so id just like to find out what the offset is, rather than set it, as you do in your template with + n_seconds
Ok, I guess I misunderstood what you said here and in the other thread (for my CC.) I thought you were looking to trigger an automation at some dynamically calculated offset from sunset.
If you just want to figure out how long it has been since the last sunset (at some time determined by some other mechanism), then yes, there is no current attribute I’m aware of that would tell you when the previous sunset was (especially after midnight.) My CC could be fairly easily extended to add a prev_sunset attribute I suppose. Although as others have suggested, you could have an automation that runs, say at midnight, that saves the value of the next sunset (i.e., “today’s”, from either the standard sun component or my CC) into an input_datetime, and then use that. Actually, since these attributes are really strings (which are compatible with the as_timestamp function), it would probably be easier to save to an input_text.
EDIT: Actually, if you triggered the automation at sunset, and had it save the current time (i.e., now()), that should give you the time of the previous sunset until the next sunset happens (when the time is updated again.)
do i understand correctly that your component has an attribute sunset that is valid for the whole day? wouldn’t that than allow for something like offset = sunset - now() ? (never mind the correct syntax , this is only the idea)
the sunset would never go past midnight, so id always stay within the 24 hours of one day
i think that would be easiest, might I throw in a feature request for that no need for extra input_texts or automations if it were available like that!
this would be what I need, call it last_sunset, and then use that to calculate the offset when the light_sensor kicks in with the now() of that moment: offset = now() - last_sunset.
think that’s what I posted above already…
No, that would not work between midnight and sunset, because at midnight it gets updated to the new day’s sunset. From sunset to midnight it is effectively the date/time of the previous sunset. But after midnight (and until sunset) it is the date/time of the next sunset, just like next_rising. The difference between these two attributes is that next_rising updates at sunset, whereas sunset updates at midnight. next_rising always tells you when the next sunset will be, whereas sunset always tells you when today’s sunset will be or was. What you’re looking for is an attribute that also updates at sunset and always tells you when the previous sunset was (which is effectively the date/time of when next_rising is updated, which is why capturing the current time at sunset would give you the same thing.)
Easiest for you, not for me. So far you’re the only one that I’m aware of that is looking for such a feature. If I had infinite time on my hands I’d consider doing this, but I don’t, and I have a few other things I’m trying to do right now that I think more people will benefit from, so they’re taking priority.
It really comes down to what time period during a given day do you want to be able to calculate the time since the last sunset. If you just need that to work between sunset and midnight, then you can do this with my current CC using the sunset attribute. But if you want the calculations to be valid between midnight and sunset as well, then I’d suggest what I did before: use a simple automation that triggers at sunset and captures the current time in an input_text.
yes, that was what I am looking for, and hoping to be able to use your component for. would this work:
{{(as_timestamp(now()) - as_timestamp(state_attr('sun.sun','sunset')))| timestamp_custom('%H:%M:%S', 0) }}
would lead to:
##############################################################################################################
# using @pnbruckner cc sun.py
# https://github.com/pnbruckner/homeassistant-config/blob/master/custom_components/sun.py
##############################################################################################################
sunset_offset:
friendly_name: Sunset offset
value_template: >
{{(as_timestamp(now()) -
as_timestamp(state_attr('sun.sun','sunset')))| timestamp_custom('%H:%M:%S', 0) }}
and
automation:
- alias: 'Notify outside daylight'
id: 'Notify outside daylight'
# initial_state: on
trigger:
platform: state
entity_id: binary_sensor.outside_daylight_sensor
# to: 'off'
condition:
condition: template
value_template: >
{{is_state('input_boolean.notify_system', 'on')}}
action:
service: notify.notify
data_template:
message: >
{{as_timestamp(now()) | timestamp_custom("%X") }}:
Daylight {{states('binary_sensor.outside_daylight_sensor') }}: Outside lights are powered
{{'on, ' if is_state('binary_sensor.outside_daylight_sensor', 'off') else 'off, '}}
Solar angle is {{states('sensor.solar_angle')}} and Offset is {{states('sensor.sunset_offset')}}.
Mostly, but you’ve fallen into the “don’t count on now() to update a template sensor” trap again. 
In this particular case (unless you want to use sensor.sunset_offset elsewhere) you’re probably better off just moving the calculation into the automation action.
Also, the second parameter of timestamp_custom is supposed to be a boolean, so it should be false, not 0. (BTW, the preferred boolean values in jinja are lower case false & true, not the Python spelling of capitalized False and True, although either works.)
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:
- {{(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) }}
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%}