How to handle error state for numeric rest sensor

I’ve been running a fairly old version of HA as a docker container on a RPI for quite some time. I recently pulled a new docker image and since then I’ve started having lots of problems with my REST sensors. In particular, I’ve got a separate python service running on the same RPI that runs my heating system; among other things, it exposes an HTTP endpoint that enumerates the temperatures of all my 1 Wire temperature sensors as a JSON object.

1 Wire being what it is, sometimes the sensors crap out for a bit. I’m working on making them more reliable but it’s very much a WIP. I’ve e.g. got one problematic sensor completely disconnected right now. The heating service catches errors with the sensors and returns an error value instead of a temperature reading for that sensor. I used to return “Error” and HA dealt with it fine. If there was a numeric value, it displayed and recorded it, if the value was “Error” it displayed “Error” and didn’t record the numeric value for charting (there would just be a gap in the chart).

Since I pulled the new version, this has broken. Returning any kind of non-numeric value - be that a string or a null - in the JSON breaks the entire REST resource, stopping all the temperature sensors from updating, including the ones that are returning valid values. I’m getting lots of these:

ValueError: Sensor sensor.bedroom_temperature has device class 'temperature', state class 'measurement' unit '°C' and suggested precision 'None' thus indicating it has a numeric value; however, it has the non-numeric value: 'None' (<class 'str'>)

This ticket looks relevant but apparently none of the HA devs are interested in it :frowning_face: Rest sensor not updating (non-numeric value: 'None') · Issue #99942 · home-assistant/core · GitHub

What can I do to restore the previous behaviour? I want the sensor to remain a numeric temperature measurement sensor with historical graphing, but I need a way to handle the possibility that some of the values may not be available. I’ve got a load of these so ideally I don’t want to have a massive boilerplate template for every single one just to be able to handle the possibility of an unavailable value :frowning:

Here’s a snippet of the relevant config:

rest:
  - scan_interval: 30
    resource: http://192.168.1.15:5000/temperature
    sensor:
      - name: "Bedroom temperature"
        value_template: "{{ value_json.bedroom }}"
        unit_of_measurement: "°C"
        device_class: "temperature"
        state_class: "measurement"
        unique_id: "pi_bedroom_temp_sensor"
      - name: "Bathroom temperature"
        value_template: "{{ value_json.bathroom }}"
        unit_of_measurement: "°C"
        device_class: "temperature"
        state_class: "measurement"
        unique_id: "pi_bathroom_temp_sensor"
# etc -> lots more of these

Try to implement the availability: in your sensor, with something like

availability: "{{ value_json.bedroom | is_number }}"

The sensor will then have the “unavailable” state if the value is not numeric, which will prevent that error message

1 Like

Hi herodotus,

FYI that may or may not fix anything depending on what version you are running and if your supervised install OS is up to date or not. Supervised is notoriously hard to keep functioning correctly. Depending on how old, the Docs may or may not help either.

Especially if you are not running current version, let your helper know what you are running so we can make sure you are getting the correct help.

I pulled latest stable of the docker image a few days ago which is when the problems started. I’m going to pin now to 2024.7 to ensure that I know more closely what I’m running - that’ll be 2024.7.3 right now. OS is Raspbian 11 Bullseye, fully updated.

Because I’m also using the RPI to handle the hardware IO side via my own Python application, running the full HA OS isn’t really a practical option for me. I’m a web software engineer and I build massive enterprise apps with Docker so I’m reasonably comfortable with that side of it.

I’ll give the “availability” thing a try later; I hadn’t done that yet because that ticket I linked seemed to imply that this was systematically broken for the REST integration, but maybe that’s not true.

As feared, the availability thing doesn’t work, it still fails with the same exception. That’s the thrust of the ticket that I linked. This is a pretty substantial regression for anyone using REST sensors to pull back numeric values; it means that useful error handling is basically impossible. Sigh. I don’t know if anyone has any other bright ideas on how to fix this?

I’m wondering if, tedious though it would be to do, I have to add some sort of value coercion in the value template to handle the None value

It looks like this change: Refactor Rest Sensor with ManualTriggerEntity by gjohansson-ST · Pull Request #97396 · home-assistant/core · GitHub broke the behaviour here quite substantially. This is very frustrating.