What the heck turned my light on?

My what the heck moment was that sometime ago my light turned itself on and to this day I do not know what triggered it.

So I’d like to improve logbook and add information about what actually triggered the change. User triggered changes were added some time ago, but I’d like to add automations, scripts, self-updates etc. to be able to tell right from the logbook, that automation “Turn off the lights when nobody is home” turned of my light.

Agree! The basic foundation for it is already in place. However, it can be quite complex (in terms of a domino effect across multiple things that caused each other to trigger?)… I guess?

1 Like

We added this info to the backend for exactly this reason. If you feel like querying the DB, you can follow the context_id. The first event with the context_id did it (usually an automation_triggered or script_fired event). Doing these reverse lookups is expensive for the frontend :confused: maybe a detail view could do it on a per event basis?

4 Likes

Yea I think that detail view would be great for that, because I generally don’t need to query all the events at once, usually I’m interested in a single event.

3 Likes

More generic, not just on lights but on all automation’s. Why did my TV volume suddenly lower is just as valid a question.

This would also be really valuable for machine learning and other advanced home automation tasks. If we can distinguish if a user or an automation triggered a light, we can use it as input to train the algorithm for instance.

I did read something in this sense in the last release notes, not sure if that solves it though. haven’t checked yet. Does anyone know?

1 Like

Indeed, each automation should say what triggered it

Automation 'Lights on' was triggered by binary_sensor.motion turning on

Or

Automation 'Lights on' was triggered by sensor.time changing to 21:00

Etc

7 Likes

I love the idea of a detail view that can be pulled up from the entry!

Make it an attribute to the entity, last_modified_by

4 Likes

Here’s one way to determine what triggered an automation. Append a service call for logbook.log in all your automations.

Totally! I walked in to see my TV on the other day. WTH?! How many times can I vote? :slight_smile:

Here is my first pass at implementing this.

7 Likes

This has been implemented in 0.115dev

13 Likes

Brilliant, I raised a feature request/suggestion only today for this!!

I’m looking at lights in my logbook and it just says if it was turned on or off. Not what was responsible for the turning on and off. Isn’t that the purpose of this addition?

1 Like

I can confirm there are a lot cases where the information is missing where a automation is causing the change.

So what is the current status of this? Its not immediately clear if this will just become part of the core component, or if some sort of loglevel setting will need to be applied.

Currently im on version 0.117.5 and my logbook does not look like the screenshots in the pull requests linked. I see that both have been merged into the dev branch, but from there my lack of git knowledge causes me to lose track of where these stand. Any idea when they will be included in stable branch and if anything is required to implement this?

This is already in since a few months for the logbook panel. In other places (e.g. logbook card) it is not, but I proposed to change that now with this PR: