Using context

Configuration
,
1

I want to use context information as explained here

How to use context - Community Guides

and here

State and state object

Background: I want to find out who switched on or off an entity, e.g. light or thermostat etc.

In the current case I use the scheduler extension to switch thermostats on and off and set the temperature. But of course, sometimes a person changes a thermostat physically at the device itself. In that case I want to pause the scheduled actions for a while and then resume later.

However the scheduler extension does not provide a context_id which is why I submitted a feature request at github: scheduler-component

Further testing with a helper schedule and also a calendar entry showed, that it is important how you retrieve the context information while keeping in mind that for some automation triggers there is no identifiable parent as listed here

Here is an example that shows how you get a parent_id and how you don’t with the same calendar event - even though calendar trigger has a green check mark (maybe I am doing it wrong)

This is automation code resulting in a valid trigger.to_state.context.parent_id

alias: TL1 press button by calendar state trigger
description: ""
triggers:
  - trigger: state
    entity_id:
      - calendar.calendar_push_button
    from:
      - "off"
    to:
      - "on"
    enabled: true
conditions: []
actions:
  - action: input_button.press
    metadata: {}
    data: {}
    target:
      entity_id: input_button.tl1
mode: single

in traces clicking on the action button press and reading changed variables

context:
  id: 01K9H5C6J59KJ6RDZSM53CEN89
  parent_id: 01K9H5C6J5JYAW6T60TKGYGAVH
  user_id: null

however this automation code results in null as parent_id

alias: TL1 push button by calendar trigger
description: ""
triggers:
  - trigger: calendar
    entity_id: calendar.calendar_push_button
    event: start
    offset: "0:0:0"
    enabled: true
conditions: []
actions:
  - action: input_button.press
    metadata: {}
    data: {}
    target:
      entity_id: input_button.tl1
mode: single

context:
  id: 01K9H5C581HGJ21PH3N62ZTFTK
  parent_id: null
  user_id: null

so the state trigger works and the calendar trigger does not.

Question 1: is that a bug? Or am I doing something wrong with the calendar trigger?

Question 2: can I get the context information directly from the entity as well? The logs of the entity show the context information too somehow:

image
image597×220 17.2 KB

the green dot entry shows the parent_id as state of the calendar calendar push button
the blue dot entry is missing the information that the trigger was caused by the calendar

and here the log shows with purple dot my user when I click the button on the dashboard:

image
image663×196 7.18 KB

and pink is when the scheduler extension pushes the button with no parent_id resulting in no information where the push came from - sadly :cry:

2

Answer to Question 2: can I get the context information directly from the entity as well?

Yes, you can. To access id, parent_id and user_id you have to access the state object
State and State Object - About the State Object

In my case the context information of my entity input_button.tl1 is retrieved like this:

{{ states.input_button.tl1.context.id }}
{{ states.input_button.tl1.context.parent_id }}
{{ states.input_button.tl1.context.user_id }}
3

Don’t think you need an automation to catch the information about entities changing.
Sometimes you want to know at a later point and this is how to find out:

Who flipped the switch?

{{ states.switch.<your_switch>.context.id }}
{{ states.switch.<your_switch>.context.parent_id }}
{{ states.switch.<your_switch>.context.user_id }}

# name of the user
{% set mylonguserid = states.switch.<your_switch>.context.user_id %}
{{ states.person|selectattr("attributes.user_id", "==", mylonguserid)|map(attribute="attributes.friendly_name")|first }}

So is the switch on or off now?

{{ states.switch.<your_switch>.state }}

edit: better use the the pre-defined functions to access the state.object where available
see Templating (scroll down to warning)
in our example access the state like this

{{ states('switch.<your_switch>') }}

And when was it switched?

{{ states.switch.<your_switch>.last_changed }}

in this case there is no pre-defined function like for state.
But be vary that the statement might fail during start-up of HA or even later, that is, before the state of the switch changed for the first time.

At time of writing there are only four functions to access the state object:

  1. states()
  2. is_state()
  3. state_attr()
  4. is_state_attr()

other information of state object has to be done like that:

{{ states.switch.<your_switch>.last_changed }}