Templated binary sensor: too simple, but with an interesting glitch

Consider this sensor:

      - name: testing_2_flags
        state: >-
          {{ states('input_boolean.testing_boolean') }}

I expect this sensor to repeat the “input_boolean” state - and it works.

Next, I want to add a logic: the sensor repeats “testing_boolean” - unless it is forced to ON by “testing_boolean_2”:

      - name: testing_2_flags_1
        state: >-
          {{ states('input_boolean.testing_boolean') or
              is_state('input_boolean.testing_boolean_2','on') }}

and an alternative version:

      - name: testing_2_flags_2
        state: >-
          {{ is_state('input_boolean.testing_boolean','on') or
              is_state('input_boolean.testing_boolean_2','on') }}

And these sensors behave differently:
изображение

i.e.:

on or True -> on
off or True -> off
on or False -> on
off or False -> off

True or True -> on
False or True -> on
True or False -> on
False or False -> on

I see that I should use the 2nd variant.
But the 1st variant LOOKS like a working too - until you start testing it.

Why do we have a different logic here?
Probably because I am comparing values of different types - “on/off” & “True/False”.
But my dark C/C++ past is telling me that “off or True” is supposed to be resolved as “True” and then presented as “on”.

Exactly.

The template for sensor.testing_2_flags_1 is logically ORing a string and a boolean. The result is the string value.

Logically ORing two booleans produces expected results.

1 Like

This is the kind of situation the Bool function was made for.

1 Like

Very impressive demonstration.
Honestly, I believed that would return a True too.
I am still not getting anyway why “cat or True” returns “cat” - but I will call it a “jinja-way”.

Exactly!

Thanks a lot, guys.