Sensor with delay_off has state unknown at startup when off

Configuration
26

Now I understand. The availability has to be set, otherwise it will just set the sensor to a silly state.

  - sensor:
      - name: "Sonne Höhe"
        unit_of_measurement: "°"
        unique_id: SonneHohe
        availability: "{{ state_attr('sun.sun', 'elevation')|float(none) != none }}"
        state: "{{ state_attr('sun.sun', 'elevation')|float(none) }}"

So I will change all my template sensors like that.

Right now I am just changing template.yaml, but I am using more templates.

What about these templates - are these already fail proof or how should I handle those:

  - platform: template
    switches:
      panasonic_tv:
        friendly_name: "TV"
        unique_id: "switch.panasonic_tv"
        value_template: "{{ states('media_player.panasonic_tv') }}"

  - platform: command_line
    name: Status
    scan_interval: 60
    command: "/Users/server/scripts/status.sh"
    value_template: "{{ value }}"

  - wait_template: '{{ (states(''media_player.receiver'') == ''on'' ) }}'
    timeout: '30'

  - resource: url
    scan_interval: 60
    timeout: 45
    binary_sensor:
      - name: "Service"
        value_template: >-
          {% if value_json is defined %}
            {% if value_json.currentState == 0 %}
              {{'off'}}
            {% else %}
              {{'on'}}
            {% endif %}
          {% else %}
            {{'unknown'}}
          {% endif %}


- platform: template
  covers:
    garage_tor:
      friendly_name: 'Tor'
      unique_id: Tor
      value_template: "
        {% if states('switch.status_tor') == 'off' %}
          {{ True }}
        {% else %}
          {{ False }}
        {% endif %}"
27

None of those templates are using functions or filters that require a default to be defined.

This one can be simplified:

- platform: template
  covers:
    garage_tor:
      friendly_name: 'Tor'
      unique_id: Tor
      value_template: "
        {% if states('switch.status_tor') == 'off' %}
          {{ True }}
        {% else %}
          {{ False }}
        {% endif %}"

to this:

- platform: template
  covers:
    garage_tor:
      friendly_name: 'Tor'
      unique_id: Tor
      value_template: "{{ is_state('switch.status_tor', 'off') }}"
1 Like
28

If I set the availability as you said above, do I really have to set float(none) to every value I use in the template?

        availability: "{{ state_attr('sun.sun', 'elevation')|float(none) != none }}"
        state: "{{ state_attr('sun.sun', 'elevation')|float(none) }}"

or

        availability: "{{ state_attr('sun.sun', 'elevation')|float(none) != none }}"
        state: "{{ state_attr('sun.sun', 'elevation') }}"
29

You don’t need a float filter or an availability template.

Just this:

state: "{{ state_attr('sun.sun', 'elevation') }}"
30

So, should I only use the availability if I compare or calculate something?

If so is this correct?

        availability: "{{ states('sensor.boen_m_s')|float(none) != none }}"
        state: >
          {% if (states('sensor.boen_m_s')|float(none) < 5) %}
            {{ (10 * 3.6 * states('sensor.boen_m_s')|float(none) )|round(1) }}
          {% else %}
            {{ 11.111 }}
          {% endif %}

or this one:

        availability: "{{ states('sensor.boen_m_s')|float(none) != none }}"
        state: >
          {% if (states('sensor.boen_m_s')|float < 5) %}
            {{ (10 * 3.6 * states('sensor.boen_m_s')|float)|round(1) }}
          {% else %}
            {{ 11.111 }}
          {% endif %}
31

You need to supply a default value for functions and filters, e.g. |float or log().

You only need to supply an availability template if you want to protect against these templates returning incorrect values when the sensors in the templates are unknown or unavailable.

32

But it is still required to set the default if I check for availability, right?

Also |round(1) calls for a default value as well.

33

Yes. I think there is work being done on a PR that prevents the state template being evaluated if the availability template returns false but I’m not sure if it has been merged yet.

Yes.

1 Like
34

And if I just copy the value to a template it will also copy unknown and therefore not fail.

state: "{{ state_attr('sun.sun', 'elevation') }}"

I think now I have it.

But thinking about condition templates. These will just return false if a sensor is not available, right? Because I do make calculations in these templates as well.

35

Correct.

As for template conditions, if you are worried about them and they are unreliable put them in their own template sensors.

1 Like
36

Most sensors are states or state_attr that return a float value. So I did float(none).

How should I handle binary_sensors or strings?

37
1 Like
38

Maybe I missed it but if I compare this for on or off in a template I need a default value.

states('binary_sensor.test')

This is obviously wrong:
{{ states('binary_sensor.test')|boolean(none) != none }}

39

You must have, you’re making up filters boolean is not a filter, test, or keyword. So no, it doesn’t need a default value because it doesn’t exist.

40

So if I check if binary is on and it is unknown it is not on - makes sense :grin:

41

I have no idea why you’re arguing here. In templates, you must cover all state possibilities in code if you want to avoid having unknown or unavailable sensors. I explained this in the other thread you started with this. If you want meaningful states at all times, you must code it that way.

42

I start to understand. What was weird to me is how HA handles this. I never had issues and at some point I will have, because this error management is in place. That is why I am doing this right now.

Take it simple: why does HA just label a sensor unknown if a state is missing or wrong? As far as I understand this is the behavior right now.

I don’t want to argue, I want to understand.

43

If you don’t know something, is it known or unknown?

44

It is unknown. So the sensor should report unknown.

45

Binary entities will. Everything else will report whatever you coded it as (sensors)