Ikea Air quality sensor (E2112) report rate too high (blocks Z2MQTT)

[BelHaUser]

What happened?

After adding Ikea E2112 Air quality monitor to Z2M, connection is lost to other devices after a few hours. Probably this is due to the E2112 publishing to MQTT around once second. I tried to change the reporting interval, but I can not achieve this for pm25Measurement, which gives an error when trying to do so (Invalid data type). On log grab include one can see the MQTT message rate and the error when trying to change the reporting limits. Firmware on E2112 was update from 1.0.010 to 1.0.11 without change in behaviour

What did you expect to happen?

I would expect to be able to limit the reporting speed of E2112

How to reproduce it (minimal and precise)

No special actions taken (check the log to see the messages)

Zigbee2MQTT version

1.35.1

Adapter firmware version

6.10.3.0 build 297

Adapter

Sonoff USB ZBDongle-E

Setup

Home Assistant Add-on on Raspberry Pi 4

Debug log

No response

[Hundhausen]

I do suspect the same thing but instead of hours, its a few days.

The only thing that I spotted that looks weird is the log duration. The logs are created every hour (pretty much spot on) and from the first few lines, it looks like it restarted. Only from 7pm to 9pm it ran 2 hours and 11pm it restarted a 2nd time but this time it was an updated and the previous log did contained a shutdown log message. An hour later jet again a restart but then no logs until 3am and then my manual restart at 7am.

The logs didn't contained much, except the air quality sensor every second with a status update. Before that device, I had no crashes but now within the 3 weeks I have it, it's my 3rd or 4th crash.

Besides that, I don't need the device to report every second.

[sjorge]

@Koenkk jusr FYI, this is because we don't store the manually passed DT in the db.

We now pass the DT for this attribute on this device because it doesn't match with the cluster default (And the device doesn't accept it either when sending with a manufacturerCode), so we set it manually in the configure. As for decode it doesn't matter if it's uint8 or singleperc.

It was mentioned on that PR that configuring vis frontend would still be broken.

It should work fine using mqtt if we pass the DT though. Not near my computer atm so i can't grab the proper payload from my history.

[sjorge]

This is from memory as I can't access my setup from work:

mosquitto_pub -t zigbee2mqtt/bridge/request/device/configure_reporting -m '{"id": "0x50325ffffe146729/1", "cluster": "pm25Measurement", "attrbute": {"ID": 0, "DataType": 57}, "minimum_report_interval": 900, "maximum_report_interval": 900, "reportable_change": 0}'

Probably increasing reportable_change to something like 5 or 10 would probably also fix it.

[BelHaUser]

Updating to Z2M 1.35.3 solved the continuous reporting and stability problem.

Note that the changing the reporting rate of pm25Measurement still results in an error.

[sjorge]

As noted in the PR, setting it via the frontend will always be broken. There is bo way to fix this. You can set it via mqtt if you provide the datatype.

[sjorge]

As noted in the PR, setting it via the frontend will always be broken. There is bo way to fix this. You can set it via mqtt if you provide the datatype.

This has been fixed actually, so you can reconfigure via the frontend if the default is still too much.

[cbrunnkvist]

Just chiming in here in order to confirm that yes pushing settings via the UI works fine now. I do find it strange that one E2112 device would default to too-long update intervals (mine, remember?) while others (@BelHaUser's) comes out of the box with interval set to 1 second? Actually, the exact cause doesn't really matter as long as it can be (re-)set to something sane (=mine has been stable as a rock since 1.37.0 🙂)

[sjorge]

https://github.com/Koenkk/zigbee-herdsman-converters/blob/3e56ca454b942b4780f08976e81de93982f89606/src/devices/ikea.ts#L988

Newly paired devices should come with a more sane:

pm25({reporting: {min: '1_MINUTE', max: '2_MINUTES', change: 2}}),

Which seems to mirror your screenshot, it could be that those with more agressive intervals were paired before that and never got a reconfigure.