I don’t know why we are talking about messages. I’m not talking about it. I just want to be able to except some automations from executing if a entity switch on my dashboard is flipped by a user.
Ok, and here we are 20 posts later and you finally gave out the actual Feature Requests.
You want to be able to use the context as a condition in automations and scripts without templates.
That’s why I’ve been saying…
There’s hundreds of different ways to use context in an automation through templating. Conditions are but a small aspect of it. This is why I’ve been trying to get your exact use case out. Because you’re not explaining yourself well, and there’s hundreds of different ways this Feature Requests can be interpreted.
Well maybe I’m just bad at explaining. And also not fully understand what context can do more then what I need it for.
This nugget was very useful, thank you! With this I can now differentiate the 3 ways a device’s state was changed.
Here is a sample implementation using the choose action:
trigger:
- platform: state
entity_id:
- switch.office
condition: []
action:
- choose:
- conditions:
- condition: template
value_template: '{{ trigger.to_state.context.id != none }}'
- condition: template
value_template: '{{ trigger.to_state.context.parent_id == none }}'
- condition: template
value_template: '{{ trigger.to_state.context.user_id == none }}'
sequence:
- service: system_log.write
data:
level: debug
message: Physical device
default: []
- choose:
- conditions:
- condition: template
value_template: '{{ trigger.to_state.context.id != none }}'
- condition: template
value_template: '{{ trigger.to_state.context.parent_id == none }}'
- condition: template
value_template: '{{ trigger.to_state.context.user_id != none }}'
sequence:
- service: system_log.write
data:
level: debug
message: HA user interface
default: []
- choose:
- conditions:
- condition: template
value_template: '{{ trigger.to_state.context.id != none }}'
- condition: template
value_template: '{{ trigger.to_state.context.parent_id != none }}'
- condition: template
value_template: '{{ trigger.to_state.context.user_id == none }}'
sequence:
- service: system_log.write
data:
level: debug
message: HA automation
default: []
mode: restart
14 Likes
In the UI, Event trigger have context input (Limit to events triggered by user)
You can read in the doc (https://data.home-assistant.io/docs/context/) context exist for events AND states
Why there is not the same input/field for the state trigger ?
I made 2 design to use the context in UI.
The user input is to choose user_id (Any user for != none and No user for == none), the original trigger is to choose parent_id (itself for == none, Automation/Script for != none)
3 Likes
This would be very helpful, and I think modeling the UI similar to the existing event UI makes the most sense. The only addition I would make would be to add None to the trigger dropdown for cases where the change occurred outside of HA (someone interacted with the physical device).
Does something changed till this time? Automation related events, drops physical output for me now.
I am using the exact conditions listed above to detect physical operation of my light switches. Still works perfectly.
Yes, physical & UI opertation works fine, but automation related drops also physical for me.
Could you try rephrasing this or giving an example?
I don’t understand what you mean.
I’ve triggered an automation by time, to flip the test switch in the code, and the result was Physical device, not HA automation. I’ve expected the HA automation output not Physical device.
For some strange reason if I trigger it with a motion sensor it gives me HA automation output.
time triggers don’t have context. The result will always be none, none, none.
2 Likes
Ah, that is the explain it! Many thanks!
Yeah this will not work for all automation triggers. The trigger has to have an entity or device it can call a parent, so context.parent_id is available for:
- Event trigger
- Home Assistant trigger
- MQTT trigger
- Numeric state trigger
- State trigger
- Sun trigger
- Tag trigger
- Template trigger
- Time trigger
- Time pattern trigger
- Persistent notification trigger
- Webhook trigger
- Zone trigger
- Geolocation trigger
- Device triggers
- Calendar trigger
- Sentence trigger
This is an untested list and based on my understanding of how the parent context id is generated.
2 Likes
I believe this might have fixed a race condition I had which was caused by an online-only integration sometime responding slowly. I’ll report if I have any issues. Thank you to everyone who has contributed!
Thanks for documenting this @mbuscher.
I have the automation working when I press the physical wall switch on my Fibaro switch device.
My question is where are the log entries written? I can’t see them in the System Log or the Logbook. Is there a config you have to do to see the Debug entries?
Another question: How you recommend using this physical switch detection method in a lighting automation to switch that automation to a ‘manual mode’ that disables the motion-based triggers until the physical light switch is turned off again?
Those DEBUG messages nowadays should appear after pressing the LOAD FULL LOGS button of HOME ASSISTANT CORE under System → Logs. Sorry, I currently don’t have any actual DEBUG messages set up but the following screen shots should give you an idea.
Re 2nd question: in the past I used one of the state machines of node-red for this kind of logic. Don’t have it anymore as it got too complicated for simple me.