I am trying to trigger an automation on events so that it handles things sensible. I have one automation that works well due to an odd HA design quirk. This uses the fact that I only have zigbee on off devices and so an ZHA event for on and off is easy to establish.
I do however have some timers I am trying to track events on. I would like to trigger only when timers trigger a state chage to active or to idle. But as it stands it seems I have to take all state_change events for active and idle states and then in a condition create a template to see if it was for one of the timers.
Any help on improving this process os the automation is not triggered more often than it should be would be great.
Thank you all.
Example rigger to trap timer idle
trigger: state
entity_id:
- timer.keymaster_backdoor_autolock
id: idle_timer
to: idle
not_from:
- unavailable
- unknown
So what doesn’t work
As Nathan has pointed out, the best trigger to use for state changes is the State (or Numeric State) trigger.
To expand on his example, if desired you can use multiple entities and states in one trigger:
trigger: state
entity_id:
- timer.example_1
- timer.example_2
- timer.example_3
to:
- idle
- active
not_from:
- unavailable
- unknown
The Timer integration has specific Events that can be listened for by an Event trigger. But you would basically need to monitor all of them but timer.paused to capture all the events that would lead to a state of “idle” or “active”.
The issue is I do not want to limit it to a specific entity, but an entity type. i.e a timer. I have many timers and each time one is set to active, or returns to idle I want to triger an automation that acts on the devices in the same area as the timers.
I have a similar automation that is triggered by a ZHA_Event where the event data is “command: on_press”, this catches the on button being pressed on any of my lights and then switches lights in the same area as the light switch involved in the trigger. That way I have 1 automation that handles any new switch or light added to an area.
Now I just need to work out how to do this with timers without having the automation trigger on any device that may have an state of “active” or “idle”.
We understand what you are looking for…
Unless every timer entity that will ever exist should be subject to this automation, there is no way to avoid some type of user input to define the list of entities. As stated previously, your options are to list them in a State trigger OR to monitor all the timer events that can result in a state of “idle” or “active” and use template conditions to allow or block the entities based on some user-defined criteria. Those criteria could be based on an using a specific “naming” scheme for their entity IDs, applying a Label to them, assigning them a custom attribute, etc.
I am trying to work out how to trigger on all timer events. That is what I want. If I ever get 2 timers in an area that do not perform the same task I can worry about limiting the functions. But for now just limiting the events to all timer state_changed events where the to state is Active or idle would be great.
Your not listening… there is almost never a use case to use state_changed as the event type in an Event trigger. The only event data that can be used to effectively limit the trigger is entity_id. There is no way to use templates or wildcards for that data, so you need a event trigger for each entity being watched… basically recreating the worst version of a State trigger. Otherwise the trigger has to listen for all state_changed events which is both inefficient and unreliable due to the rate at which those type of events are posted to the event bus.
If you are adamant that you want to monitor “all” timers, use the timer events I linked previously:
Listening yes, but understanding, no. I think I need to go and do some more reading.
I am not an expert on this, but my understanding of this thread is that:
There are three ways to do something close to what you are asking, specifically you can trigger on a:
- State change event (the recommended solution).
- Timer event (using a generic event trigger)
- State change event (using a generic event trigger)
The last approach is considered really bad, because it will fire for every state change in the system.
If you wanted to use option #2, it would look something like this:
triggers:
- trigger: event
event_type: timer.started
- trigger: event
event_type: timer.finished
You would need to add addition triggers for the other timer events you were interested in, as well.