I have no idea what STATE currently is. If it’s unknown, the logic still works because it’s not “XXX”. not STATE if populated will be FALSE and FALSE == “XXXXXX” will be false, i.e. it will hit unknown in that case.
You keep focusing on unkonwn, but there’s nothing special with it. It’s a string, not an object. There is no special case here. It’s the word ‘unknown’.
Can we just focus on your original template, the actual template instead of these tests? They don’t solve anything other than confuse everyone. Post your original issue with the original templates (not these fake templates), I’ll fix it and we can move on.
My original case is rather complex.
But results are same as in the simple example.
In short - when the value_template is unknown, the reported state is “off”.
I wanted to understand the problem, that is why I created a simple example.
Here is the output:
One window, 2 different results.
binary sensors restore states, did you just restart? Did you change the input_select? Again, the states machine holds the last state, not the current state. I feel like a broken record here.
No, should I restart?
Several times for testing, how could I show you different screenshots with the card otherwise?
No need to get irritated here.
Now let’s change to sensor from binary_sensor - it works as expected:
The problem with “unknown” happens only to “binary_sensor”.
Only when I specify “unknown” state to the binary_sensor via “Set state” panel - the card shows “unknown” state:
Otherwise, if the “unknown” state is set in “value_template”, it anyway is “turned” to “off”.
Maybe it’s something strange with 2022.5.x
I’m still on 2022.4.7 and it works as expected for me:
looks like it may be time for a bug report?
How did you set the “unknown” state for the sensor - is it via “value_template”?
Unknown can only be on trigger template binary sensors for legacy functionality.
Is this not a trigger binary sensor?
And in this version they restore states. Changed from last version.
Lastly, circling back, I still don’t understand how this impacts your icon template in your original post which is why I’m trying to focus on that.
Either way, I’m getting frustrated so I’m out.
it is just that way after a HA restart so it hasn’t updated yet. (system controlled…)
that shouldn’t matter in the dev tools should it?
it should be displaying whatever the current state is.
Mine is showing “unknown”. Which is correct.
the OP’s is showing ‘off’ which reportedly is not correct and should also be unknown.
unless I’m missing something?
Ah, so easy to frustrate.
Too bad if you do not understand that this behaviour is not productive.
IF he reloaded his templates, then it does matter. we have no idea because he’s still showing the same tired old dev tools screenshot.
Reload → state restored
Restart → state restored
He has to do that at some point to put the new logic in.
Because you’re talking past the original issue, which is your icon template and you’re focusing on this completely unrelated question. Do you want to fix your unknown icon or what?
“He” did restart even after changing a code.
Then I played with input_select, and changing the “input_select” was supposed to change the binary_sensor too.
It works for me on 2022.5.3
As you could notice, last posts I was asking a same question: “why when the state is unknown, it is reported as off”.
Right, which has been explained. If you just restarted after executing your logic, it should restore your previous state.
Then the word ‘unknown’ being output should result in on or off, because binary sensors only accept on, off, or none. All other words resolve to either on or off because that’s how the resolver works.
You can try just making a simple binary sensor that just outputs the word {{ 'unknown' }} and see what it resolves to.
and just reading the docs, it even tells you
This answer is EXACTLY what I needed.
That is why binary sensor assigned to “unknown” is keeping “off”.
That means that for my particular original case I should probably switch to “sensor” from “binary_sensor”.
Unless another decision is possible.
The original idea was:
That is why I faced a situation “sensor is set to Unknown but is reported as OFF”.
if you want tri-logic, then set your unknown case to output none or make an availablity template for that case. It will show up as unavailable with an unknown icon.
Binary_snesors can only be unknown at startup with trigger based binary_sensors and IIRC that now restores states so you shouldn’t get unknown in 2022.5 anymore.
I will experiment with this proposal and probably come back with results.
Thanks a lot for helping!
Here are my tests:
4 binary_sensors:
Sensor_1:
value_template: none for “unknown” case;icon_template defined for cases “unknown”, “on” & “off”;Sensor_2:
value_template = on/off;icon_template defined for cases “on” & “off”;Sensor_3:
value_template - same as above;icon_template defined for cases “unknown”, “on” & “off”;Sensor_4:
value_template - same as above;icon_template NOT defined;device_class: battery_charging;Sensor_5:
value_template - same as above;icon_template defined for cases “unknown”, “on” & “off”;device_class: battery_charging;The code:
binary_sensor:
- platform: template
sensors:
test_unknown:
value_template: >-
{% set STATE = states("input_select.test_unknown_selector") -%}
{%- if STATE != "xxxxxx" -%}
{{ STATE }}
{%- else -%}
{{ none }}
{%- endif %}
icon_template: &ref_icon_template >-
{% if is_state("input_select.test_unknown_selector","xxxxxx") -%}
{{ "mdi:battery-unknown" }}
{%- elif is_state("input_select.test_unknown_selector","on") -%}
{{ "mdi:battery-charging" }}
{%- else -%}
{{ "mdi:battery" }}
{%- endif %}
test_unknown_2:
value_template: &ref_value_template >-
{% set STATE = states("input_select.test_unknown_selector") -%}
{{ STATE }}
icon_template: >-
{% if is_state("input_select.test_unknown_selector","on") -%}
{{ "mdi:battery-charging" }}
{%- else -%}
{{ "mdi:battery" }}
{%- endif %}
availability_template: &ref_availability >-
{{ not is_state("input_select.test_unknown_selector","xxxxxx") }}
test_unknown_with_icon_for_unknown:
value_template: *ref_value_template
icon_template: *ref_icon_template
availability_template: *ref_availability
test_unknown_with_dev_class:
value_template: *ref_value_template
device_class: battery_charging
availability_template: *ref_availability
test_unknown_with_icon_for_unknown_dev_class:
value_template: *ref_value_template
device_class: battery_charging
icon_template: *ref_icon_template
availability_template: *ref_availability
############################################################
input_select:
test_unknown_selector:
options:
- "xxxxxx"
- "on"
- "off"
The card (also contains a tri-state sensor (not binary)):
type: entities
state_color: true
entities:
- entity: input_select.test_unknown_selector
- type: section
label: binary_sensor
- entity: binary_sensor.test_unknown
name: 'value_template: none'
- entity: binary_sensor.test_unknown_2
name: avail_template
- entity: binary_sensor.test_unknown_with_icon_for_unknown
name: avail_template + icon for unknown
- entity: binary_sensor.test_unknown_with_dev_class
name: avail_template + dev_class
- entity: binary_sensor.test_unknown_with_icon_for_unknown_dev_class
name: avail_template + icon for unknown + dev_class
- type: section
label: sensor
- entity: sensor.test_unknown
The result:
Observations:
device_class does not affect on the icon since it is controlled by the icon_template.