Trigger-based binary sensor: icon is set in opposite way - BUG?

[Ildar_Gabdullin]

Consider this template sensor:

template:
  - binary_sensor:
      - name: testing_binary_sensor
        state: >-
          {{ states('input_boolean.testing_binary_sensor') }}
        icon: >-
          {% if is_state('binary_sensor.testing_binary_sensor','on') -%}
          mdi:shield-check
          {%- else -%}
          mdi:shield-off
          {%- endif %}

The "icon" is either “mdi:shield-check” when ON or “mdi:shield-off” when OFF.
Works fine.

Now this trigger-based sensor:

  - trigger:
      - platform: state
        entity_id: input_boolean.testing_binary_sensor
    binary_sensor:
      - name: testing_binary_sensor_trigger
        state: >-
          {{ states('input_boolean.testing_binary_sensor') }}
        icon: >-
          {% if is_state('binary_sensor.testing_binary_sensor_trigger','on') -%}
          mdi:shield-check
          {%- else -%}
          mdi:shield-off
          {%- endif %}

or - with using “this”:

  - trigger:
      - platform: state
        entity_id: input_boolean.testing_binary_sensor
    binary_sensor:
      - name: testing_binary_sensor_trigger_use_this
        state: >-
          {{ states('input_boolean.testing_binary_sensor') }}
        icon: >-
          {% if is_state(this.entity_id,'on') -%}
          mdi:shield-check
          {%- else -%}
          mdi:shield-off
          {%- endif %}

And how these sensors change their icons in this card:

type: entities
entities:
  - input_boolean.testing_binary_sensor
  - binary_sensor.testing_binary_sensor
  - binary_sensor.testing_binary_sensor_trigger
  - binary_sensor.testing_binary_sensor_trigger_use_this

Why an icon is set in opposite way for trigger-based sensors?

Templates for “icon” seem to be OK:

Update:
the same bug happens with this another version with using “this”:

        icon: >-
          {% if this.state == 'on' -%}
          mdi:shield-check
          {%- else -%}
          mdi:shield-off
          {%- endif %}

[Ildar_Gabdullin]

Anyone may have an answer?

[petro]

It’s referencing the state in the state machine, which is the previous state. Use the trigger object instead.

[Ildar_Gabdullin]

Previous - because this is a trigger-based sensor?
Why “this.state” refers to the current state in non-trigger-based sensors, and here it refers to the previous state?
I remind you that this is an “icon” attribute which is supposed to be set dependingly on some template - and in my example it must be set dependingly on “this.state” - which is a CURRENT state.

[petro]

Because trigger based templates resolve at the exact same moment, where non-trigger based ones resolve when they resolve.

[Ildar_Gabdullin]

Not getting your last post.
Can an attribute of a trigger-based sensor change independently on a defined trigger - i.e. a sensors state is resolved after a trigger, an attribute is resolved at any other time when it’s template is changed?
Or attributes & a state are only changed right after trigger?

[petro]

Trigger based template entities resolve all fields (templates) at the moment the trigger occurs.

Non-trigger template entities have listeners for each field (template) and they each update independently. IIRC there’s a priority order as well that’s applied.

[Ildar_Gabdullin]

@petro

resolve all templates at the moment the trigger occurs.

i.e. for all attributes too?imeans - attributes may not be updated on theor own ways asynchronously?

[petro]

For all templates in the template entity.

[Ildar_Gabdullin]

I see. I need to review my trigger-based sensors.
Thank your for explanations.

[Ildar_Gabdullin]

So, using “this” in trigger-based sensors always refers to the previous state.
Then this must be described in Docs.

[petro]

This always references the previous state, it just happens to work in non-trigger based template entities with attributes because the attributes resolve after the state does. I.e. if you use this.state in your state template, it’s going to be the previous state.

[Ildar_Gabdullin]

@petro

I.e. if you use this.state in your state template, it’s going to be the previous state.

In my tests with non-trigger-based sensors, if I use this for an “icon” or any other attribute - it refers to the CURRENT state. At least these attributes are set properly.

[petro]

@Ildar_Gabdullin

In my tests with non-trigger-based sensors, if I use this for an “icon” or any other attribute - it refers to the CURRENT state.

Again, that’s only because templates resolve in the following order: availability → state → everything else. And because these each have their own listener, the state machine is updated during that process.

[123 (Taras)]

FWIW, this.state contains the previous state value and a common usage is to report a sensor’s previous state if its current state is not something you want (like undefined, non-numeric, zero, etc).

Examples

How to trigger an automation based on temperature hysteresis

Create a Template Sensor that reports the current value of the “cold” sensor except when the value is unavailable (or unknown). In that case, the Template Sensor reports its existing value (which represents the “cold” sensor’s previous value). template: - sensor: - name: Enhanced Cold Sensor state: > {% set t = states('sensor.your_cold_sensor') %} {{ t if t | is_number else this.state }} device_class: temperature unit_of_measurement: '°C'

Problem with wall switch connected to relay controller

Replace this: value_template: '{{ value_json.input1.on }}' with this: value_template: '{{ value_json.input1.on if value_json.input1 is defined else this.state }}'

---

This would be useful somewhere in the documentation (I learned it empirically):

@petro

templates resolve in the following order: availability → state → everything else

[petro]

Just do a test real quick, you’ll see that I’m right. Put this.state inside the state: template (not an attribute template). It will always be the previous state.

[Ildar_Gabdullin]

Then probably this must be better explained in Docs here:

Will try to propose my corrections.

[petro]

@123

This would be useful somewhere in the documentation (I learned it empirically):

I’d have to look at the code again to give the real order. Off the top of my head, I know availability → state are the first 2. The order is buried in the code and I don’t have access to an IDE with the code at the moment.

[Ildar_Gabdullin]

@petro

this.state inside the state: template

Here I agree, noticed some day - explained it myself like “cannot refer to myself since not updated yet”.
But for attributes I believed that I can safely use “this”.
Now this is explained by that “availability → state → everything else” sequence.

As for trigger-based sensors - I was sure that only states are updated after trigger, and all attributes are updated like other template sensors…
OK, need to review some my sensors. Thanks a lot!

[Ildar_Gabdullin]

@123

this.state contains the previous state value and a common usage is to report a sensor’s previous state if its current state is not something you want (like undefined, non-numeric, zero, etc).

This is the only case when I use “this” in a state definition, like:

state: >-
  {% set VALUE_FROM_DEVICE = state('sensor.some_device') -%}
  {%- if VALUE_FROM_DEVICE in ['unavailable','unknown'] -%}
  {{ states(this.entity_id) }}
  {%- else -%}
  {{ VALUE_FROM_DEVICE }}
  {%- endif %}