Add more information to "context" objects

Right now context only contains an id, user_id, and parent_id. It would be very useful to have additional information available in context so that automations may react not only to a state changing but also what caused the state to change. To do this context could be expanded to include the following:

root_entity_id: the entity id that started the overall set of state changes / events
entity_chain: list of entity ids starting from root_entity_id that led to this current context

With these two fields we could support the following use cases:

  1. Only trigger an automation if a state change was by an interaction with a particular physical device. Ex: Disable motion lighting auto-off automation when someone changes light level from a physical switch but not when light level is changed by other automations.
  2. Only trigger an automation if a state change was caused by a particular other automation or script. Ex: Ignore light brightness change if the change was triggered by a circadian lighting automation.

The ability to customize context would also be useful. For example if an automation could add arbitrary data to context (like event_data but available to all things that change as a result of the automation’s actions). That would allow for significantly smarter automations that can add context about why changes are happening so that downstream consumers of changes can make better decisions.

I think this is a good idea and can greatly simplify the way to do certain things.

However, I have found that the behaviour of the current context data is not very reliable.

This user explains it quite well here.

Apparently, the way to group contexts so that they share the same id is done based on a time window of 5s. During this time, neither the id, nor the user_id, nor the parent_id, change.

This can be consistent if the parent_id and user_id are the same. But if they change, both should be respected, as well as creating a new id.

Examples with “state_changed” event:

EXPECTED BEHAVIOUR:

  • Switch on from lovelace.
    New ID, Null parent_id, current user user_id.
  • Switch off from the device itself (hardware switch).
    New ID, Null parent_id, Null user_id.
  • Switch on from an automation not related with previous actions.
    New ID, Trigger parent_id, Null user_id.

CURRENT BEHAVIOUR (Less than 5 seconds between actions):

  • Switch on from lovelace.
    New ID, Null parent_id, current user user_id.
  • Switch off from the device itself (hardware switch).
    Same ID, Null parent_id, Same user_id.
  • Switch on from an automation not related with previous actions.
    Same ID, Null parent_id, Same user_id.

So I think your proposal is very interesting, but I also think the current behaviour should be fixed first before adding new functions.

I wasn’t aware of that quirk, thanks for bringing it up, that greatly limits the usefulness of context! If that’s how it behaves right now then IMO it’s essentially broken in practice and I think that bug needs to be fixed.

Yes, I think so. Using context for anything could be completely unpredictable because of this way of grouping the events.

Thank you for opening the issue.

I was testing to try to understand how the context works, with the purpose of using it in various automations. But after seeing this problem I have discarded it for the moment.