Improve context object to allow better logbook entries

[nielsfaber]

Context

The logbook entries are very useful for tracing back when+why the states of entities were changed.
The current implementation already allows you to see which user made a change to an entity, if this was done through the GUI.
In other cases, such as an automation that turned on an entity, it is not always clear what happened, since this is not mentioned in the logbook entry.

Proposal

My proposal is to improve the context description for logbook entries.
E.g.:

1. "Turned on by (automation name)"
2. "Turned on by (integration name)"

And perhaps other use-cases, which I cannot think of right now.

This change can be made possible by expanding the ha.Context object, allowing it to refer to an (automation) entity or an integration entry.
Ofcourse the ha-logbook frontend element should be modified as well, for being able to pretty-print the context.

Consequences

The proposed change seems a win-win to me, from what I can see there are no negative side-effects.
To be sure, we need to investigate in which places the ha.Context object is used currently.

[kevinkahn]

Could this also cover the case where the change is initiated from the API interface. I have a Pi based set of control consoles that access HA to turn things on/off via GET/POST calls to HA. Currently, any of these logs as by the user who created the authentication token (namely, me) no matter which console the command came from. What would be nice would be to augment that call with enough context information so that this could log as from a specific console.

[spacegaier]

This information is already there. This is what the backend provides for my light that has been turned on my an automation. In some cases it is not correctly rendered in the frontend (more-info {see your screenshot} and logbook card, I will create a PR home-assistant/frontend#8231), but in the logbook panel it is shown.

item: Object
context_domain: "automation"
context_entity_id: "automation.turn_on_office_light"
context_entity_id_name: "Turn on Office Light"
context_event_type: "automation_triggered"
context_name: "Turn on Office Light"
entity_id: "light.office_ceiling"
message: "turned on"
name: "Office Ceiling"
state: "on"
when: "2021-01-24T08:16:27.546892+00:00"

[nielsfaber]

@spacegaier Thanks for your feedback on this.
I was not aware of differences between the logbook panel and the more-info card.
It seems like a good idea to get rid of the inconsistencies here 👍

I see indeed that when an entity has been changed by an automation, it already shows up correctly in the logbook panel (as in your example).

My only remaining question is how an integration can make use of this functionality.
I am the owner of the scheduler-component which allows users to program a day/week program for their devices.
This component now uses async_call_from_config for the service calls.
So far I haven't been able to figure out how I could pass the context to the service call, such that it would display "(entity identifier) turned on by (schedule identifier)".
Could you give some pointers for this?

[spacegaier]

Have a look at the unit test test_logbook_entity_context_id. That might provide some leads, otherwise @bdraco can surely help. But since there clearly has to be a way, I think this falls outside of this architecture issue.

[balloob]

Fire an event when a schedule fires with same context. Then add a logbook platform.

This is a dev q. Not architecture