Exception since 2023.5.0: state class None: numeric value, however, it has the non-numeric value. #92483

Holland1 · 2023-05-04T10:21:27Z

The problem

The issue is introduced in 2023.5, without any config changes from my site related to my iPhone

Exception is visible both with charging and not-charging. (makes sense off course)

What version of Home Assistant Core has the issue?

2023.5.0

What was the last working version of Home Assistant Core?

2023.4.6

What type of installation are you running?

Home Assistant OS

Integration causing the issue

NA

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

2023-05-04 11:30:55.105 ERROR (MainThread) [homeassistant.util.logging] Exception in _handle_update when dispatching 'mobile_app_sensor_update': ('aa296a1333b3ea46c2cfa721b87a9816df8e9935cdba08f5c8f23c57d57a0dda_battery_state', {'attributes': {'Low Power Mode': False}, 'icon': 'mdi:battery-charging-20', 'state': 'Charging', 'type': 'sensor', 'unique_id': 'battery_state', 'webhook_id': 'aa296a1333b3ea46c2cfa721b87a9816df8e9935cdba08f5c8f23c57d57a0dda'})
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 579, in state
    numerical_value = int(value)
ValueError: invalid literal for int() with base 10: 'Charging'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mobile_app/entity.py", line 105, in _handle_update
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 585, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 649, in _async_write_ha_state
    state = self._stringify_state(available)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 591, in _stringify_state
    if (state := self.state) is None:
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 583, in state
    raise ValueError(
ValueError: Sensor sensor.iphone_van_marck_battery_state has device class battery, state class None unit None and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: Charging (<class 'str'>)

Additional information

No response

KruseLuds · 2023-05-05T20:19:17Z

Same problem here, this code in longer works (sensor shows as unavailable in lovelace):

sensor:
  - platform: template
    sensors:
      battery_status_kruse_cell:
        friendly_name: Kruse's Cell Battery
        value_template: >-
          {% if is_state('binary_sensor.kruse_s_s23_ultra_is_charging','on') %}
             Charging: {{ states('sensor.kruse_s_s23_ultra_battery_level') }}
          {% else %}
             Not Charging: {{ states('sensor.kruse_s_s23_ultra_battery_level') }}
          {% endif %}
        icon_template: >-
          {% set batterylevelicon = states('sensor.kruse_s_s23_ultra_battery_level') | int(0) // 10 * 10 %}
          {% if batterylevelicon == 100 %}
             mdi:battery
          {% else %}
             mdi:battery-{{batterylevelicon}}
          {% endif %}
        unique_id: battery_status_kruse_cell
        unit_of_measurement: "%"

But, it does work if the code is changed to this (note three lines changed):

sensor:
  - platform: template
    sensors:
      battery_status_kruse_cell:
        friendly_name: Kruse's Cell Battery
        value_template: >-
          {% if is_state('binary_sensor.kruse_s_s23_ultra_is_charging','on') %}
             Charging: {{ states('sensor.kruse_s_s23_ultra_battery_level') }}%
          {% else %}
             Not Charging: {{ states('sensor.kruse_s_s23_ultra_battery_level') }}%
          {% endif %}
        icon_template: >-
          {% set batterylevelicon = states('sensor.kruse_s_s23_ultra_battery_level') | int(0) // 10 * 10 %}
          {% if batterylevelicon == 100 %}
             mdi:battery
          {% else %}
             mdi:battery-{{batterylevelicon}}
          {% endif %}
        unique_id: battery_status_kruse_cell

But, even with the change above (three places with %) to make the sensor work, this error is still in the syslog:

May 5 08:01:26 kruse-pi homeassistant[599]: ValueError: Sensor sensor.battery_status_kruse_cell has device class None, state class None unit % and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: Charging: 100 (<class 'str'>)#33[0m

e10kstarfire · 2023-05-07T00:31:30Z

I am also seeing this with the GivTCP addon, as below:

Logger: homeassistant.components.mqtt.models
Source: components/sensor/__init__.py:583
Integration: MQTT (documentation, issues)
First occurred: 00:02:47 (676 occurrences)
Last logged: 00:12:28

Exception raised when updating state of sensor.givtcp_ed225XXXXX_invertor_serial_number, topic: 'GivEnergy/ED225XXXXX/Invertor_Details/Invertor_Serial_Number' with payload: b'ED225XXXXX'
Exception raised when updating state of sensor.givtcp_ed225XXXXX_invertor_time, topic: 'GivEnergy/ED225XXXXX/Invertor_Details/Invertor_Time' with payload: b'07-05-2023 00:12:16'
Exception raised when updating state of sensor.givtcp_ed225XXXXX_meter_type, topic: 'GivEnergy/ED225XXXXX/Invertor_Details/Meter_Type' with payload: b'EM115'
Exception raised when updating state of sensor.givtcp_ed225XXXXX_invertor_type, topic: 'GivEnergy/ED225XXXXX/Invertor_Details/Invertor_Type' with payload: b'Gen 2 Hybrid'
Exception raised when updating state of sensor.givtcp_dx225XXXXX_battery_serial_number, topic: 'GivEnergy/ED225XXXXX/Battery_Details/DX225XXXXX/Battery_Serial_Number' with payload: b'DX225XXXXX'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 579, in state
    numerical_value = int(value)
ValueError: invalid literal for int() with base 10: 'DX225XXXXX'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/mqtt/models.py", line 270, in process_write_state_requests
    entity.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 585, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 649, in _async_write_ha_state
    state = self._stringify_state(available)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 591, in _stringify_state
    if (state := self.state) is None:
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 583, in state
    raise ValueError(
ValueError: Sensor sensor.givtcp_dx225XXXXX_battery_serial_number has device class None, state class None unit  and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: DX225XXXXX (<class 'str'>)

String-656 · 2023-05-07T01:34:21Z

I also started getting a similar error after the latest update.. related to modbus sensor.

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 579, in state
    numerical_value = int(value)
ValueError: invalid literal for int() with base 10: 'nan'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/modbus/sensor.py", line 137, in async_update
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 585, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 649, in _async_write_ha_state
    state = self._stringify_state(available)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 591, in _stringify_state
    if (state := self.state) is None:
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 583, in state
    raise ValueError(
ValueError: Sensor sensor.inverter_dc_current has device class None, state class None unit A and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: nan (<class 'str'>)

hitnrun30 · 2023-05-08T19:50:14Z

I am getting this with a template

template:
  - sensor:
      - name: "Unavailable Entities"
        unique_id: unavailable_entities
        icon: "{{ iif(states(this.entity_id)|int(0) > 0,'mdi:alert-circle','mdi:check-circle') }}"
        unit_of_measurement: entities
        state: >
          {% set entities = state_attr(this.entity_id,'entity_id') %}
          {% if entities != none %} {{ entities|count }} {% endif %}
        attributes:
          entity_id: >
            {% set ignore_seconds = 60 %}
            {% set ignored = state_attr('group.ignored_entities','entity_id') %}
            {% set ignore_ts = (now().timestamp() - ignore_seconds)|as_datetime %}
            {% set entities = states|rejectattr('domain','eq','group')
                |rejectattr('last_changed','ge',ignore_ts)
                |selectattr('state','in',['unavailable','unknown','none'])%}
            {% if ignored != none %}
              {% set entities =  entities|rejectattr('entity_id','in',ignored) %}
            {% endif %}
            {{ entities|map(attribute='entity_id')|list }}

Error is
ValueError: Sensor sensor.unavailable_entities has device class None, state class None unit entities and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: (<class 'str'>)

stickpin · 2023-05-08T19:53:58Z

@hitnrun30 remove:
unit_of_measurement: entities

neilenns · 2023-05-08T19:55:21Z

A user reported this exception for my HomeAssistant add-on (neilenns/ambientweather2mqtt#99). It's a timestamp sensor and worked fine prior to this update.

Looks like it might be related to this pull request: https://github.com/home-assistant/core/pull/85605/files

Holland1 · 2023-05-09T08:34:12Z

I have a solution that could work for some.
As can be seen in the first post, in my case the battery status variable was the issue. The historic data is not relevant for me, so I deleted the variable.
The battery status variable was recreated automatically by the iOS integration, and the exception issue was solved.

hitnrun30 · 2023-05-09T12:29:56Z

@hitnrun30 remove: unit_of_measurement: entities

Thank you that did it.

CybDis · 2023-05-11T09:07:30Z

there seems to have been a breaking change, so that entites with unit_of_measurement: '' cause now an exception when assuming it is a numeric value.

Was this breaking change documented somewhere or is some fallback planned?

However, I could change all unit_of_measurement:'' to unit_of_measurement:'something' - but a usefull fallback seems reasonable

Dehumanizer77 · 2023-05-16T09:01:46Z

This is getting really annoying. I am having tens of thousands of these messages in the log and the log is cluttered with these messages, adding tens of megabytes per day...
I have this for several of my tasmota devices:
Exception raised when updating state of sensor.bojler_ds18b20_id, topic: 'tele/bojler/SENSOR' with payload: b'{"Time":"2023-05-16T10:00:37","DS18B20":{"Id":"0300A279A35F","Temperature":50.6},"TempUnit":"C"}' Exception raised when updating state of sensor.tasmota_mhz19b_model, topic: 'tele/spalna/SENSOR' with payload: b'{"Time":"2023-05-16T11:00:41","ANALOG":{"Illuminance":2},"MHZ19B":{"Model":"B","CarbonDioxide":400,"Temperature":24.0},"TempUnit":"C"}' Exception raised when updating state of sensor.brana_ds18b20_id, topic: 'tele/brana/SENSOR' with payload: b'{"Time":"2023-05-16T10:00:43","DS18B20":{"Id":"0416B08A50FF","Temperature":18.6},"TempUnit":"C"}' Exception raised when updating state of sensor.buda_ds18b20_id_2, topic: 'tele/buda/SENSOR' with payload: b'{"Time":"2023-05-16T11:00:44","DS18B20":{"Id":"01205F878BF2","Temperature":23.3},"TempUnit":"C"}' Exception raised when updating state of sensor.kurenie_v_bude_energy_totalstarttime, topic: 'tele/budaheat/SENSOR' with payload: b'{"Time":"2023-05-16T11:00:44","ENERGY":{"TotalStartTime":"2022-09-21T00:00:00","Total":169.255,"Yesterday":0.135,"Today":0.062,"Period":0,"Power":5,"ApparentPower":14,"ReactivePower":13,"Factor":0.34,"Voltage":245,"Current":0.056}}'

Dehumanizer77 · 2023-05-16T09:02:18Z

Is there any workaround I can use in my case?

skilletjohn · 2023-05-16T12:06:49Z

I'm having the same problem:

``Logger: homeassistant.components.mqtt.models
Source: components/sensor/init.py:583
Integration: MQTT (documentation, issues)
First occurred: 7:42:57 AM (88 occurrences)
Last logged: 7:54:57 AM

Exception raised when updating state of sensor.rain_barrel_ds18b20_id, topic: 'tele/RainBarrel/SENSOR' with payload: b'{"Time":"2023-05-16T12:46:57","Switch1":"ON","Switch2":"ON","Switch3":"ON","Switch4":"ON","Switch5":"ON","DS18B20":{"Id":"00000983A15A","Temperature":55.2},"TempUnit":"F"}'
Exception raised when updating state of sensor.rain_barrel_ds18b20_id, topic: 'tele/RainBarrel/SENSOR' with payload: b'{"Time":"2023-05-16T12:48:57","Switch1":"ON","Switch2":"ON","Switch3":"ON","Switch4":"ON","Switch5":"ON","DS18B20":{"Id":"00000983A15A","Temperature":55.1},"TempUnit":"F"}'
Exception raised when updating state of sensor.rain_barrel_ds18b20_id, topic: 'tele/RainBarrel/SENSOR' with payload: b'{"Time":"2023-05-16T12:50:57","Switch1":"ON","Switch2":"ON","Switch3":"ON","Switch4":"ON","Switch5":"ON","DS18B20":{"Id":"00000983A15A","Temperature":55.2},"TempUnit":"F"}'
Exception raised when updating state of sensor.rain_barrel_ds18b20_id, topic: 'tele/RainBarrel/SENSOR' with payload: b'{"Time":"2023-05-16T12:52:57","Switch1":"ON","Switch2":"ON","Switch3":"ON","Switch4":"ON","Switch5":"ON","DS18B20":{"Id":"00000983A15A","Temperature":55.1},"TempUnit":"F"}'
Exception raised when updating state of sensor.rain_barrel_ds18b20_id, topic: 'tele/RainBarrel/SENSOR' with payload: b'{"Time":"2023-05-16T12:54:57","Switch1":"ON","Switch2":"ON","Switch3":"ON","Switch4":"ON","Switch5":"ON","DS18B20":{"Id":"00000983A15A","Temperature":55.1},"TempUnit":"F"}'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/sensor/init.py", line 579, in state
numerical_value = int(value)
ValueError: invalid literal for int() with base 10: '00000983A15A'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/mqtt/models.py", line 270, in process_write_state_requests
entity.async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 585, in async_write_ha_state
self._async_write_ha_state()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 649, in _async_write_ha_state
state = self._stringify_state(available)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 591, in _stringify_state
if (state := self.state) is None:
File "/usr/src/homeassistant/homeassistant/components/sensor/init.py", line 583, in state
raise ValueError(
ValueError: Sensor sensor.rain_barrel_ds18b20_id has device class None, state class None unit and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: 00000983A15A (<class 'str'>)

My mqtt yaml:

- name: "RainBarrel_Temp"
  device_class: temperature
  state_topic: "tele/RainBarrel/SENSOR"
  availability_topic: "tele/RainBarrel/LWT"
  payload_available: "Online"
  payload_not_available: "Offline"
  unit_of_measurement: "°F"
  value_template: "{{ value_json['DS18B20'].Temperature }}"

My mqtt payload:

SENSOR = 
{"Time":"2023-05-16T13:02:57","Switch1":"ON","Switch2":"ON","Switch3":"ON","Switch4":"ON","Switch5":"ON","DS18B20":{"Id":"00000983A15A","Temperature":55.1},"TempUnit":"F"}

martin3000 · 2023-05-16T12:13:51Z

@epenet ist this a new problem or only a new message?

epenet · 2023-05-16T12:25:04Z

If it has a unit of measurement => the value MUST be a number or None
For a few months warnings were raised, but since 2023.5 invalid settings fail.

So there are two ways to fix:

either fix the unit of measurement, setting it to None (don't use empty string)
or fix the value, replacing things such as nan with None

For example:

ValueError: Sensor sensor.rain_barrel_ds18b20_id has device class None, state class None unit and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: 00000983A15A (<class 'str'>) the unit seems to be empty string, and needs to be replaced with None
ValueError: Sensor sensor.unavailable_entities has device class None, state class None unit entities and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: (<class 'str'>) the unit is set to entities, and needs to be replaced with None
ValueError: Sensor sensor.inverter_dc_current has device class None, state class None unit A and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: nan (<class 'str'>) the value is set to nan, and needs to be replaced with None
ValueError: Sensor sensor.givtcp_dx225XXXXX_battery_serial_number has device class None, state class None unit and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: DX225XXXXX (<class 'str'>) the unit seems to be a space character, and needs to be replaced with None

neilenns · 2023-05-16T12:39:22Z

If it has a unit of measurement => the value MUST be a number or None

Where is this documented? If the unit of measurement is TIMESTAMP my understanding is it is (and was) expected to be a string.

Dehumanizer77 · 2023-05-16T12:44:30Z

Also in my case the sensors are not manually defined, they are automatically added by MQTT integration, I can't change anything for those sensors...
Fortunatelly I have noticed that these errors are only happening on the ID sensor which is essentially useless, so I have disabled them.
The only non-id sensor with error is the sensor.kurenie_v_bude_energy_totalstarttime, which is date/time and it is expected to be string exactly as @neilenns says, so not really sure what is the problem there.

martin3000 · 2023-05-16T12:44:56Z

If it has a unit of measurement => the value MUST be a number

But this is not what the message says. It says:
"has device class None, state class None unit and suggested precision None thus indicating it has a numeric value"

epenet · 2023-05-16T12:51:51Z

"has device class None, state class None unit and suggested precision None thus indicating it has a numeric value"

device class None is good
state class None is good
unit is bad (it indicates that it has empty string as value)
suggested precision None is good

Each scenario here is different... and it should be resolved differently in each case.
The most common is that "" (empty string) is not a valid unit of measurement, and that needs to be resolved in the source of the sensor.

Dehumanizer77 · 2023-05-16T12:54:44Z

I suppose this is down to MQTT integration then, because the very same sensors loaded through different integration (Tasmota) show up OK without errors.

epenet · 2023-05-16T12:56:32Z

Another issue that I see above from @KruseLuds: Charging: 80 and Not charging: 80 are not valid numeric values.
If you want to use a numeric value, then use 80 without a prefix.
If you want to use a text value, then remove the unit of measurement and set it direction in your template Charging: 80% and Not charging: 80%

neilenns · 2023-05-16T12:57:15Z

"has device class None, state class None unit and suggested precision None thus indicating it has a numeric value"

device class None is good

state class None is good

unit is bad (it indicates that it has empty string as value)

suggested precision None is good

Each scenario here is different... and it should be resolved differently in each case. The most common is that "" (empty string) is not a valid unit of measurement, and that needs to be resolved in the source of the sensor.

Yes, there are some sensors that are incorrectly sending strings for numeric data. But others are doing it correctly (e.g. for timestamp values), and HomeAssistant is incorrectly reporting those as invalid. The change introduced for 2023.5.0 to enforce the numeric value appears to have forgotten to handle the case where the sensor value is supposed to be a string.

Edit: Here's one issue logged specifically for timestamp values.

home-assistant · 2023-05-16T12:57:24Z

Hey there @home-assistant/core, mind taking a look at this issue as it has been labeled with an integration (mobile_app) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of mobile_app can trigger bot actions by commenting:

@home-assistant close Closes the issue.
@home-assistant rename Awesome new title Renames the issue.
@home-assistant reopen Reopen the issue.
@home-assistant unassign mobile_app Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

mobile_app documentation
mobile_app source
_{^{(message by IssueLinks)}}

Dehumanizer77 · 2023-05-16T12:59:39Z

I suppose you wanted to add mqtt integration label, not mobile_app?

String-656 · 2023-05-16T13:02:55Z

I suppose you wanted to add mqtt integration label, not mobile_app?

I have the same issue with modus sensors... no change on my end for years.

epenet · 2023-05-16T13:02:59Z

I suppose you wanted to add mqtt integration label, not mobile_app?

No. I tagged as mobile_app because that is the original issue.
ValueError: Sensor sensor.iphone_van_marck_battery_state has device class battery, state class None unit None and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: Charging (<class 'str'>)

That one is (or was) a bug in mobile_app, which should not have set the device class battery when returning a Charging \ Not charging string.

epenet · 2023-05-16T13:04:51Z

I have the same issue with modus sensors... no change on my end for years.

You should open a separate issue for modbus. It should be adjusted to strip nan values.

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

justinmaiuto · 2023-05-17T23:38:10Z

similar issue here

#93205

ghost · 2023-05-20T12:40:47Z

I don't know why suddenly home assistant is now strictly enforcing typing of states. States in the past were always strings unless explicitly used in a manner that forces their conversion, ie. platform: numeric_state or manually converted via a template. I think this was the best way of handling it. Now it's assumed that if there is a unit of measurement the state must be convertible to a float or be None. Why? Of what benefit is this of the user?

Everyone who writes uses a template sensor, MQTT sensor must write in their own data sanitization to keep home assistant from throwing ugly exceptions. I thought the goal of this project was to make things more user friendly over time, but this move is completely backwards when we have to make the states compatible with raw python string to numeric conversion at all times.

Worse yet this isn't even compatible with how home assistant normally handles the state of sensors. If a sensor is malfunctioning or hasn't been completely initialized yet it is supposed to report unknown or unavailable. But even this standard behavior isn't being trapped. I have tons of template sensors that were coded to report unknown or unavailable to handle bad data. Now would have to change them to 'None'. Changing these well known error states to appease python's string to numeric conversion will look terrible on the frontend. Why is this burden being shifted onto the user instead of adding checks for these states?

emufan · 2023-05-20T14:32:01Z

And it seems to be not working as designed. Even a trigger template and check against a number and only take this then and otherwise the old value, which should be a number because of this rule is not working either. Where it should restore state on startup. But gives the same error.

Dehumanizer77 · 2023-05-20T14:36:54Z

Well said, I can't think of what was the point of this change.

glarwill · 2023-05-20T15:22:41Z

A quote from a great man, as noted on wikipedia… In computing <https://en.m.wikipedia.org/wiki/Computing>, the *robustness principle* is a design guideline for software that states: "be conservative in what you do, be liberal in what you accept from others". It is often reworded as: "be conservative in what you send, be liberal in what you accept". The principle is also known as *Postel's law*, after Jon Postel <https://en.m.wikipedia.org/wiki/Jon_Postel>, who used the wording in an early specification of TCP <https://en.m.wikipedia.org/wiki/Transmission_Control_Protocol>.[1] <https://en.m.wikipedia.org/wiki/Robustness_principle#cite_note-1>

On Sat, May 20, 2023 at 07:37 JoHnY ***@***.***> wrote: Well said, I can't think of what was the point of this change. — Reply to this email directly, view it on GitHub <#92483 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN5FLPAVLOPD4UJKA7O4H33XHDJJHANCNFSM6AAAAAAXVSQEYU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Glen Larwill

…

-- opinions expressed are my own - no connection to my employer --

ghost · 2023-05-20T17:39:23Z

I've been experimenting to see if I can even create a template sensor that can return a 'None' to satisfy the string to numeric conversion. Is this even possible? The string 'None' won't work. Hard coding a 'None' in yaml as 'null' throws an error because a none type is invalid according to the yaml parser. An empty string is still a string. If I can only represent the state as a string in a template or mqtt sensor, but a python None can't be represented as a string, then now we got an unresolvable problem.

emufan · 2023-05-21T06:53:33Z

I've been experimenting to see if I can even create a template sensor that can return a 'None' to satisfy the string to numeric conversion. Is this even possible? The string 'None' won't work. Hard coding a 'None' in yaml as 'null' throws an error because a none type is invalid according to the yaml parser. An empty string is still a string. If I can only represent the state as a string in a template or mqtt sensor, but a python None can't be represented as a string, then now we got an unresolvable problem.

That is the result of my tests as well.

Secondly a trigger template should restore it's state at startup. And then I tried to set a change trigger on the source, which is perhaps not available on startup of the template and a trigger on ha-start and a if with is_number, so that the template should either take his old (or restored value) number value or the/a new number value from source. But it returns the same error on startup for whatever reasons because it should work, at least think so.

Can anyone or the one who implemented this error message (was it you @epenet in #85605?) please give one single example how to define now a template sensor with a number state class or a uom and which is working without error at system start?

ghost · 2023-05-21T10:43:54Z

For templates the solution seems to be {{None}}. Home assisant will generously convert all sorts of strings to python booleans, but for a None type only {{None}} via Jinja will do. This will be converted back into a string as the state 'unknown'.

For your trigger templates, I think I have an idea of what could be wrong as I encountered this issue. If a trigger based template throws the exception due to a failed string to numeric conversion the trigger gets disabled until hass is rebooted. You can have a whole block of template sensors under one trigger and if any one of those throws the exception the whole block no longer triggers. Later in the week I'll see if I can come up with a reproducer configuration and open an issue for that.

drjjr2 · 2023-05-22T20:52:27Z

So this went away for me when I deleted my iPhone from the mobile integration and then let it get re-added when I ran the iOS companion app.

epenet · 2023-05-22T21:01:36Z

So this went away for me when I deleted my iPhone from the mobile integration and then let it get re-added when I ran the iOS companion app.

Thanks for confirming.
Other integrations should be tracked in separate issues.

oz-glenn · 2023-05-24T05:28:20Z

So this went away for me when I deleted my iPhone from the mobile integration and then let it get re-added when I ran the iOS companion app.

This fixed it for me, too.

FiTekno · 2023-05-24T20:33:12Z

I updated my Home Assistant and now I get from some of devices:

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

ValueError: Sensor sensor.fr_re22210040331_radon_uptime_string has device class None, state class measurement unit None and suggested precision None thus indicating it has a numeric value; however, it has the non-numeric value: 3d 11:27:36 (<class 'str'>)

So this means those are not shown on HA anymore. How to fix this?

They was working before update just fine.

epenet · 2023-05-25T07:46:56Z

The issue here is closed. Please open a new issue describing precisely which integration the sensors belong to.

Holland1 changed the title ~~Exception: state class None: numeric value, however, it has the non-numeric value.~~ Exception since 2023.5.0: state class None: numeric value, however, it has the non-numeric value. May 4, 2023

gieljnssns mentioned this issue May 5, 2023

Ecowitt Integration - integration looses support of strike distance value #92496

Closed

stickpin mentioned this issue May 5, 2023

[BUG] Error after upgrading to Home Assistant 2023.5.0 robinostlund/homeassistant-volkswagencarnet#474

Closed

3 tasks

epenet added the integration: mobile_app label May 16, 2023

String-656 mentioned this issue May 20, 2023

Modbus - Exception since 2023.5.0: state class None: numeric value, however, it has the non-numeric value. #93297

Closed

epenet closed this as completed May 22, 2023

emufan mentioned this issue May 23, 2023

Exception since 2023.5.0: state class None: numeric value, however, it has the non-numeric value #93386

Closed

justinmaiuto mentioned this issue May 24, 2023

Ariela alarm sensor broken in 2023.5 #93205

Closed

epenet mentioned this issue May 24, 2023

Companion app battery_state updates are failing since 2023.5.2 #92719

Closed

home-assistant locked and limited conversation to collaborators May 25, 2023

Exception since 2023.5.0: state class None: numeric value, however, it has the non-numeric value. #92483

Exception since 2023.5.0: state class None: numeric value, however, it has the non-numeric value. #92483

Comments

Holland1 commented May 4, 2023 • edited Loading

The problem

What version of Home Assistant Core has the issue?

What was the last working version of Home Assistant Core?

What type of installation are you running?

Integration causing the issue

Link to integration documentation on our website

Diagnostics information

Example YAML snippet

Anything in the logs that might be useful for us?

Additional information

KruseLuds commented May 5, 2023 • edited Loading

e10kstarfire commented May 7, 2023

String-656 commented May 7, 2023 • edited Loading

hitnrun30 commented May 8, 2023

stickpin commented May 8, 2023

neilenns commented May 8, 2023

Holland1 commented May 9, 2023

hitnrun30 commented May 9, 2023

CybDis commented May 11, 2023

Dehumanizer77 commented May 16, 2023

Dehumanizer77 commented May 16, 2023

skilletjohn commented May 16, 2023

martin3000 commented May 16, 2023

epenet commented May 16, 2023 • edited Loading

neilenns commented May 16, 2023

Dehumanizer77 commented May 16, 2023

martin3000 commented May 16, 2023

epenet commented May 16, 2023 • edited Loading

Dehumanizer77 commented May 16, 2023

epenet commented May 16, 2023

neilenns commented May 16, 2023 • edited Loading

home-assistant bot commented May 16, 2023

Dehumanizer77 commented May 16, 2023

String-656 commented May 16, 2023

epenet commented May 16, 2023 • edited Loading

epenet commented May 16, 2023

justinmaiuto commented May 17, 2023

ghost commented May 20, 2023

emufan commented May 20, 2023

Dehumanizer77 commented May 20, 2023

glarwill commented May 20, 2023 via email

ghost commented May 20, 2023

emufan commented May 21, 2023 • edited Loading

ghost commented May 21, 2023

drjjr2 commented May 22, 2023

epenet commented May 22, 2023

oz-glenn commented May 24, 2023

FiTekno commented May 24, 2023

epenet commented May 25, 2023

Holland1 commented May 4, 2023 •

edited

Loading

KruseLuds commented May 5, 2023 •

edited

Loading

String-656 commented May 7, 2023 •

edited

Loading

epenet commented May 16, 2023 •

edited

Loading

epenet commented May 16, 2023 •

edited

Loading

neilenns commented May 16, 2023 •

edited

Loading

epenet commented May 16, 2023 •

edited

Loading

emufan commented May 21, 2023 •

edited

Loading