There is a last_triggered attribute for automations, but why not a last_finished.
It makes sense, since automations can wait for certain conditions before they continue, which makes calculating from the last_triggered timestamp not ideal.
I solved this for myself by calling a a python script at the end of the automation to add/set this attribute where needed. I can imagine it to be useful in other scenario’s as-well. Vote if you would love to see the attribute set by default too.
My use case, for those who are curious
I have an automation that triggers at entering the kitchen and when the TV is on, it joins the speaker there to the TV group. Nice if you want to hear what’s happening when you are away. It’s called ‘Follow Me’. Within the Follow Me automation is a ‘wait for trigger’ that unjoins the speaker once the sensor is clear for a certain amount of time.
If it’s dark, the same sensor triggers another automation that turns on the lights.
Now there is a third automation that groups all speakers in the same area when the radio or a stream is started (not when the source is TV). The automation has a condition that requires the speaker to be ‘not playing’ for 5 minutes. Otherwise it will (re)group speakers, that one might have unjoined for a reason, everytime a new song on Apple Music or Spotify starts.
This all works perfectly except for one scenario. A scenario where the speaker in the kitchen played the TV audio less than 5 minutes before someone decides to play a stream (radio/Spotify) and picks the kitchen as the first speaker.Then it doesn’t match the 5 minute condition and so the grouping doesn’t take place.
I solved this by checking whether the Follow Me automation was finished less than 5 minutes ago. If so, the speaker grouping is executed, even though the speaker status has last changed less than 5 minutes ago.
So as said, I now use a Python script that does the trick, but I think it’s a useful attribute for automations in general. Especially since automations can take more time to complete because of the waits.
Fyi, when you modify the state of an entity in a python script like you’re describing, those changes are temporary. As soon as the integration which manages that entity changes it’s state (the automation integration in this case) it’s going to remove the attribute you added. So is doing an HA restart or reloading that automation after editing it.
If you want to keep track of the time a particular automation last finished in a persistent way I would suggest creating an input datetime helper for that particular automation and then setting it from the automation. Course that would really be the “last successful finished time” since if the automation had an error it wouldnt get to that last step. But I would guess that’s good enough since you’re calling a python script right now and that would have the same issues.
Thanks for addressing the attribute being temporary. I am aware of it and am currently testing to see if it lasts for the 5 minutes I need it. I currently check if the attribute is there using {% if state_attr("automation.follow_me_tv","last_finished") != none %} before calculating the 5 minutes. If it’s not there, the condition will be False.
If it’s not available long enough, the helper is definitely the way to go, unless this feature gets into production of course
Is there a chance the automation would trigger again in that 5 min window? Triggering would clear the attribute since it updates the state of the entity to set last_triggered
The follow me automation triggers and kitchen speaker is playing TV audio until the same follow me automation says it to unjoin. Then it sets the last_finished
While the speaker is playing, the ‘group’ area automation will not be triggered by the speaker in the kitchen cause the condition prevents it to do so. So the unavailability of the attribute is no problem while the automation runs.
When the kitchen speaker is selected to play audio, the ‘group area’ automation is triggered and will check if the speaker was “not playing” for over 5 minutes.
If so, the grouping will take place.
If not, it will check if the ‘follow me’ automation was finished within the past 5 minutes, if so the grouping takes place, if not, the automation ‘group area’ finishes without grouping.
I expect the last_triggered to be set at the start and the last_finished is set at the end. The only scenario I can think of that can cause an “issue” is when you disable/enable and edit the automation. That is fine.
Having that said, this applies of course to my situation. There can be a lot of other scenarios in which it does cause problems
Sorry actually reading the use case. Before I just basically read the “I manually set the state of a thing” bit and pointed out the usual gotcha that trips people up.who try to do that.
Couldnt you just check last_changed of the the media player entity? See if it’s state has been modified in the last 5 minutes or not
In the initial post - use case - I try to explain that and doing so in the previous post as well.
I use that last_changed**, there however is one scenario in where that is not a solution. Quote:
This all works perfectly except for one scenario. A scenario where the speaker in the kitchen played the TV audio less than 5 minutes before someone decides to play a stream (radio/Spotify) and picks the kitchen as the first speaker.Then it doesn’t match the 5 minute condition and so the grouping doesn’t take place.
** The last changed however is a little more complex than one might expect, cause once it triggers it changes So I use:
I can confirm that the automation’s last_updated contains the time when it completed executing its actions.
I tested it by creating a simple automation, triggered by a button, containing only one action consisting of a 17 second delay. The value of last_updated was 17 seconds later than last_triggered.
It’s a bit of a surprise to me because I would have assumed last_updated contained the time when the automation was most recently modified. Anyway, it’s an interesting bit of information.
NOTE
Keep in mind that last_updated is (effectively) the same value as last_triggered at the moment the automation is triggered. It changes when the automation finishes executing its actions.
So I use:
