Closed OnFreund closed 3 years ago
Seems like there aren't any opinions either way. Given that it's fully backwards compatible and optional, any objection that I go ahead and implement this?
We don't implement architecture changes without explicit approval.
Sounds like a good idea 👍
Would also be nice if wait_for_trigger
could take conditions 👀
Great. I'll get to work on adding an event_context
parameter.
As for enhancing wait_for_trigger
, I might need some help, as I don't understand it well enough yet, and there are also some interesting questions (like how to access the trigger in subsequent actions. In an automation trigger you can do it through the trigger
parameter).
I think that you can call it just context
, not event_context.
This was implemented in https://github.com/home-assistant/core/pull/40932.
Context
The event trigger lets you use an event's data dict to make sure the automation only triggers in certain cases. However, you cannot specify any constraints based on information in the context dict (e.g.
user_id
). Before 0.115, this could be solved by adding a template condition using{{ trigger.event.context }}
, but there's no easy way to do that with the newwait_for_trigger
.Proposal
Apart from
event_data
, let the user define constraints based oncontext
in anevent_context
parameter.Consequences
It's easier to trigger automations based on specific attributes of an event (e.g. the user who fired it), and it'll also be easier to use it with
wait_for_trigger
. Since this is done with a new parameter, it should be fully backwards compatible.