Both of the feature request, can be done with other tools, but I am just thinking that maybe HA can do this natively, in the future…
You can get this information right now with the context object in templates (and condition off it)
It can. Context object. It’s just not available with ‘simple conditions’, only via templates.
Can you please show me how? Thanks
take a look at this thread
Uffff… I think that my solution it is easier, till HA decides to add something natively 
ok… I can tell you 100%, this will not be added to triggers. It will be added as a condition. And I think you need to re-evaluate the meaning behind ‘natively’, because home assistant can do this right now. I.e. Home assistant natively tracks what automation/script enacted a change and you can access it. I think you may just mean “Until it’s added to the UI in an easy-to-use function”.
My issue is that I have not understood very good how to use this Context object… 
Lets say that I have a switch (S) and two automations (A and B). How can I make a 3rd automation which will change the state of my switch S, depending of what automation change the state of my switch? How the template condition with this “Context Object” should look?
Thank you!
The link i provided does exactly that. I’m pretty sure you didn’t bother to read any of it, so here’s the exact exerpt:
- condition: template
value_template: "{{ trigger.to_state.context.id != states.automation.kuche_bewegung.context.id }}"
All you have to change is the automation in that condition.
As for this WTH #feature-requests, I’ve been planning on adding this functionality to core myself and it’s on my list. It does require some changes to helper functions if we want it to be added both in triggers and conditions.
Ultimately, my plan is to have a condition where you select a list of users, automations, scripts, or scenes.
1 Like
- make an automation that triggers when the switch changes. Doesn’t need to do anything else
- while logged in, toggle the switch
- open the trace of the automation, click the circle for the trigger
- switch to the ‘changed variables’ tab
- copy the value in
trigger.to_state.context.user_id - add a condition of
{{ trigger.to_state.context.user_id in ['<paste user id>'] }} - repeat for each user you want the automation to run for and add them to the array in the template
Pretty sure you can also get this user id from somewhere in .storage but I forget where.
Not sure how the variable solution could work (or why you’d need a variable when an input_text can hold a username just fine). How do you determine who triggered the automation if you don’t look at context?
2 Likes
it’s on persons
1 Like
“An automation that monitors what other automations do to a switch.”
What’s the application for this arrangement?
I opened the link before but I didn’t understood too much from it… I’m a newbie, so… please bare with me
It could be nice, as a condition, like you said. This should be the perfect solution. Till then, I will try with this content object. Thanks
If I have two automations and both have this switch inside but each one have different other actions, I want to make another automation which can trigger something different based on who changed that switch which is in both automations…
I am trying to understand what that template does exactly but it is over me 
I understand that it is checking an ID to not match the other ID, but it is way over me with this For this I should know what an context id is, how it is working…
I think I will be stuck with my old solution… I added a variable to both automations, next to the switch I look and this variable will change it’s value depending of what automation will change the switch state, then I added the 3rd automation and I check from where the value came…
the id is just a unique identifier. You don’t even need to know what it is. All you need to know is to compare the trigger’s context.id to the automation’s context.id. When something is triggered, it has context on what triggered it. If you compare the context from the trigger to an automations context and they are the same, then you know that automation triggered this automation.
Post the two automations.
There are far more details than just two automations… to understand the actions in this case, I will try to explain you with more details…
This has everything to do with turning on / off my computer…
I can turn off/on my computer in three modes:
- PIN code with Alarmo (armed_away will turn ON my PC, disarm will turn it OFF)
- Webhook from my phone (turn on or off my computer)
- Start/Shutdown from my computer (normal shutdown or hardware buttons)
More than that, HA will know every move, if I shutdown my computer, if restart, hibernate, everything… So there are more things with this, but I will only give you the power on / off actions
Now, to have all these modes connected and synchronized, in order to have every used entity to the proper state, I need to make some automations, for Alarmo to know if the switch state came from him or from another automation… more than that, Alarmo should know if I cancelled the shutdown, in order to get its state back… and so on… (My computer it is not shutting down instantly if I click shutdown… I have 5 seconds after I clicked ShutDown, time to change my mind for this action and then I can cancel it or aprove the action as getting shutdown or not.
This automation is for Alarmo, in order to tell him that the action of shutdown, was cancelled (eventghost and custom scripts/apps are used as well)
alias: WebHook2Action - Computer Power PIN Cancel
description: ""
trigger:
- platform: webhook
webhook_id: >-
computer_off_cancel_windows
condition: []
action:
- if:
- condition: state
entity_id: alarm_control_panel.computer_power
state: armed_away
then:
- service: variable.set_variable
data:
variable: computer_power_pin
value: initial
else:
- service: variable.set_variable
data:
variable: computer_power_pin
value: cancel
- service: alarmo.arm
data:
entity_id: alarm_control_panel.computer_power
code: "1234"
mode: single
So, if the variable have the value “cancel”, it will tell to Alarmo that I have cancelled the shutdown and it can get its state back, as armed_away (pc on)
This one is to make Alarmo knowing the state of my computer, even if it was powered on/off from other modes (like the hardware power button of my computer or phone)
alias: Data2Var - Computer Power PIN State
description: ""
trigger:
- platform: state
entity_id:
- variable.computer
to: "on"
from: "off"
id: computer-status-on
alias: If Computer Status changes from Off to On
- platform: state
entity_id:
- variable.computer
to: "off"
from: "on"
id: computer-status-off
alias: If Computer Status changes from On to Off
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: computer-status-on
alias: Computer Status to ON
- condition: state
entity_id: alarm_control_panel.computer_power
state: disarmed
sequence:
- service: variable.set_variable
data:
variable: computer_power_pin
value: power_on
- service: alarmo.arm
data:
entity_id: alarm_control_panel.computer_power
code: "1234"
default: []
- choose:
- conditions:
- condition: trigger
id: computer-status-off
alias: Computer Status to OFF
- condition: state
entity_id: alarm_control_panel.computer_power
state: armed_away
sequence:
- service: variable.set_variable
data:
variable: computer_power_pin
value: power_off
- service: alarmo.disarm
data:
entity_id: alarm_control_panel.computer_power
code: "1234"
default: []
mode: parallel
max: 2
And this one is the Alarmo automation, which does all the things, where Alarmo knows from where the command came and how its state should be, regarding the other details…
alias: Auto - Computer Power PIN
description: ""
trigger:
- platform: state
entity_id: alarm_control_panel.computer_power
id: online
to: armed_away
alias: If Computer Power PIN changes to Online
- platform: state
entity_id: alarm_control_panel.computer_power
id: offline
to: disarmed
alias: If Computer Power PIN changes to Offline
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: online
sequence:
- choose:
- conditions:
- condition: state
entity_id: variable.computer_power_pin
state: cancel
sequence:
- service: alarmo.arm
data:
entity_id: alarm_control_panel.computer_power
code: "1234"
- service: variable.set_variable
data:
variable: computer_power_pin
value: initial
- conditions:
- condition: state
entity_id: variable.computer_power_pin
state: power_on
sequence:
- service: alarmo.arm
data:
entity_id: alarm_control_panel.computer_power
code: "1234"
- service: variable.set_variable
data:
variable: computer_power_pin
value: initial
- conditions:
- condition: state
entity_id: variable.computer_power_pin
state: initial
sequence:
- service: switch.turn_on
data: {}
target:
entity_id: switch.computer_1_power
- conditions:
- condition: trigger
id: offline
sequence:
- choose:
- conditions:
- condition: state
entity_id: variable.computer_power_pin
state: power_off
sequence:
- service: alarmo.disarm
data:
entity_id: alarm_control_panel.computer_power
code: "1234"
- service: variable.set_variable
data:
variable: computer_power_pin
value: initial
- conditions:
- condition: state
entity_id: variable.computer_power_pin
state: initial
sequence:
- service: switch.turn_off
data: {}
target:
entity_id: switch.computer_1_power
mode: parallel
max: 2
This is just an example, but I find far more things to do if I can know which automation/script/switch has changed the state of another entity…
What exactly do you mean by “switch state”? Do you mean “state-change” like when a variable entity’s state value changes?
If I have understood the automations you posted, they use variable entities as a means of communicating information to one another.
if the variable have the value “cancel”, it will tell to Alarmo that I have cancelled the shutdown and it can get its state back, as armed_away (pc on)
Is the goal of your Feature Request to use another way, other than variable (a custom component), for one automation to know what another automation did?
The goal is to use these automations in an easier way, not with custom variable addon.
If I could use a “choose” action in alarmo automation, telling to do something based on which automation changed the state of alarmo, I could avoid using this communication from one to another through variable component.
Look, if I could use these information in automations, it will achieve what I am trying to do…
It’s currently possible to achieve the same thing using a Helper or a Template Sensor; the use of a custom variable add-on isn’t required.
Or you could consolidate the automations to eliminate the need for inter-automation messaging.
As already mentioned, you can experiment with context to determine the source of the automation’s trigger. The table in the following post might be helpful: