Closed uvjim closed 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
Same issue for ConBee II and Eurotronic thermostat (SPZB0001)
Same here - looks like duplicate issue:
https://github.com/Koenkk/zigbee2mqtt/issues/8963#issuecomment-933013963
@uvjim could you try to set the occupancy_timeout
once via the frontend (for Porch - Motion Sensor
)? (does this fix the problem?)
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
@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?
If I set my value for "overload_protection" in GUI to any value, log error no longer appears.
@uvjim could you try to set the
occupancy_timeout
once via the frontend (forPorch - Motion Sensor
)? (does this fix the problem?)
I rolled back but can have a look at some point today if that helps.
@uvjim could you try to set the
occupancy_timeout
once via the frontend (forPorch - 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 publishesnull
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.
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...
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.
@emontnemery I think it would be nicer to allow for an unknown
value (like it is for all other MQTT sensors)
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.
@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.
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?
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)
@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).
How come the values are unknown, do the devices only support writing, not reading, the value?
@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)
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.
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.
@emontnemery perfect, thanks again!
Will close this since it will be solved in HA.
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)
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.
'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
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
{
"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
}
What happened
Upgraded to latest version and new warnings started to appear in the logs.
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