State.context to UI automation

So maybe I should rephrase my whole topic? To be more like: UI option what the cause of an entity to change state is?

To be honest now my topic just releases a discussion about how to use context or what context can do for me. But as I understand correctly context is not what I need.

You can only check if it was a dashboard action, and automation or a physical control.

Which is exactly what I want. But I want to be able to use it from the UI. I’m no programmer. Templating gives me the creeps.

Ok, that’s fine. But you still haven’t explained where you want to use it in the UI. Condition? Trigger? Action?

This is why I siad:

because this quote below does not fit into anything that HA can do without templates.

Long story short, HA can already get the context out with templates.

If you want to use it as a condition, that can be built pretty easily. However if you want to use the context in a message… well, you have to use templates as there’s no way to “Get information” in an automation without using templates.

If you want to have something in a trigger, that can probably be built too pretty easily. But circling back, using that info later in the automation will force you to use templates.

TLDR: The only way to get ANY information out to use in an automation is through templates, which can already do this.

I explained my use case. And for now I would settle with the condition of an automation. In the future maybe also in the choose of an action too.

But my feature request is not about how to do it (because it is clear to me that it can be done with templating), it is about to be able to do it in the UI without any templating knowledge. Just like some other features you can do in the UI these days. Which weren’t possible in the past.

I’m just hoping some developer sees this as useful and easy to implement for a future iteration of the automation UI. I can imagine other people have use cases for this since there are a lot of people having automations and dashboards with switches to change entities.

Chooses and conditions would go hand and hand. They use the same code.

And this simply won’t be possible in messages, which would be the other place you’d want to use it outside of triggers and conditions.

The best case you’ll get here is a simple template variable that contains the context in a friendly manner without writing code. Unfortunately, if you want to use custom messages with information extracted from the automation/script, you’ll need to use templating. That’s why templating was added into HA in the first place.

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.

Screenshot 2022-06-21 081430

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
11 Likes

Thank you very much for taking the time to respond. @tom_l provided the information I was missing.

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!