Checking mqtt sensors for bad values

Hello,
I am using a shelly 1PM with 3 temperature sensors (ds18b20) configured via mqtt sensor as follows:

mqtt:
  sensor:
  - state_topic: "shellies/shelly1pm-E8DB84D7EB2D/ext_temperature/1"
      state_class: measurement
      unique_id: "28192976e0013c67"
      unit_of_measurement: ºC 
      value_template: "{{ value | float  | round (2) }}"

This has been working fine for several months, but now for some reason, every now and then I receive 999.0 as temperature value on one of the sensors which completely messes up the graphics for temperature history.
Looking for a solution in the forum to skip unacceptable values, I found and tried the following:

mqtt:
  sensor:
  - state_topic: "shellies/shelly1pm-E8DB84D7EB2D/ext_temperature/1"
      state_class: measurement
      unique_id: "28192976e0013c67"
      unit_of_measurement: ºC 
      value_template: >-
        {%- if value | float >= 1 and value | float <= 120 -%}
        "{{ value | float  | round (2) }}"
        {%- else -%}
        nan
        {%- endif -%}

which does not work (temperature is said to be “unavailable”).
But when I try this piece of code within the developer tools / template, substituting “value” with the sensor name as follows:

{%- if states("sensor.mqtt_sensor") | float >= 1 and states("sensor.mqtt_sensor") | float <= 120 -%}
{{ states("sensor.mqtt_sensor") | float  | round (2) }}
{%- else -%}
nan
{%- endif -%}

It works fine…

As a next step, I would like to replace “nan” with some code to send a persistent notification within HomeAssistant (not to phone or anything else) just to be able to see how often I get temperatures that are outside of the expected range. I have used persistent notifications calling the service within the “action” part of automations, but somehow can’t figure out how to do this here…

Any ideas on what is wrong with the code and on how to send the notification?
And a possible explanation as for why suddenly after several weeks this sensor gives those wrong values?

GD

You can’t have the string “nan” as a sensor state with a defined unit_of_measurement.

Use the availability features instead (docs): this should work:

mqtt:
  sensor:
    - name: "ADD NAME HERE"
      state_topic: "shellies/shelly1pm-E8DB84D7EB2D/ext_temperature/1"
      state_class: measurement
      unique_id: "28192976e0013c67"
      unit_of_measurement: "°C" 
      value_template: "{{ value|float(0)|round(2) }}"
      availability_topic: "shellies/shelly1pm-E8DB84D7EB2D/ext_temperature/1"
      availability_template: "{{ 'online' if (1 <= value|float(0) <= 120) else 'offline' }}"

I’ve also fixed the indentation and added default values to float. name isn’t mandatory but good practice.

1 Like

Thanks,

I tried this out and it seems to work. I had a look at the availability features in the past, but I thought this would just set the attribute to “offline” but still pass the wrong value

If I understand it correctly now: when the measured value is not within the limits set in the availability_template, the sensor is regarded as being unavailable and the measured value will not be used, is that correct?

GD

That’s what the documentation suggests: I’ve not used it myself.

The availability_template returns 'online' or 'offline' depending whether your value is inside your specified range — and if it’s not a number, float will return a default value of 0 which is outside the range.

Those 'online' and 'offline' strings are the default values for payload_available and payload_not_available, which I ass-u-me will set the sensor state to either a valid value or unavailable.

If that’s not how it ends up working, let us know as the docs would need modfying.

Good tip you gave me there with

“if it’s not a number, float will return a default value of 0 which is outside the range”

I will have to remember that, because on some other temp. sensors I do have ranges that go e.g. from -10 to 40. Here “0” would be within the range, but anyway, my problem until now is that the sensors do give wrong values every now and then, but they are always numbers, so I should be OK.

And as for your explanation of the values that are returned when the availability template returns “offline”, from what I can see, you are right: when offline the sensor state becomes “unavailable”

Thanks for the explanation

GD

I suspect you already realise this, but the default 0 is the number in brackets in float(0) — you can put other values or even strings as defaults to be used if conversion fails.