All the ways of knowing who performed an action over a switch (for example) are really cumbersome. Why not have a sensor??
Because it’s not just “who”.
It can be changed by
- A user from the dashboard,
- an automation, or
- the physical device.
All three are available to check using context. Though I agree this is cumbersome. A simpler method is required.
Don’t forget to vote for your own request.
5 Likes
I agree it is cumbersome and could be improved, so I also voted even though as @tom_l says, it can be done.
See below for another example showing how you can do that. I use this to check if a window screen closing was done ‘manually’ (via a physical button or via my home assistant GUI, but not via an automation). I then sent out an event and start a timer, both of which I can use in other automations (like checking if they should be automatically opened again).
alias: Zonwering changed by button press or UI
description: Detect if zonwering is changed by a button or the UI
mode: parallel
trace:
stored_traces: 50
max: 5
triggers:
- entity_id:
- cover.zonwering_slaapkamer
- cover.zonwering_woonkamer_beneden
- cover.zonwering_eetkamer
- cover.zonwering_woonkamer_boven
- cover.zonwering_vide
from: null
to: opening
id: opening
trigger: state
- entity_id:
- cover.zonwering_slaapkamer
- cover.zonwering_woonkamer_beneden
- cover.zonwering_eetkamer
- cover.zonwering_woonkamer_boven
- cover.zonwering_vide
from: null
to: closing
id: closing
trigger: state
conditions:
- alias: Not from an automation
condition: template
value_template: "{{ trigger.to_state.context.parent_id is none }}"
actions:
- alias: Send event based on button press or UI
choose:
- conditions:
- condition: trigger
id:
- closing
- opening
sequence:
- event: zonwering_manual
event_data:
entity: "{{ trigger.entity_id }}"
type: ui
target_state: "{{ trigger.to_state.state }}"
- metadata: {}
data:
duration: "03:00:00"
target:
entity_id: timer.zonwering_handmatig_naar_beneden
action: timer.start
That’s overly complicated, this does the same thing
alias: Zonwering changed by button press or UI
description: Detect if zonwering is changed by a button or the UI
mode: parallel
trace:
stored_traces: 50
max: 5
triggers:
- entity_id:
- cover.zonwering_slaapkamer
- cover.zonwering_woonkamer_beneden
- cover.zonwering_eetkamer
- cover.zonwering_woonkamer_boven
- cover.zonwering_vide
from: null
to:
- opening
- closing
trigger: state
conditions:
- alias: Not from an automation
condition: template
value_template: "{{ trigger.to_state.context.parent_id is none }}"
action:
- event: zonwering_manual
event_data:
entity: "{{ trigger.entity_id }}"
type: ui
target_state: "{{ trigger.to_state.state }}"
- metadata: {}
data:
duration: "03:00:00"
target:
entity_id: timer.zonwering_handmatig_naar_beneden
action: timer.start
Yeah, now you mention it, you’re right, maybe not the best example. It’s this way because it started out very different and I didn’t bother ‘cleaning it up’.
That could useful - basically have some easy-to-use metadata per state change indicating if it came from:
- the device (ex: physical button press)
- a user (with user name and optionally dashboard ID or UI element ID , if not using API)
- automation (with the automation id)
it could help some automations be cleaner and easier to read and write (like linking on/off states of multiple entities) and it is just interesting for auditing or fun stats (which user uses which device).
If that is already possible without much hassle - at least document it well or have a helper function for easy access
My issue with that solution is that you can only access the values if you use it as a trigger for the automation. I want to access it at any time.
One of the use cases I have are external lights. I will turn them on when a person is detected by frigate, and turn back off when there’s no person. However, I don’t want to turn off automatically IF I turned it on “manually”. The only way I figured you can achieve this currently is either by using an auxiliar entity, or by turning on and waiting to turn off within the same automation, which is really fragile (and more importantly: not resilient).
In any case, thanks for your time to check this out.
Using an automation?
BTW I am not arguing against this WTH. I voted for it. The method we have now is cumbersome as I noted.
1 Like
Yes, using an automation.
Yeah I understand you are not arguing against 
I was just elaborating on my problem.
Cheers
Can you elaborate on how such a sensor would be used?
To me it’s useful in notifications, like knowing who armed the alarm (if not armed by a remote), or who turned the guest mode on, or who changed the morning routine settings. Things like that.
3 Likes
The use case I have is using it as a condition for an automation. I allow modification of scenes based on input from the UI (I.e. a user will be attached to the context). This allows automations to behave like normal however users can override the interactions because I know it’s them making the modifications.
I’m currently using templates to figure out the user. I’ve also helped out a ton of beginners add these to their automations. Bare minimum, a “who/what triggered the automation” condition would go along way. This is where I see most people requesting help with context.
5 Likes
My current scenario:
- [Trigger] Person occupancy changes from clear to detected
- [Conditionals] It’s dark and the light is off
- [Actions]
i. Turn the light on
ii. Wait until [person occupancy changes from detected to clear]
iii. Turn the light off
(Note that this is a much simplified version than my actual automations; I’m also doing a delay, checking to see if it’s not dark anymore, and have a few other triggers)
To:
Automation A
- [Trigger] Person occupancy changes from clear to detected
- [Conditionals] It’s dark and the light is off
- [Actions] Turn the light on
Automation B
- [Trigger] Person occupancy changes from detected to clear
- [Conditionals] The light is on && the light was turned on by an automation
- [Actions] Turn the light off
1 Like
While I also started using the context data to check if it was
- physical device
- Automation
- User Interface
I came with a bug where triggered by assist gets handled as physical device. Is that only me or can someone else check that? I created also a bug ticket but no one replied until now.
Really breaks some thing for my and that means my wife is not happy 
I think the whole “reverse engineer the context data” is kind of a hack and not really how it is intended to be used.
In the linked thread it is discussed that this does not work for many kinds of triggers. (https://community.home-assistant.io/t/state-context-to-ui-automation/427861/36)
1 Like
In the event context you have a user_id field that you can use.
When I press my mobile button it triggers not only the light I set in my automation but another light as well.
I looked into all my automations and my Appdaemon Apps and none is connected to that button+that light.
When looking at the device HA confirms it:
In the log book there is not much about what triggered the On state:
It would be so nice to have something:
- triggered by Automation “xxx”
- triggered by device
- triggered by scene “xxx”
- triggered by script “xxx”
- triggered by restart
- …
1 Like
+1.
Also like to use this as a condition in my automations!
1 Like
There’s already a popular WTH about this:
Logbook already shows what triggered what. Not sure what’s going on in your home but it may be an issue at a level lower than HA.
1 Like