Condition: Last button press at least an hour ago

Configuration
1

I have an automation that I would like to add a condition to. The last press of a specific Hue Smart Button must be at least an hour ago. Normally I would use something like that:

    - condition: template
      value_template: >
        {{ (as_timestamp(now()) - as_timestamp(state_attr('remote.hue_smart_button_1','last_triggered'))) > 3600 }}

But the Smart Button doesn’t have “last_triggered”. Instead it has “last_updated”, which is an array:

[2020-05-27], [18:37:08]

How can I concatenate both array-entries to make them work with the as_timestamp-function? Or is there an even easier way to check for the last button press?

2

It’s not clear exactly what type(s) that data is. Is it a single string that looks like that? Is it an list of strings, a list of lists? Are those values datetime.date & datetime.time objects, or strings, …???

3

In the dev tools it looks like this:

2020-05-27_22h56_53

When I enter this in the templating-section:

{{ state_attr('remote.hue_smart_button_1','last_updated') }}

it outputs:
['2020-05-27', '18:37:08']

4

Ah, ok, a list of strings.

{% set attr = state_attr('remote.hue_smart_button_1','last_updated') %}
{{ (attr[0]~'T'~attr[1])|as_timestamp }}
5

Never mind; brain fart; try what pnbruckner posted below.

6

Did you mean maybe one of these:

{{ states.remote.hue_smart_button_1.last_changed }}
{{ states.remote.hue_smart_button_1.last_updated }}

You can’t get to those “fields” of the state object using the state_attr() function.

1 Like
7

The moment I posted that I recalled mentioning to someone else that you can’t do that …

Brain fart. Post will be amended.

1 Like
8

Thanks, that worked! I had to adjust it a little bit, because strangely the last_updated values are off by two hours (e.g. showing the last button press for 2pm when it was 4pm). So I did this to remove the time zone difference:

{{ (as_timestamp(now()) - as_timestamp(attr[0]~' '~attr[1]~'+00:00')) > 3600 }}

I don’t know if this will make problems around midnight, will have to test it.

Btw., what’s more common, as_timestamp(now()) or now()|as_timestamp?

9

Ok, so I’m guessing your local time zone is +2hrs, yes? So it looks like the last_updated time is in UTC, and adding that suffix is necessary, because otherwise as_timestamp will assume local time.

I think as_timestamp was first implemented as a function, and then later added as a filter. So I would suspect the former is more common, only because that was all that was available and so that’s what people learned to use. Which you use in any given circumstance now depends more on what’s easier, or really, personal preference. I think (and hope) the function works exactly the same as the filter, so it shouldn’t matter.

1 Like
10

Yes, I live in Germany, my current time zone (summer time) is CEST, which is UTC+2.

11

As you are now doing an offset to UTC, this will not work all year round, where for instance you will only be 1 hour ahead in winter. ( … so 2 hours between presses)
Instead you need to cancel the offset and just work in local time.
(This will also be wrong twice a year end March. end October, but only for an hour each time)

12

Um, I don’t think so. It appears the time is being provided in UTC, which never changes. So adding a time zone suffix is just making sure that the as_timestamp function/filter will properly interpret it as such (i.e., the time will be interpreted as UTC, which it appears to be.)

13

Apologies, for ‘some’ reason (stupidity) I saw that he had the utc applied at one of the timezones, had to adjust the template.
I didn’t read it fully and see that the same function applied to both, so any comparison (given identical offsets, or not (again identical) will still evaluate correctly.

As Taras is fond of saying ‘brain fart’
:flushed:

14

I think you still might be missing something. “Timestamps”, by definition, are always in UTC. They are the number of seconds since the “Unix Epoch” which is 1970-01-01T00:00:00+00:00, which is UTC. So regardless of the time zone of the value “input” to as_timestamp, the “output” is always UTC. So subtracting the output of two as_timestamp function/filter calls, where one was “fed” a time in UTC and the other was fed a time in the local time zone, still works perfectly fine.

The problem was that as_timestamp will assume the local time zone if the “input” does not specify a time zone (with an appropriate suffix.) And since the one time was in UTC, but didn’t have a suffix to say so, the output from as_timestamp was wrong. The fix was to add an explicit time zone suffix so as_timestamp would interpret it correctly.

1 Like
15

Errrr, that’s quite often the case !

This is the difference between understanding a subject and having just enough tools to be dangerous. I do know that ‘whatever’ I produce has to be tested in the template editor (best tool in my box).
Thankyou for the clarification, I will try to take this on board but no guarantees that it will stick. I have created a set of templates from finity’s EPIC thread, which I need to work through till it properly beds in.
Feel free to correct me at any time (how else am I gonna learn ?)
I’ve run out of likes for today otherwise … (when did that come in to effect ? :man_shrugging: )

16

Phil,
Playing with these templates (derived from finity’s EPIC time thread). I can see that for actual durations UTC is best.
AND that the frontend will always deliver these values in local time.
So I only have to determine (check each time as I’m paranoid) that I’m dealing with UTC or local time (very rarely the latter) and do the manipulations accordingly.
So for ‘time since’ the difference (absolute) is implicit with UTC and I have to convert to local time to display eg 1 hr 26 mins since this light went on.
If the above is correct I may have wrapped my head round this.
(I’m a guy who needs to picture a globe rotating to work out timezones and offsets and procession (I really hate dst) and the sidereal/stellar day difference ughhhh !)

17 
{{ (as_timestamp(now()) - as_timestamp(attr[0]~' '~attr[1]~'+00:00')) > 3600 }}

So, this seems to have stopped working since 0.113. Any idea why?

“attr[0]” now returns “None has no element 0”.

18

What does the dev tools state screenshot look like now? Perhaps something has changed there? The basic templating logic hasn’t changed, so this:

{% set attr = ['2020-05-27', '18:37:08'] %}
{{ attr[0] }}

still outputs 2020-05-27.

Please post the full automation along with the states screenshot if you are still having problems.

19

I’m sorry, it was a configuration-mistake on my side. I removed a deprecated HACS integration for Hue Smart Buttons, hence the device I was trying to read the attributes from doesn’t exist any longer.

1 Like