Trigger sensor: using "trigger" variable - "trigger.to_state.state" vs "states(...)"

Consider this trigger-based template sensor:

template:
  - trigger:
      - platform: state
        entity_id: sensor.x
    sensor:
      - name: z
        state: >-
          ... use trigger.to_state.state ...

I learnt that using “trigger.to_state.state” variable is better than using this:

        state: >-
          ... use states('sensor.x') ...

State objects are not 100% clear for me so I wonder - will these 2 variants give same results?

And here is the next question - consider a trigger with 2 entities:

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.x
          - sensor.y

How shall I address them?
This way?

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.x
          - sensor.y
    sensor:
      - name: z
        state: >-
          ... use states('sensor.x'), states('sensor.y') ...

Or this way?

template:
  - trigger:
      - platform: state
        entity_id:
          - sensor.x
          - sensor.y
    action:
      - variables:
          VALUE_X: >-
            {% if trigger.entity_id == 'sensor.x' -%}
              {{ trigger.to_state.state }}
            {%- else -%}
              {{ states('sensor.x') }}
            {%- endif %}
          VALUE_Y: >-
            {% if trigger.entity_id == 'sensor.y' -%}
              {{ trigger.to_state.state }}
            {%- else -%}
              {{ states('sensor.y') }}
            {%- endif %}
    sensor:
      - name: z
        state: >-
          ... use VALUE_X, VALUE_Y ...

Made a quick test - it shows that both ways (“trigger.to_state.state” and “states(…)”) give same result…

1 Like

states() will query the state object at the time the template is rendered. The trigger object is instantiated at the time the trigger is fired and will not change after that (until the trigger fires again). There is less processing overhead referencing the trigger object.

If you want to reference two sensor triggers separately, use two sensor triggers with trigger id’s:

template:
  - trigger:
      - platform: state
        entity_id: sensor.x
        id: sensor_x
      - platform: state
        entity_id: sensor.y
        id: sensor_y
    sensor:
      - name: z
        state: >-
          ... if trigger.id == 'sensor_x' ...

Interesting, have not thought about it.

Good.

Imho it is similar to what I proposed:
use variables for “sensor.x” & “sensor.y” - and set these vars dependently on the current trigger.
I.e. - these are similar:

if trigger.entity_id == 'sensor.x'
if trigger.id == 'sensor_x'

Or am I wrong?

They are very similar but I used a poor example.
The primary benefit of using trigger_id is you to only have to reference the entity_id in a single location in your code. This makes maintaining and reusing code much easier. The second, smaller, benefit is it can also make your code more readable, especially if you don’t rename your entity_id’s.

if trigger.entity_id == 'sensor.tuya_a3gh87de_2'
if trigger.id == 'water_temperature'

I see, thanks for clarifications!