Awesome Switch triggered_by Attribute For Happy Automations!

Feature Requests
#1

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.

#2

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

1 Like
#3

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

#4

https://lmgtfy.com/?q=Home+assistant+context

1 Like
#5

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
#6

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

#7

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

Anyone knows if this was implemented?

https://data.home-assistant.io/docs/data_context 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)

#8

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

#9

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
  trigger:
    platform: state
    entity_id: switch.kitchen
    to: 'on'
  action:
    service: notify.notify
    data_template:
      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
#10

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.

2 Likes
Any way to know what triggered a state change?
#11

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:

sysevent.srcElement.Class.Name
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.

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

sysevent.srcProperty.Name
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.

2 Likes
Home Graph Solid Base For 1000+ Items
Garage Door Opener - Best brand motor and controller
#12

This is definitively needed!

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

#13

For my tuya devices I wrote my own little solution here. https://github.com/TradeFace/tuyamqtt 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.