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.
