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