Set sensor value to -1, if sensor is unknown

Configuration
,
1

To avoid a “Die Entität ist nicht-numerisch: sensor.heizung_ventil” message, I was thinkaing about a template, but I still see the not numeric value instead of the gauge. When I test the value_template it works well.

  - platform: mqtt
    name: "Heizung Terrasse - Ventil2"
    state_topic: "homee/human/Wohnzimmer Heizung Terrasse(2)/CurrentValvePosition(29)"
    unit_of_measurement: '%'
    icon: mdi:valve
    value_template: >
      {% if states('sensor.heizung_terrasse_ventil') == 'unknown' %}
        {{ '-1' | int  }}
      {% else %}
        {{states('sensor.heizung_terrasse_ventil')}}
      {% endif %}
2

Did you try:

    value_template: >
      {% if states('sensor.heizung_terrasse_ventil') == 'unknown' %}
        -1
      {% else %}
        {{states('sensor.heizung_terrasse_ventil')}}
      {% endif %}
3

it’s just -1 intead of {{ '-1' | int }}?

Yes, same result.

4 
{{ -1 if states(...) == 'unknown' else states(...) }}
5 
  - platform: mqtt
    name: "Heizung Terrasse - Ventil2"
    state_topic: "homee/human/Wohnzimmer Heizung Terrasse(2)/CurrentValvePosition(29)"
    unit_of_measurement: '%'
    icon: mdi:valve
    value_template: >
      {{ -1 if states('sensor.heizung_terrasse_ventil') == 'unknown' else states('sensor.heizung_terrasse_ventil') }}

Same result.

6

I don’t get it, why do you create an MQTT sensor and then use the state of another sensor to determine the value of the MQTT sensor?

7

The Ventil2 is just to see the original sensor and the sensor after the value_template operation during experimenting with value templates.
Goal is to just have only the corrected sensor, when I got it to work.

8

But then why is the ventil2 a mqtt sensor and not a template sensor?
What value do you receive on the mqtt topic that shows as unknown?

9

Got that. Removed the original Ventil and changed the new (with template) to Ventil.

name: "Heizung Terrasse - Ventil"

Same result.

10

Can you please show the config of the original mqtt sensor and tell me what you receive on the topic that makes the value unknown?

1 Like
11

Came here to say this. You don’t need a second sensor, adjust the first to have -1 when it goes unknown.

12

old orignal yaml:

  # - platform: mqtt
  #   name: "Heizung Terrasse - Ventil"
  #   state_topic: "homee/human/Wohnzimmer Heizung Terrasse(2)/CurrentValvePosition(29)"
  #   unit_of_measurement: '%'
  #   value_template: "{{ value_json | round(0) }}"
  #   icon: mdi:valve

When I just put {{states('sensor.heizung_terrasse_ventil')}} in the template editor I see unknown.

Yes, that was my idea but I didn’t get the -1 value…

Remark: That idea is only a work around to get rid of the unknown display after a reboot of HA when using i.e. the gauge card. Any other idea of avoid that ugly display is welcome.

grafik
grafik764×80 6.7 KB

13

Yes, because it references itself and itself doesn’t have information at bootup.

Why do you care if its only momentary?

On reboot, the MQTT server is starting up. Wrapping it in a template sensor is the only option if you don’t want the yellow.

14

That’s because the payload published to this topic:

homee/human/Wohnzimmer Heizung Terrasse(2)/CurrentValvePosition(29)

is not published as a retained message.

Do you have any control over the device that publishes to that topic?

15

I’m just restarting HA; and in my docker-compose the mqtt-broker starts before HA.
May you post an example or a link to an example, pls.

Hhm. I’m afraid, not. The sensor comes from homee using the homeetomqtt integration.

And I see the same unknown with the zigbee2mqtt integration.

16

In homeetomqtt’s repository, I see examples for Node-Red. Are you using any Node-Red flows to implement the homeetomqtt integration?

Are you using ZigBee2MQTT’s MQTT Discovery feature or are you defining the entities manually in Home Assistant?

ZigBee2MQTT has a configuration option for retain.

17

No, I just let the values forward to mqtt.

To be honest, I’m not sure. Did this some time ago. Actually I have the sensors defined manually:

  - platform: mqtt
    name: "XiaomiAqara-1 Temperature"
    state_topic: "zigbee2mqtt/XiaomiAqara-1"
    unit_of_measurement: '°C'
    value_template: "{{ value_json.temperature | round(1) }}"
    availability_topic: "zigbee2mqtt/bridge/state"
    device_class: "temperature"

What do you suggest? Remove and let the integration re-discover (when the homee2mqtt problem is solved)?

18

Given that you are not using MQTT Discovery and manually defining the entities, I suggest you enable ZigBee2MQTT’s retain option.

1 Like
19

Got you…
Added retain: true in the zigbee2mqtt/data/configuration.yaml and the unknown is away shortly after the HA restart. Thanks for that hint!

20

The same solution would fix the unknown problem with homeetomqtt, unfortunately it doesn’t offer a way to publish using retain: true like ZigBee2MQTT does.

I looked at the JavaScript code in one of homeetomqtt’s files called app.js. That’s the file responsible for publishing payloads. It’s possible to modify the code so that it always publishes payloads as retained messages.

For example, look at line 197 here:

I’m no JavaScript expert but I believe all that’s required is to change it to this:

mqttConnection.publish(publishString, JSON.stringify(mqttJson), {retain: true})
1 Like