Add device_id to context

[balloob]

Context

Context is an object that indicates what actions belong to one another. It is attached to events and states. It is also passed along to service calls such that any resulting event/state shares the context.

By looking at the history, we note that the first event with a specific context was the originating event that set the things in motion.

Besides an id, a context has other fields, all optional:

• parent_id: this is used to link contexts together. If an automation triggers because of a state change, it will start a new context and the parent_context_id is set to the context ID of the state change.
• user_id: this is used to indicate the user that is making this action. It is used for both authentication and to attribute a change to a user

With voice we're introducing voice assistants. These are devices that take voice commands that will interact with Home Assistant. It is important that a user is able to track down which device initiated a command. Voice identification might help with this in the future, but it's not a guarantee to always be there nor would we block commands from non-identified users.

We also see events fired from devices or in the case of ESPHome, services called from a device. In both cases it's not clear what the origin is.

Proposal

Add a new device_id to Context to indicate what device started the action.

Consequences

We add a new optional field device_id to Context class in homeassistant/core.py.

We need to store this data in the database. Since the context is stored flattened in the events and states table, it will require adding a new column to both tables.

ESPHome will need to set device_id when creating a context as part of Assist Pipeline or any service call/event fired from ESPHome.

[balloob]

Here is an open question: we've been moving away from integrations firing events for things like motion detected in favor of new event entities. Do we want to update the old events to include device_id in the context?

[frenck]

We have discussed this today, and concluded we should enrich anything we can. The more we store, the more we are able to show.

[BradleyFord]

Yes, it can only help when debugging

…

On Wed, Oct 4, 2023, 01:51 Paulus Schoutsen ***@***.***> wrote: Here is an open question: we've been moving away from integrations firing events for things like motion detected in favor of new event entities. Do we want to update the old events to include device_id in the context? — Reply to this email directly, view it on GitHub <#978 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOZ77DL5KUCQ5CWLE256DX5RNEDAVCNFSM6AAAAAA5RG46XKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TCNZZGE4DC> . You are receiving this because you are subscribed to this thread.Message ID: <home-assistant/architecture/repo-discussions/978/comments/7179181@ github.com>

[luka6000]

Can this be generalized also to automation not only voice triggers? Looking at automation trace we can see what actions it performed, say call service switch toggle. But looking at that switch logbook we only see state change from service call (sometimes with user name) but not the automation entity that actually triggered that action. So maybe extending context with entity_id would be better. Maybe it's not entity_id or device_id but both? The purpose stays the same: being able to track down source of action.

[balloob]

This is already possible. The automation_triggered event was the first event with the context, and so Home Assistant can derive who fired it.

[frenck]

Discussed this proposal today, and agreed this is OK to move forward.

../Frenck