In binary_sensor, even if is_state is always true or false, the template is not

[Olivier1974 (Olivier Toussaint)]

They told me that I don’t understand.
They told me that it is impossible.
They made me understand that enough is enough and I should stop talking nonsense.

Here is my binary_sensor:

binary_sensor:
- platform: template
    sensors:
      test_for_petro:
        friendly_name: Test for Petro
        device_class: power
        value_template: >
          {{ is_state('binary_sensor.smoke_1','on') }}

According to the documentation linked bellow, the template can only be true or false. Nothing else, that is impossible

Template

I quote:

If you are using the state of a platform that might not be available during startup, the Template Sensor may get an unknown state. To avoid this (…). The same would apply to the is_state() function. You should replace {{ states.switch.source.state == 'on' }} with this equivalent that returns true/false and never gives an unknown result:

{{ is_state('switch.source', 'on') }}

And this is exactly what I did, using is_state to never have an unknown status not even at startup.

But look:

Zoom

What do you see between 13:57:09 and 13:58:37?

Yes! You’re right! Unknown value.

But…, but…, that is not possible, the documentation is clear “returns true/false and never gives an unknown result:”

They told me that it was HA unable to render the template.
Once again, that can’t be the reason, even if I put rubbish as sensor, it is still rendering:

There must be something in the log according to them, here is the log at that time:

Error on retrieving data: empty response
14:12:27 – (WARNING) waze_travel_time - message first occurred at 14:02:28 and shows up 2 times

Unable to ping Kodi via websocket
14:11:22 – (WARNING) kodi - message first occurred at 13:59:23 and shows up 4 times

hci0 (C9:18:FB:E4:C9:1A): Error stopping scanner: [org.bluez.Error.Failed] No discovery started
14:01:38 – (ERROR) bluetooth

Update of sensor.ical_agenda_d_olivier_event_0 is taking over 10 seconds
13:57:38 – (WARNING) helpers/entity.py

Unable to find referenced entities switch.sonoff_1000d4aac6_1 or it is/they are currently not available
13:56:32 – (WARNING) helpers/service.py

Error while executing automation automation.gateway_tradfri_sonoff: Template rendered invalid service:
13:56:32 – (ERROR) automation

Gateway TRADFRI - Sonoff: Error executing script. Error for call_service at pos 1: Template rendered invalid service:
13:56:32 – (ERROR) automation

Can’t see anything related to my binary_sensor, nor the sensor smoke_1 it is based on here.

So, for sure, that transition to/from unknown is in the logbook, right? No, it is not.

So, is_state is robust as it is always rendering but, it is not always true or false.
Is it a problem? Yes, because I made some automation triggered on state going to off that are triggered when unknown is back to off.

Should I open an issue on the Github of HomeAssistant?

[boheme61]

You could just rewrite your automation, including “unforeseen_states” ( i.e. from On>to>Off ), beside i don’t know if you have bother to enable Debug-Level, before you consider open an issue you could, with your expertise, provide a full log, for the time-period of the “unknown” state in “History”

Do you actually had/seen any automations triggered on that “state”, when the “History” shows ( unknown>off ) ? … or is it actually History who “spooks” , and not your template-sensor ?

[petro]

Sorry man, but you still don’t understand what I explained to you.

The template itself will never be anything other than true or false. That’s it. The template. Maybe you don’t understand what I mean when I say template?

That means this:

{{ is_state('switch.source', 'on') }}

Nothing else.

The template binary_sensor has different rules. That means this:

- platform: template
    sensors:
      test_for_petro:
        friendly_name: Test for Petro
        device_class: power
        value_template: >
          {{ is_state('binary_sensor.smoke_1','on') }}

So you keep focusing on the issue being is_state when it has nothing to do with is_state.

Hopefully you can finally understand what I’m saying.

[Olivier1974 (Olivier Toussaint)]

I will enable the debug and keep the community posted (if I found where to do so).

What I see is the effect, even if nothing is in the logbook, my automation (which send a notification to my phone) is triggered as I receive the notification. Partial code:

  trigger:
  - platform: state
    entity_id:
    - binary_sensor.test_for_petro
    to: 'off'
  condition: []
  action:

I can understand and would probably accept that at startup, it could be unavailable, that could make sense even if it is not supposed to, it should keep the latest status in my opinion. But even if HA was not restarted, I have an unknown>off event at 13:58:37 and 14:58:13.

I did that automation in another way in real life, it is in another topic, using a workaround given by Taras, estimated member of this forum. But the substance of the issue was not solved hence this topic.

This automation was just to prove that I’m not crazy, that it is possible that is_state can be unknown.

If someone can give me a clear explanation, I’d be glad to hear it.

[tom_l]

The value your template must return can only be true or false.

The system may mark the binary sensor as unavailable or unknown but you can not return those states in the binary sensor template.

If you want to control the availability use the availability_template option. This template will mark the sensor as unavailable if the template resolves to false.

[Olivier1974 (Olivier Toussaint)]

Still not, if the value_template is always true or false, why is the value of the binary_sensor not always true or false?
You can repeat it as much as it is possible, I don’t get it.

[petro]

I tried explaining this to Oliver but he did not believe me and has been focusing on is_state.

I’m not sure what else I can say to get the point across because Oliver doesn’t like my response.

[petro]

Yes, it’s clear you don’t get the difference between a template and a binary_sensor template. This whole argument is a moot point until you understand the difference between a template entity and the jinja template that it uses.

[Olivier1974 (Olivier Toussaint)]

Ok, I know about the availability, I did that for my washing machine, thanks to the help received in this forum more that a year ago.

Here is just the opposite, I never want the sensor to be something else than true or false.
Hence the use of is_state that is supposed to always give a value to the sensor, never allowing it to become unavailable or unknown.

I can hear all the explanations, but if the value of the template is always true or false, according to @petro, why is the sensor itself not always true or false? Just give me some rules/circumstances/reasons why the template value is not transferred as such to the sensor’s value.

[Ildar_Gabdullin]

Sorry but the way you are sometimes trying to explain things is rather intolerable. Hope this is a right word, English is not my native language. You are an expert in this stuff - that is great. Other people are not. Please be patient.

[Olivier1974 (Olivier Toussaint)]

I’ll let my developper skills for 25 years speak for me, in C

#include <stdbool.h>

int main() {
    bool myBool = SomeJinja(myBaseSensor);
    return 0;
}

You say : the SomeJinja function, described in the template is always true or false, stop focusing on this part.
So will be my boolean here, always true or false.
If there is a subtle mechanism behind the binary_sensor that convert something always true or false to unknown, just tell me which one.

[Olivier1974 (Olivier Toussaint)]

Or even better, write the binary_sensor for me if I’m obviously stupid in your eyes.

I have a sensor that can be on/off/unavailable or unknown.
I’d like a binary_sensor based on that one that will only be on or off

• on when the other one is on,
• off otherwise.

No unknown, never.

[petro]

I have patience, but I’m at my limit with Oliver. As you can see Oliver is still aruging about is_state because Oliver can’t separate the template from the entity. is_state is inside the template, the template will always resolve true or false. Binary sensors have a whole set of rules they follow that are 100% unrelated to the template. That’s where Oliver should be focusing his efforts. But nooooooo it’s is_state that’s failing.

[Ildar_Gabdullin]

Dear Petro! We all want to learn the system. Most of us then contribute experience / solutions.
Even very smart people may not understand “simple” things…

[petro]

There’s a difference when you don’t accept an answer and continue to argue. I’m sorry, but Oliver is still arguing that is_state is broken. You can see it in the title. That is not the case. Oliver’s issue lies elsewhere. There’s a time when even any level headed novice of a system will step back and say “Maybe I don’t understand the interworking’s here, maybe I’m looking in the wrong spot”.

[Olivier1974 (Olivier Toussaint)]

@Olivier1974

If there is a subtle mechanism behind the binary_sensor that convert something always true or false to unknown, just tell me which one.

Might be, if the base sensor is not updated for more than 1 hour, the binary_sensor will be marked as unknown, and I’ll be fine with that kind of explanation.

But today I don’t know what to change in that sensor for it to never be unknown.
I have a workaround using trigger sensor given by Taras in my other post but the main question remain:

Ok, got your point, is_state is always true or false. That is now my hypothesis.
Is it normal then that a sensor whose value is explicitly defined by that could have its value set to something else?

[petro]

Yes:

1. During restart.
2. During reload of the template integration.

Here’s a binary sensor that I use that literally is always on or off accept during the 2 scenarios listed above.

Petro31/home-assistant-config/blob/22399d7ebce325e44268cb906f72c18865540b71/template/energy.yaml

- binary_sensor:
  - unique_id: washer_status
    name: Washer Status
    device_class: power
    state: >
      {{ is_state('input_boolean.washer', 'on') }}
    attributes:
      template: energy

Here’s a 1 day period where I updated (restart occured)

Here’s a 2 day period where I didn’t update or restart (no restarts, no reloads)

Notice the 2 day period, no unknowns.

If you’re getting unknown on that entity, it’s most likely a restart or a template reload.

And just to clarify, when I say reload template:

[Olivier1974 (Olivier Toussaint)]

@petro

If you’re getting unknown on that entity, it’s most likely a restart or a template reload.

I swear to God that I did not restart HA neither reloaded the templates.
And I know where it is, I’m not the noob you seems to believe, it is here in French

EDIT:

sensor created this morning, was unavailable at first

Then it was turned on because I triggered the sensor used in the template, perfect.
Back to off after, as expected.

Then 2 unknown, 13:58 and 14:58

And I did not touch anything on my HA instance.

[petro]

Then by all means, write up an issue against binary_sensor template entities if you’re so confident. Just don’t write it against is_state, because that’s not the problem.

Here’s the code for is_state

def is_state(hass: HomeAssistant, entity_id: str, state: str | list[str]) -> bool:
    """Test if a state is a specific value."""
    state_obj = _get_state(hass, entity_id)
    return state_obj is not None and (
        state_obj.state == state or isinstance(state, list) and state_obj.state in state
    )

As you can see, it’s literally impossible for it to return anything other than True or False.

[stevemann (Stephen Mann (YAML-challenged))]

@Ildar_Gabdullin

Even very smart people may not understand “simple” things…

I have been using Home Assistant for two years and still avoid templates because they don’t make sense to me. I see what you are trying to do, but I have no clue how to solve it.

But… why does it matter if the entity value is unavailable?