Is there a way to refer to the current running automation *within* that automation, like "self"?

Configuration
21

select_attr returns a generator, which is a list of items that it found. first grabs the first one.

22

fyi, all this is written in the docs for jinja :wink: . And just to put it into perspective, you and I learned jinja at the same starting time. I know I’ve said this 100 times to you, but you REALLY should take a class in this stuff.

23

of course I’ve read that, over and over. And its not that I dont grasp the generator…using that all over the place.
Still didn’t see why however, when the id is passed, and the person is selected, the |first does what it does. There’s only 1 person with the unique id is there? And there seems to be no difference when using eg |list

or am I to understand this it grabs the first one with this ‘id’ (the template doesn’t ‘know’ it’s unique, and it might just as well be ‘on’…of which many could exist?) and displays that.

In which case the |list does exactly the same, listing the sole person with this id?

24

if you have a list, you have a list object. It has list properties and only does things that a list does.

If you have an object, like a state object, it has state object properties and only does things that state objects do.

So, if you have a list of state objects:

{% set stuff = [ states.light.mylight ] %}

And you try to do state object things, liek this:

stuff.state

it will fail.

So you have to get the state object from the list like so:

stuff[0].state

or

{% set first_stuff = stuff | first %}
{{ first_stuff.state }}

This is all taught in beginner tutorials btw.

1 Like
25

I was hoping for the addition of a “user_id” function but using state_attr to get the job done is about as good as it’ll ever get. Thanks for the example.

26

Of course. that’s a way better idea.

I forgot that the user_id was in the person attributes.

27

Think of a list as being a container, like a bucket. If I hand you a bucket containing a single apple, you are directly holding the bucket and indirectly holding the apple. To directly hold the apple, you must reach into the bucket and pull it out.

In the same manner, given a list containing a single item, to get the item you first have to pull it out of the list.

28

Yes, that’s why |list does he same with a single item list :wink:
Funny though we can’t use |last

29

Not sure I understand what you mean.

If I apply the list filter to a list, the result is a list (not the item within the list).

If I apply first or last filter to a list containing a single item, the result will be the item.

Screenshot from 2020-07-22 09-03-00
Screenshot from 2020-07-22 09-03-00760×330 20 KB

{{ ['hello'] }}
{{ ['hello'] | list }}

{{ ['hello'] | first }}
{{ ['hello'] | last }}

{{ ['hello', 'world'] | last }}
30

what I meant was that if using |list in my template where posted |first, the exact same output is generated:

{{states.person|selectattr('attributes.user_id','eq','3redacted63')|first}}

renders:

<template state person.marijn=home; editable=False, id=theboss, latitude=5redacted, longitude=4.redacted, gps_accuracy=15, source=device_tracker.life360_marijn, user_id=3redacted63, friendly_name=Marijn, hide_attributes=['templates'], templates=entity_picture=if (entities['sensor.marijn_picture']) return entities['sensor.marijn_picture'].state; return '/local/family/marijn_not_home.png'; @ 2020-07-22T12:03:50.550668+02:00>

there’s only 1 person in the ‘bucket’. using either |list or |first gives the same outcome. of course, the first is not a list, sorry for the confusion. I meant there’s only 1 person…

31

this turns the generator object into a list.

Generators take less memory and can only be iterated across once. Lists stay in memory and can be iterated on many times. You need | list when you want to use the generator past the currently executing line.

32

Not true. List turns it into a list. example [ obj ]. And first gets the first item out of the list obj. Very different.

33

Good discussion of the difference between list and generator here but it’s (obviously) targeted at aspiring python programmers so it uses terminology that might be well beyond the familiarity of a casual Home Assistant user. Nevertheless, if you can grasp it, it clarifies how generators differ from lists … and might even make you wish list comprehension was available here.

34

I tried it and it does not return anything. That’s a bummer.

35

I know one year passed since last reply, but if someone wanders in here like me I have a solution. In automations you can now use variable this that contains state object. It’s been available since 2021.8 version.

From documentation of automation trigger variables:

Variable this is the state object of the automation. State objects also contain context data which can be used to identify the user that caused a script or automation to execute.

In my automation I used it like this:

condition: template
value_template: >-
  {{ as_timestamp(now()) - as_timestamp(state_attr(this.entity_id,
  'last_triggered')) > 60 }}
7 Likes
36

I know this is an old post. But I think you need a conversion to int there.

Like this. Incase anyone else uses this.

condition: template
value_template: >-
  {{ as_timestamp(now()) - as_timestamp(state_attr(this.entity_id,
  'last_triggered')) | int > 60 }}