Not that i think it will “help” you, i tend to find easy “solutions” , so in this case, where the state unknown/unavailable/yellow/red/fatal/error/1/2/3 , should/could be ignored, Ignore !
I changed the title but I’ll ask you to stop considering that I don’t understand. I’ll also ask you to use my name instead of “he” that is a direct insult in French, please.
Sorry, I didn’t mean to insult you with he. And I’ll stop referring you you as not understanding, but this is the first time that it seems you might actually be listening to what I’m saying about is_state. We only got here because you refused to try to understand what I was saying and argued instead. Maybe next time you approach a problem, think “hey maybe I’m looking at the wrong thing” when someone tells you you’re looking at the wrong thing.
It is part of a complex automation, not relevant in this context.
The automation is used for different things, but to do short:
It is based on a smoke detector that can be on (alarm went off, that’s already hard for a non English speaker like me), off when everything if fine (triggered by the last will given to mosquitto) but replaced almost instantly by unavailable/unknown as the D1mini assuring the smart part of the sensor is no longer powered on.
To alert the world, smartphones, lights, automatic call to my neighbor, I want a sensor that is only on or off.
On : alert, fire
Off : Everything is ok, or back to normal.
I’m keeping the 4 states initial sensor to do a basic intelligence that will try to identify if everything is back to normal or if my D1mini just melted.
I could do multiple trigger on off, unknown or unavailable but then I’ll have notifications like
Smoke detected
Back to normal
Back to normal
And I wanted to avoid this case.
You can always constrain your trigger to occur from off to on. You can also have it ignore from_states. There are many different ways to approach instead of trying to ensure an entity is always on or off.
You can even make an automation that flicks an input_boolean on or off. Those will always have a state, regardless of restarting and reloading.
Ok, but you have to admit that when a sensor can basically be reduces to the value given by a Jinja template, nobody can reasonably think that it could possibly be something else in such a simple definition of template.
There are only yaml tags in
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') }}
There is literally nothing else I can change except the friendly_name.and the device_class and that is the reason why I still don’t know what I should focus on. I’ll follow-up this on Github.
I know, I can think of many other way to do it. But as I wanted to do a combinatoric analysis of the 2 states and be smarter than just on/off, I’d have like that sensor to be always on or off and combine it with the ’ states of the smoke detector.
Please don’t. You will just be told the same thing you are refusing to understand here.
IMHO, I also do not understand the system properly.
Please consider these binary sensors (not trigger-based):
- name: testing_binary_sensor_3
state: >-
{{ states('input_boolean.testing_binary_sensor') }}
- name: testing_binary_sensor_4
state: >-
{{ states('input_boolean.testing_binary_sensor') }}
availability: >-
{{ states.input_boolean.testing_binary_sensor is defined }}
- name: testing_binary_sensor_5
state: >-
{{ states('input_boolean.testing_binary_sensor') }}
availability: >-
{{ not states('input_boolean.testing_binary_sensor') in ['unknown','unavailable'] }}
And here is a period when HA restarted:
All sensors are “unknown” even when “availability” is defined.
Is it normal?
I believe Oliver is referring to following up unknown states randomly showing up on template binary_sensors, not the is_state. Which I recommended he should do.
Yes, that’s normal. During restart or reload, template entities are ‘unknown’, because the state is ‘unknown’.
‘unknown’ means HA doesn’t know the state. ‘unavailable’ means the entity is not available because home assistant can’t get the state (for whatever reason). During a restart, home assistant doesn’t know the state but it knows it can get the state. I.e. unknown. This is just how template entities behave when you restart. That behavior isn’t always consistent across integrations, but it is consistent across template entities.
As a sidebar, that availability template won’t do anything because input_booleans are always persistent, i.e. they don’t have unknown or unavailable states because they are “virtual”.
1 Like
I’m not refusing to understand.
I understood @petro, looking at the python, is_state will always be true if in (list of) states or false if None or not in the (list of) state. No more issue here.
But the initial question remain: As (no more ifs) the template is always evaluated as true or false, why is the sensor’s value unknown from time to time?
Just please explain to me why it is normal, the reasons why, the conditions for this to happen (other than the 2 mentioned by @petro and that are not the cause of my issue, I did not restart part or the whole Home Assistant)
I’m just asking someone from HA to tell me in easy terms : “yes, that can happen because the ttemplates are sometimes re-evaluated when this or that and that might (not will) cause the template to be considered as unknow for a few seconds. It is by design”. And I’ll be happy, trust me.
Even when “value_template” is defined and gives a particular value?
Like at HA startup the system is unable to define sensor’s state independently on it’s “value_template” & “availability” code.
@Olivier1974 on to your actual issue. I believe you should investigate your latency issues that were shown in your logs. I saw a few taking 10 seconds to update in one of your log posts around the time you had an unknown state. It’s possible that these issue’s you’re having are a symptom of a larger system wide problem.
1 Like
I know that my Pi 3B+ is struggling sometimes but I’m waiting for the Pi 5 
If it timesout trying to evaluate the template I’d prefer to have unavailable instead of unknown but it is another story.
If the template integration is restarting and the system is reading in all your templates again, all affected templates are ‘unknown’. That’s it, nothing more to this.
By the way, looking at the code I now know that it can be a list.
Shouldn’t it be in the log somewhere if it is restarting?
Only reloading may show in the logs (can’t remember if there’s a log line for that). Restarting will clear the logs. That’s not happening in your case because you’d see the startup. Reloading… maybe? If you have an automation that reloads the template integration, that would cause it.
You can look at your actual text logs instead of the logs in the UI. That gives better context.
If you can’t remember if you’re using the reload service for templates, search your configuration for: template.reload