Trigger automation 15 minutes before date_time stored in input_datetime

[123 (Taras)]

Just for fun, paste this into the Template Editor:

{% set t = as_datetime('1970-01-01T08:45').astimezone()%}
{{ t }}
{{ t.timestamp() }}
{{ now().fromtimestamp(t.timestamp(), now().tzinfo) }}

There’s a potential hitch with the idea of storing the time (for a time-only input_datetime) on the day of the Unix Epoch plus one’s timezone. The hitch is DST.

The result of the three templates is this (for my timezone):

1970-01-01 08:45:00-05:00
49500.0
1970-01-01 08:45:00-05:00

• The first line represents the 08:45 as a datetime object whose date is the Unix Epoch and whose timezone is set to the local timezone. It looks good.
• The second line is the same datetime object but converted to a unix timestamp.
• The third line creates a datetime object from the timestamp and the result matches the original datetime object. It looks good.

Everything looks perfect except the timezone offset now, in July August, is -04:00 and not -05:00 (which is OK for January).

This poses a challenge of how to use this arrangement to set a fixed time of 08:45 (for year round use) without it being offset by DST.

I’m beginning to see why it currently works the way it does … (namely as just the number of seconds since midnight).

[koying (Chris B)]

Yeah, no-go.

What about

[123 (Taras)]

My as_datetime() and `as_timestamp() don’t appear to have the same magic as yours do.

[koying (Chris B)]

What I showed is a proposal for a change that I implemented
Indeed, currently, neither as_datetime nor as_timestamp work for a time-only input_datetime…

[123 (Taras)]

@koying

What I showed is a proposal for a change that I implemented

Ah! My mistake; I didn’t understand that and thought you were demonstrating existing functionality.

I like it. It would make using a time-only input_datetime as neat as what petro proposed with a today() function:

{{ now() >= as_datetime(states('input_datetime.xyz')) - timedelta(minutes=15) }}

That happens to be the same template one can currently use if the input_datetime has both time and date.

Are you planning to create a PR?

[koying (Chris B)]

@123

Are you planning to create a PR?

Sure. Would be nice to get the feedback from @petro, as he already thought quite a bit about the problem.

[petro]

What exactly did you change? Can you plop your changeset or branch?

[koying (Chris B)]

Here you are

CHG: as_datetime/as_timestamp handle time-only

[petro]

I don’t think that will pass a review. I could be wrong on that, but i would expect the changes to go in home-assistant/dt.py at 9fc92ab04e0d1933cc23e89b4095714aee725f8b · koying/home-assistant · GitHub

I want to post a detailed response but I’m on a crunch at work. I’ll have to respond in a day or 2.

[123 (Taras)]

What are your thoughts on making as_datetime convert a date-only input_datetime?

For example it would convert 2021-08-20 to a datetime object with the same date but at time 00:00:00 and one’s local timezone?

Basically, it would support conversion of all flavors of input_datetime to a usable datetime object.

[koying (Chris B)]

That’s already the case, isn’t it?

[123 (Taras)]

Almost, the result is offset-naive (no timezone) so you can’t use it in a comparison with an offset-aware datetime object like what’s produced by now() or in date math.

[koying (Chris B)]

Per ISO, no TZ means local time.
If I do

{{ as_timestamp(as_datetime(states('input_datetime.date_only'))) }}

I get a timestamp of 00:00 in my local time.

[123 (Taras)]

@koying

Per ISO, no TZ means local time.

Home Assistant’s Jinja2 interpreter doesn’t appear to make assumptions when timezone is missing.

---

EDIT

FWIW, explicitly setting the timezone makes it offset-aware and then the comparison can be performed:

[koying (Chris B)]

(Not so) fun fact:
If the timezone is not explicit, it’s the TZ of the machine (or container) that is picked up, via python I guess.
The vscode dev container is in UTC, even though the machine is in UTC+2, and I get timestamps in UTC. The TZ setting of HA is ignored, then, but now() still returns a datetime with the HA TZ

[tmcmaster (Umutcelebi)]

Can someone help me with something similar like this?

I have a few time sensors and i want to make sensor which is - 15 minutes of the sensor.
So if it is 15.15 then i want the second sensor 15.00 and then i can trigger them for automations.
Any idea?
I have tried those things above but i cant program and just edited but with no luck sadly…

[123 (Taras)]

Post what you have tried but failed to work.

[tmcmaster (Umutcelebi)]

I have tried many things but like i said im a noob in this.
Just have this as last which isnt working ofc.

{{ state_attr(‘sensor.s_time’, ‘timestamp’) - 900 }}
{{ states(‘sensor.s_time’, ‘timestamp’) - 900 }}
{{ states(‘sensor.s_time’) - 900 }}

[123 (Taras)]

What is sensor.s_time? Is it produced by an integration?

Post a screenshot of how that sensor appears in Developer Tools > States.

[tmcmaster (Umutcelebi)]

You mean this?

Edit:
I have made this sensor from another sensor which had date and time.