Trying to use templates in a condition:

Configuration
,
1

Good morning all.

This is my first post. I have been using ha for about 5 years now and have managed to get this far.

My problem now is I purchased some tuya, wifi, battery door sensors. To preserve battery life, they become unavailable shortly after they report a “state change”. It does appear that every once in a while they wake up and report in.

So what I wanted to do, is keep their state locally so I created accompanying input_boolean for each sensor. IE: binary_sensor.front_door => input_boolean.st_front_door.

Since I will have about 12 of these suckers, I wanted to create a trigger to handle all 12.

The trigger works pretty good, but I wanted to add a condition to not attempt to change the stated, if it hasn’t changed. (Condition 2 below) But I find the proper bracketing/quoting to make it happen.

Any insight would be appreciated.

Thanks.

- id: '1675698867270'
  alias: "Trigger for door traps"
  description: When a door trap changes state, set a corresponding input_boolean to hold the state
  trigger:
  - platform: state
    entity_id:
    - binary_sensor.glass_wall
    - binary_sensor.master_slider
    - binary_sensor.guest_slider
    - binary_sensor.front_window
  condition:
    condition: and
    conditions:
    # 1) make sure we are not going to try and change the state to "unavailable"
    - condition: template
      value_template: '{{ trigger.to_state.state in [''on'',''off''] }}'
    # 2) only change the state holder if the state truly changed.
    - condition: template
      value_template: "{{ ((trigger.to_state.state)) != {{input_boolean.st_((trigger.to_state.attributes.friendly_name)).state}} }}"
  action:
  - service: input_boolean.turn_{{trigger.to_state.state}}
    data_template:
      entity_id: input_boolean.st_{{trigger.to_state.attributes.friendly_name}}
  - service: notify.email_bb
    data:
      title: Trigger for door traps
      message: "Setting input_boolean.st_{{trigger.to_state.attributes.friendly_name}} to {{trigger.to_state.state}}"
  mode: single
2 
  trigger:
  - platform: state
    entity_id:
      - binary_sensor.glass_wall
      - binary_sensor.master_slider
      - binary_sensor.guest_slider
      - binary_sensor.front_window
    to:
      - 'on'
      - 'off'
    not_from:
      - 'unknown'
      - 'unavailable'

Then you can lose the conditions. Documented here.

Alternatively, fixing the statement you posted:

value_template: >-
   {{ trigger.to_state.state !=
      states('input_boolean.st_' ~ trigger.to_state.attributes.friendly_name) }}
3

Thanks Troon. I used the value_template code that you suggested. I gather the “~” is concatenate two strings.

4

Correct. In my opinion though, it’d be much more elegant to include the trigger changes I suggested and get rid of the conditions altogether.

Note that even if you do keep the conditions, you don’t need these two lines:

    condition: and
    conditions:

as conditions are AND by default.

5

I was not aware that you could have multiple “to:” values so that’s a plus but the other condition is to stop false triggers. It seems that the sensors from time to time wake up and broadcast their state, so by evaluating the sensor state to the “last recorded state” it just avoids calling the actions for nothing.

6

Try it. I don’t believe that your sensors republishing the same state will trigger my trigger.

They might have triggered your original if they have attributes that were updated too, but with to: etc specified, it should only trigger on a genuine state change between on and off, in either direction.

7

I did try the “not_from:” statement, but 99% of the time, the sensors are “unavailable” prior to changing their to either ‘on’ or ‘off’ .

8

Oh, I see: because they’re asleep most of the time — so my suggestion wouldn’t trigger a lot of the times you would want it to.

9

I noticed (after a cup of coffee) that this morning when I opened a few doors and I did not get notified. So I think the original condition will prevent unwanted notifications.