It doesn’t happen very often (twice to my recollection over 3 years, so has maybe happened a dozen more I didn’t observe) but one of my speakers went off and the second a light came on.
The speaker I have no clue as it’s a very complex single automation based on a very complex binary sensor (multiple time slots, occupation, manual) but life360 was having a bad day (jumped us away from home (erroneously) ??? (this is a guess based on the notifications I got from life360 saying they were having server problems) ) so probably that. (Edit: this particular automation has been tested 6 ways from sunday, gone over line by line and is as bulletproof as possible)
The light however has me mystified, so I want to track the offending automation down.
If it does it again I’ll just paste the template into the editor and the results can narrow down my search.
I ‘may’ have found the local_time myself once I started playing with it but yours certainly helped, I’ll probably mod it further to include (say) 'from 3 hrs ago, and the hour following'.
I wasn’t planning on turning this into a sensor, it’s just a debugging tool like I use other templates to write some lovelace yaml in a repetitive ordered form
I tried the first one you suggested, for automations, and it appears to have a problem handling automations that have “Never triggered”. When it encounters one, it reset its sorting sequence.
For example:
“32 seconds ago”
“5 minutes ago”
“3 days ago”
“4 weeks ago”
“7 weeks ago”
“Never triggered”
“1 hour ago”
“22 hours ago”
“1 week ago”
“Never triggered”
“12 minutes ago”
“17 minutes ago”
I tried using this template (which eliminates automations that never triggered) but that style of entity filtering seems to lose the ability to support options with secondary-info: last-triggered
So, I went to ‘limit’ the window for last triggered I was interested in, and tried : -
{% set timepoint = 2 %}
{% set timepoint = now() | as_timestamp - timepoint * 60 * 60 %}
{% set offset = 30 %}
{% set timefrom = timepoint - offset * 60 %}
{% set timeto = timepoint + offset * 60 %}
{% for state in states.automation | selectattr('attributes.last_triggered')
| sort(attribute='attributes.last_triggered', reverse=true)
| selectattr('state.last_triggered', '>', timefrom)
| selectattr('state.last_triggered', '<', timeto) -%}
{{ state.attributes.last_triggered.timestamp() | timestamp_local }} : {{ state.name }}
{% endfor %}
I originally went with x < value < y but that gave a similar error and consulting the list of builtin functions couldn’t find a ‘window’ limit test, so I split it into two separate tests.
This too failed.
I’m thinking this must be (yet again) a failure based on last_triggered == none
but thought that had been filtered out by the first cast.
Maybe they work from right to left but changing order and parenthesis (in my limited tests given I’m groping in the dark and the possible permutations) yield similar results.
So If I’m interested in what happened 2 and a hafl hours ago I’d set timepoint to be 2.5 and if I wanted a 40 minutes window (each side) the offset = 40
The only glitch is that if you increase 1440 (number of minutes in 24 hours) it seems to have no effect other than, beyond about 2500 it suddenly displays all my automations, regardless of when they triggered (i.e. days or even weeks ago). So if you only want to present automations that have triggered in the past 24 hours (in the UI), this does a neat job.
Marius,
I think this is a neat option, but generally don’t want this guff occupying ‘real estate’ on any of my interface screens
BUT
Why would you comment out the null filter ? It would seem that this is pretty much required for any useful display of this (just trying to understand)
(My issue here being that a LOT of my automations are copied from other instances and set up for rooms (etc.) where the infrastructure isn’t even installed yet)
Would you happen to know a way to make the auto-entities card display the automations without a toggle button next to each one? In other words, just show the automation’s friendly_name and, for secondary_info, the number of minutes since it was triggered.
I guess instead of the entities card, some sort of custom card would be needed?
So should last_triggered be updated each 15 minutes regardless of the rest or only if the condition meets and the fiftyDayAverageChange in this example is below 3?
For me last_triggered should show last triggered and not last_done_something_after_triggered.
o.k. Is it working here this way as well, but wonder why this attribute is then not named last_action or whatever, perhaps as a second attribute. last_triggered is and should for me last_triggered.
It’s a general name that covers 99% of meaningful usage cases.
As you have found, having it updated every 15 minutes (in your usage case) is just pointless
I suspect it was inherited from a time when ‘conditions’ did not exist.
If you really want the last_evaluated time then remove the condition - call a script in the action and then put your condition as the first step in the script.
Think about what you want and then do it
Arguing semantics won’t actually get you anywhere as 95% of the userbase is familiar with these terms how they are used (having implemented them as such) and anything else would cause a major breaking change.
By the way, we have found a way to put the above template in a card, there are various techniques but I favour the one with only the last 40 automations shown and with a time limit too (1 day given below). you can obviously adjust to suit your requirements. These are listed showing local time (in reverse order) : -
### Automations Triggered
- type: markdown
title: Automations Triggered
content: |
**Time Name**
{% for state in (states.automation
| selectattr('attributes.last_triggered')
| sort(attribute='attributes.last_triggered', reverse=true)) [0:40] -%}
{% if (now() - state.attributes.last_triggered).total_seconds() < 86400 %}
{%- set t = (as_timestamp(state.attributes.last_triggered) | timestamp_custom('%H:%M', true)) -%}
{{t}} _{{state.name}}_
{% endif -%}
{% endfor %}
No, IMHO it is a name, which does not cover what it does.
Already had this that way before my question …
If something is obviously wrong, it should not only stay, because users are used to this. No one knows, how many new (or old users) are putting time into error debugging, because they think, that their triggers are not triggering. With the new release and the automation debugging, it is of course easier, because the “not”-last_triggered runs are in this log as well.
You are right with the /x ones, but who knows if this is working or if you have other triggers, if they are triggering, …
But of course, now I know, that this is (as expected) working this (for me: wrong) way, and so I hope that all the others, who think that their triggers are not triggering and after a lot of search in their environment will find this thread.
If you feel “strongly” about it, put it as a feature request (to be voted on).
Explain your case, how you think the existing lable should be renamed, the introduction of a new attribute, how that should be named and how you propose the change to be introduced - migrating users to the new terminology.
I don’t expect you will get many votes but even assuming it’s a popular topic and you get thousands of votes, I suspect the devs won’t touch it as : - This will be (by definition) a Major Breaking Change - The support of which will be a nightmare, with no possibility of an incremental shift allowing users to ‘get there’ without their current automations, sensors and scripts - hitting a brick wall - crash !
I may be wrong, try it and see.
You have never fired this automation before (unlikely as regular testing of any automation should include an actual triggering)
You have fallen into the trap of setting the automations initial state (this clears the last_triggered attribute) The reason this is a mistake is that automations should always be ‘on’ if you don’t want it to fire write a suitable condition to prevent it.
Your workaround is an acceptable interim step but I’d examine your motivations for setting any state
You are right, I was treating the symptoms, not the root cause. Your reply made me go back and see what automations were the ones that had .attributes.last_triggered either undefined or set to none. Turns out I had some zombie automations that showed up on the frontend, but were no longer in my automations.yaml . I deleted them and reverted the changes.
