Awesome Switch triggered_by Attribute For Happy Automations!

use case 1:
A light-switch can be switched manually and via automation. In case of the manual switching I want the light to stay on until I manually switch it off. When the switch is switched on by an automation, a specific automation can switch it off.

In my case: I have a motion-sensor in the toilet that switches the ventilation system on and it is switched off after 5m. In the bathroom I have humidity-sensor which switches the ventilation on when humidity > 80% and an other automation that switches it of when humidity <= 80%. In order to get it to work correctly I had to store who triggered the ventilation in a separate variable.

use case 2:
For one switch there are multiple automations that can switch it on or off. If I want to debug why the light was switched, I have no way of knowing what triggered it.

Of course for every switch an alternative variable could be written from each automation that alters it state, but that becomes unmanageable quickly as your automation system grows.

proposed feature:
switch.<name>.attributes.triggered_by = mqtt|automation1|automation2

I hope you guys can see value in this addition. Please subscribe, share and like. It makes a huge difference.

I believe this is already in the pipeline, but they called it ‘context’

1 Like

Do you have a link perhaps? So I can read up on it

1 Like

Google?! What a neat tool. Find of the day! :joy: I guess duckduck isn’t answering all questions.

Thanks! I’ll do some reading there.

1 Like

It was mentioned a long time ago in a galaxy far far away …

This will make it possible in the future to introduce attribution.

Anyone knows if this was implemented? shows that there is a context_id in the db.
“Context is not stored in their own table in the database. Instead, each row in each table maintains it’s own columns to store context.”

As I read it, I can get the context by querying the db, which sounds even more horrifying than writing a extra variable. (abusing a configfile to program in a template engine doesn’t seem to be the best idea)

Not yet. Like so many things in homeassistant it gets announced, the bare minimum gets released, and then it gets forgotten about for ages.

1 Like

Speaking of attributions, I would appreciate if you fix the quote in your post. You have attributed it to me but I never wrote those words; they come directly from the linked blog. Please remove my moniker as the quotation’s source. Thank you.

Your Feature Request is a good idea. I’ve been using another home automation system for many years and it supports the concept of ‘the source of the trigger’. Rather than explain how it works in the other system, I’ll give you an example of how its implementation would look in Home Assistant (more or less). Basically, it would be part of Home Assistant’s trigger object.

- alias: Example
    platform: state
    to: 'on'
    service: notify.notify
      message: 'Switch was turned on by {{ trigger.to_state.source }}'

So if you were to manually turn on the switch, the source would be something like “self” indicating the switch itself was used to perform the operation (either via the UI or directly with the physical switch). If the switch was turned on by another automation then the source would be the automation’s name.

To be honest, I simplified the example because the other system provides more insight than just the source’s name. Nevertheless, that alone would be a step forward for Home Assistant.

1 Like

Removed your name from the quote.

As a part of the trigger object would certainly work for me. I am not that familiar with the HA codebase, but adding a source to the trigger object doesn’t seem like a lot of work. Of course it wouldn’t prevent collisions between automations, but you’d be a step closer to detect those.

Which other system are you using that supports this kind of stuff? Maybe we can learn something of that platform.


The ‘other system’ is a long-discontinued product called Premise Home Control.

In Premise, the equivalent of Home Assistant’s trigger object is called the sysevent object.

sysevent.newVal = trigger.to_state.state
sysevent.oldVal = trigger.from_state.state

Then it gets more sophisticated:

This is the class name of whatever caused the state-change. The closest analogy in Home Assistant would be the entity’s type (switch, lock, binary_sensor, climate, device_tracker, etc) or possibly even its platform.

This is the name of whatever caused the state-change. In Home Assistant, this would be the entity’s object_id (or entity_id).

The device that caused the state-change is an object with properties and methods. This reports the object’s method that was responsible for the state-change. Owing to architectural differences, I can’t think of an equivalent in Home Assistant.


This is definitively needed!

Sometimes something triggers and I want to know who or what triggered it.

For my tuya devices I wrote my own little solution here. It runs a thread per device monitoring how the state was changed; via the tuya device (button press) or via mqtt (ha automation). Atleast I am now able to use the wifi-switch also for presence detection.

Out of nowhere my bedroom lights went on in the middle of the night. It would have been nice to know what triggered it.

I think HomeKit integration went haywire but I don’t have a way to probe it. It would have been nice to know if it was that or UI or AppDaemon web socket, automation, deconz integration, or what… Worse case I had my home assistant hacked and I’m not even aware.

I hope this feature gets prioritise because it would really help to detect unusual activity and keep my mind at ease.


It’s been two years since this topic was created. Since then, some visibility into what triggered an automation is provided by its trace.

Feels like we need to up this vote folks! This would be a great addition to the attributes list, and help keep track of entity changes.