Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.96k stars 1.67k forks source link

Payload... is not a number #8960

Closed uvjim closed 3 years ago

uvjim commented 3 years ago

What happened

Upgraded to latest version and new warnings started to appear in the logs.

Logger: homeassistant.components.mqtt.number
Source: components/mqtt/number.py:146
Integration: MQTT (documentation, issues)
First occurred: 14:48:29 (31 occurrences)
Last logged: 14:52:33

Payload '{"battery":null,"device":{"applicationVersion":2,"dateCode":"20190219","friendlyName":"Porch - Motion Sensor","hardwareVersion":1,"ieeeAddr":"0x001788010918ca74","manufacturerID":4107,"manufacturerName":"Philips","model":"9290012607","networkAddress":32262,"powerSource":"Battery","softwareBuildID":"6.1.1.27575","stackVersion":1,"type":"EndDevice","zclVersion":1},"illuminance":18519,"illuminance_lux":71,"last_seen":"2021-10-02T13:51:54.136Z","led_indication":null,"linkquality":255,"motion_sensitivity":null,"occupancy":true,"occupancy_timeout":null,"temperature":15.32,"update":{"state":"idle"}}' is not a Number
Payload '{"battery":null,"device":{"applicationVersion":2,"dateCode":"20190219","friendlyName":"Porch - Motion Sensor","hardwareVersion":1,"ieeeAddr":"0x001788010918ca74","manufacturerID":4107,"manufacturerName":"Philips","model":"9290012607","networkAddress":32262,"powerSource":"Battery","softwareBuildID":"6.1.1.27575","stackVersion":1,"type":"EndDevice","zclVersion":1},"illuminance":18410,"illuminance_lux":69,"last_seen":"2021-10-02T13:52:04.098Z","led_indication":null,"linkquality":255,"motion_sensitivity":null,"occupancy":true,"occupancy_timeout":null,"temperature":15.32,"update":{"state":"idle"}}' is not a Number
Payload '{"battery":null,"device":{"applicationVersion":2,"dateCode":"20190219","friendlyName":"Porch - Motion Sensor","hardwareVersion":1,"ieeeAddr":"0x001788010918ca74","manufacturerID":4107,"manufacturerName":"Philips","model":"9290012607","networkAddress":32262,"powerSource":"Battery","softwareBuildID":"6.1.1.27575","stackVersion":1,"type":"EndDevice","zclVersion":1},"illuminance":18326,"illuminance_lux":68,"last_seen":"2021-10-02T13:52:14.038Z","led_indication":null,"linkquality":255,"motion_sensitivity":null,"occupancy":true,"occupancy_timeout":null,"temperature":15.32,"update":{"state":"idle"}}' is not a Number
Payload '{"battery":null,"device":{"applicationVersion":2,"dateCode":"20190219","friendlyName":"Porch - Motion Sensor","hardwareVersion":1,"ieeeAddr":"0x001788010918ca74","manufacturerID":4107,"manufacturerName":"Philips","model":"9290012607","networkAddress":32262,"powerSource":"Battery","softwareBuildID":"6.1.1.27575","stackVersion":1,"type":"EndDevice","zclVersion":1},"illuminance":18248,"illuminance_lux":67,"last_seen":"2021-10-02T13:52:23.979Z","led_indication":null,"linkquality":255,"motion_sensitivity":null,"occupancy":true,"occupancy_timeout":null,"temperature":15.32,"update":{"state":"idle"}}' is not a Number
Payload '{"battery":null,"device":{"applicationVersion":2,"dateCode":"20190219","friendlyName":"Porch - Motion Sensor","hardwareVersion":1,"ieeeAddr":"0x001788010918ca74","manufacturerID":4107,"manufacturerName":"Philips","model":"9290012607","networkAddress":32262,"powerSource":"Battery","softwareBuildID":"6.1.1.27575","stackVersion":1,"type":"EndDevice","zclVersion":1},"illuminance":18154,"illuminance_lux":65,"last_seen":"2021-10-02T13:52:33.910Z","led_indication":null,"linkquality":255,"motion_sensitivity":null,"occupancy":true,"occupancy_timeout":null,"temperature":15.32,"update":{"state":"idle"}}' is not a Number

I did clear the HASS logs and restart the add-on but the messages came back (hence only 31 occurrences in this report).

What did you expect to happen

No new warnings - I normally have some that I'm aware of.

How to reproduce it (minimal and precise)

In my case nothing is needed. I just upgraded and left the HASS addon running.

Debug info

Zigbee2MQTT version: 1.21.2-1 Adapter hardware: RaspBee 2 Adapter firmware version: 0x26690700

gazelle-hub commented 3 years ago

I have the same eror after upgrading to version 1.21.2-1.

2021-10-03 09:24:03 WARNING (MainThread) [homeassistant.components.mqtt.number] Payload '{"battery":100,"humidity":68,"humidity_calibration":null,"illuminance":26735,"illuminance_calibration":null,"illuminance_lux":471,"keep_time":null,"led_enable":true,"linkquality":255,"occupancy":true,"pir_enable":true,"reporting_enable":true,"reporting_time":0,"sensitivity":null,"tamper":false,"temperature":19.4,"temperature_calibration":null,"voltage":0}' is not a Number

maureis commented 3 years ago

Same issue for ConBee II and Eurotronic thermostat (SPZB0001)

aegjoyce commented 3 years ago

Same here - looks like duplicate issue:

https://github.com/Koenkk/zigbee2mqtt/issues/8963#issuecomment-933013963

Koenkk commented 3 years ago

@uvjim could you try to set the occupancy_timeout once via the frontend (for Porch - Motion Sensor)? (does this fix the problem?)

dankocrnkovic commented 3 years ago

Same here. Logger: homeassistant.components.mqtt.number Source: components/mqtt/number.py:146 Integration: MQTT (documentation, issues) First occurred: 22:05:54 (13 occurrences) Last logged: 22:17:29

Payload '{"auto_off":false,"consumer_connected":true,"consumption":17.6,"current":0,"energy":17.6,"led_disabled_night":true,"linkquality":66,"overload_protection":null,"power":0,"power_outage_memory":true,"state":"OFF","temperature":21,"update":{"state":"idle"},"update_available":false,"voltage":228}' is not a Number Payload '{"auto_off":false,"consumer_connected":false,"consumption":13.38,"current":0,"energy":13.38,"led_disabled_night":true,"linkquality":72,"overload_protection":null,"power":0,"power_outage_memory":true,"state":"ON","temperature":21,"update":{"state":"idle"},"update_available":false,"voltage":228}' is not a Number Payload '{"auto_off":false,"consumer_connected":false,"consumption":13.38,"current":0,"energy":13.38,"led_disabled_night":true,"linkquality":66,"overload_protection":null,"power":0,"power_outage_memory":true,"state":"ON","temperature":21,"update":{"state":"idle"},"update_available":false,"voltage":228}' is not a Number Payload '{"auto_off":false,"consumer_connected":false,"consumption":13.38,"current":0,"energy":13.38,"led_disabled_night":true,"linkquality":72,"overload_protection":null,"power":0,"power_outage_memory":true,"state":"OFF","temperature":21,"update":{"state":"idle"},"update_available":false,"voltage":228}' is not a Number Payload '{"auto_off":false,"consumer_connected":false,"consumption":13.38,"current":0,"energy":13.38,"led_disabled_night":true,"linkquality":69,"overload_protection":null,"power":0,"power_outage_memory":true,"state":"OFF","temperature":21,"update":{"state":"idle"},"update_available":false,"voltage":228}' is not a Number

Koenkk commented 3 years ago

@emontnemery If I understand correctly, the MQTT number component cannot handle null values. Z2M publishes null because the value is unknown, how to handle this?

dankocrnkovic commented 3 years ago

If I set my value for "overload_protection" in GUI to any value, log error no longer appears.

uvjim commented 3 years ago

@uvjim could you try to set the occupancy_timeout once via the frontend (for Porch - Motion Sensor)? (does this fix the problem?)

I rolled back but can have a look at some point today if that helps.

uvjim commented 3 years ago

@uvjim could you try to set the occupancy_timeout once via the frontend (for Porch - Motion Sensor)? (does this fix the problem?)

Good news. I set the occupancy_timeout prior to upgrading. I then upgraded and have not seen the warnings since.

@emontnemery If I understand correctly, the MQTT number component cannot handle null values. Z2M publishes null because the value is unknown, how to handle this?

This would be good to know. The motion sensors don't have a value set by default when they join the Zigbee network so I envisage that I'll see these warnings if I add any more - that is until I can set a timeout for them.

Mr-Groch commented 3 years ago

I have same problem for Tuya Siren Alarm:

Payload '{"alarm":false,"battery_low":false,"duration":null,"humidity":58,"humidity_alarm":false,"humidity_max":90,"humidity_min":20,"last_seen":"2021-10-05T08:47:08+02:00","linkquality":78,"melody":7,"power_type":"usb","temperature":"20.2","temperature_alarm":false,"temperature_max":90,"temperature_min":0,"volume":"high"}' is not a Number

"duration":null but for this device duration always will be null. When I set duration it will store the value but it always report back null...

emontnemery commented 3 years ago

If the state is not known but it will be known when the device updates its state, I'd suggest to initially set the device to unavailable.

Koenkk commented 3 years ago

@emontnemery I think it would be nicer to allow for an unknown value (like it is for all other MQTT sensors)

emontnemery commented 3 years ago

MQTT sensor is a special case because you're allowed to pretty much directly write the state, Home Assistant does not make any assumptions on the type of the state, such as it should be a valid number for a temperature sensor. Maybe it should though.

For other MQTT components this doesn't hold, a switch or binary sensor can be updated to "on" or "off", but not to "unknown". If you want to mark such components being in an unknown state, use availability.

Edit: number is also a special case as it allows the value to be None, but this was not supported by MQTT number.

Koenkk commented 3 years ago

@emontnemery if I understand correctly, there is no intention to add support for a default value? If not, I will check what I can do with a value template.

emontnemery commented 3 years ago

Could you explain the use case a bit more, what do the number entities represent? When the value is not known, will attempts by the user to set the number from the frontend work? If you set the number entity's state to a default value, is that helpful or just misleading?

aegjoyce commented 3 years ago

Issue also fixed for me by setting values for objects previously set as null. However I agree with @Koenkk - my thermostats, and I imagine lots of other devices, have some settings which after initial setup and pairing do not have default values set - having a more graceful way of handling null values would be more user-friendly.

In my case it was some more granular settings like deadzone temperature and max temperature limits - stuff I had never used previously (Moes BHT-002)

Koenkk commented 3 years ago

@emontnemery they represent all sort of things, e.g. the Hue motion sensor allows settings the occupancy_timeout (in seconds), initially this value is unknown, but the user could set this value (or not which is also fine). Giving a default value could be misleading here, and figuring out the real value for all devices is not feasible (given the amount of devices).

emontnemery commented 3 years ago

How come the values are unknown, do the devices only support writing, not reading, the value?

Koenkk commented 3 years ago

@emontnemery because the device did not report the value yet, for some devices this can be solved by reading it, but for some not since they don't support reading (e.g. some crappy chinese devices)

emontnemery commented 3 years ago

Oh, OK. I noticed now that the number base entity allows setting the value to None, so we should allow that in MQTT number too.

emontnemery commented 3 years ago

This adds support for setting an MQTT number to None: https://github.com/home-assistant/core/pull/57161

This will work as is for JSON data, because a null JSON value will render to the string None if the value is extracted with a value_template such as: "value_template": "{{ value_json.val }}".

If the HA PR is accepted it will land in HA 2021.11. It's too late to add new features to HA 2021.10.

Koenkk commented 3 years ago

@emontnemery perfect, thanks again!

Will close this since it will be solved in HA.

JeanMertz commented 2 years ago

One thing I noticed, is that I had the same happening to me, even though I've set device_options for the specific attributes that reported as null in the MQTT messages picked up by HA.

Here is my device options:

device_options:
  transition: 1
  legacy: false
  led_disabled_night: false
  power_outage_memory: true
  auto_off: false
  led_indication: false
  color_sync: true
  retain: true
  optimistic: true
  filtered_optimistic:
    - color
    - color_temp

Yet, here is one of the many warning messages I saw:

2021-10-29 20:32:11 WARNING (MainThread) [homeassistant.components.mqtt.number] Payload '{"auto_off":null,"consumer_connected":null,"consumption":2.77,"current":0.0026,"energy":2.77,"last_seen":"2021-10-29T18:32:11.654Z","led_disabled_night":null,"linkquality":30,"overload_protection":null,"power":0.6,"power_outage_memory":null,"state":"ON","temperature":24,"voltage":226}' is not a Number

I'm fairly positive that I added at least some of these devices after I configured zigbee2mqtt to use these default device options.

(going through all my devices one-by-one, and setting the flags manually did solve the warnings, as indicated in this thread)

geigervibe commented 1 year ago

I have one device (TS0201) which still has above described problem, with one big difference that all fields have valid values. 3000 log entries have been accumulated for 4 days. What can be the reason for this in my case? I am using the Z2M version 1.30.3-1.

The device-config looks like this:

'0x804b50fffe028867':
  friendly_name: zb_tempsensor_d3
  filtered_attributes:
    - battery
    - alarm_humidity
    - alarm_humidity_max
    - alarm_humidity_min
    - alarm_temperature
    - alarm_temperature_max
    - alarm_temperature_min

and the HA-logs as follows:

Logger: homeassistant.components.mqtt.number
Source: components/mqtt/number.py:159
Integration: MQTT ([documentation](https://www.home-assistant.io/integrations/mqtt), [issues](https://github.com/home-assistant/home-assistant/issues?q=is%3Aissue+is%3Aopen+label%3A%22integration%3A+mqtt%22))
First occurred: 12. Juni 2023, 20:56:36 (3036 occurrences)
Last logged: 14:18:42

Payload '{"humidity":55.7,"illuminance":16991,"illuminance_lux":50,"last_seen":"2023-06-16T13:56:28+02:00","linkquality":126,"temperature":20.9,"voltage":2500}' is not a Number
Payload '{"humidity":55.7,"illuminance":16991,"illuminance_lux":50,"last_seen":"2023-06-16T14:01:11+02:00","linkquality":120,"temperature":22,"voltage":2500}' is not a Number
Payload '{"humidity":55.7,"illuminance":16991,"illuminance_lux":50,"last_seen":"2023-06-16T14:01:12+02:00","linkquality":117,"temperature":22,"voltage":2500}' is not a Number
Payload '{"humidity":55.7,"illuminance":16991,"illuminance_lux":50,"last_seen":"2023-06-16T14:01:13+02:00","linkquality":117,"temperature":22,"voltage":2500}' is not a Number
Payload '{"humidity":55.7,"illuminance":16991,"illuminance_lux":50,"last_seen":"2023-06-16T14:18:42+02:00","linkquality":123,"temperature":22,"voltage":2500}' is not a Number

The Z2M state looks like:

{
    "alarm_humidity": "off",
    "alarm_humidity_max": 90,
    "alarm_humidity_min": 20,
    "alarm_temperature": "off",
    "alarm_temperature_max": 40,
    "alarm_temperature_min": 10,
    "battery": 1,
    "humidity": 55.7,
    "illuminance": 16991,
    "illuminance_lux": 50,
    "last_seen": "2023-06-16T14:57:00+02:00",
    "linkquality": 120,
    "temperature": 22,
    "voltage": 2500
}