Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge πŸŒ‰, get rid of your proprietary Zigbee bridges πŸ”¨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
12.07k stars 1.68k forks source link

Reduce reporting interval on the TS0601 air quality sensor #8966

Closed CornerBit closed 2 years ago

CornerBit commented 3 years ago

What happened

The device reports sensor values too frequently at approximately 200ms intervals. Below is an example of the reports I see:

info MQTT publish: topic 'zigbee2mqtt/0x<snip>', payload '{"co2":1,"elapsed":202,"formaldehyd":358,"humidity":56,"last_seen":"2021-10-03T01:33:07.265Z","linkquality":24,"temperature":24,"voc":0}'
info MQTT publish: topic 'zigbee2mqtt/0x<snip>', payload '{"co2":1,"elapsed":199,"formaldehyd":358,"humidity":56,"last_seen":"2021-10-03T01:33:07.465Z","linkquality":18,"temperature":24,"voc":0}'
info MQTT publish: topic 'zigbee2mqtt/0x<snip>', payload '{"co2":1,"elapsed":202,"formaldehyd":358,"humidity":56,"last_seen":"2021-10-03T01:33:07.667Z","linkquality":27,"temperature":24,"voc":0}'

I'm not sure how to reduce the reporting interval on the device. I can see the manuSpecificTuya cluster but no attributes are listed for it under the Reporting tab in the UI. I noticed a few other people have similar reporting interval issues in #7299. Any assistance with this would be greatly appreciated!

Debug info

Zigbee2MQTT version: 1.21.2 Adapter hardware: CC26X2R1

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

CornerBit commented 2 years ago

Still seeing this issue in the latest version.

kkossev commented 2 years ago

@CornerBit Even when paired to Tuya gateway, this crappy device bombards the Zigbee network every second! I have switched mine off until a device firmware update is available that will allow configuration of the reporting intervals (highly unlikely..)

CornerBit commented 2 years ago

@kkossev thanks for confirming it's a bug on the device end. Hopefully they do release an update, but I have my doubts...

RuneNyhuus commented 2 years ago

Yeah i have the same problem... the zigbee2mqtt is running like crazy with this device turned on.

VikeDragon commented 2 years ago
dedors commented 2 years ago

My device never goes below 4 messages/sec and spams up to 10/s. It's pretty crazy. (TZE200_yvx5lh6k / round model)

harryohalloran commented 2 years ago

@CornerBit Even when paired to Tuya gateway, this crappy device bombards the Zigbee network every second! I have switched mine off until a device firmware update is available that will allow configuration of the reporting intervals (highly unlikely..)

Where do you even find the latest firmware updates? I was having trouble locating on the Tuya site. I'm having the same issue and it's causing problems with other devices based on the high amount of traffic on the network.

kkossev commented 2 years ago

Where do you even find the latest firmware updates? I was having trouble locating on the Tuya site. I'm having the same issue and it's causing problems with other devices based on the high amount of traffic on the network.

Firmware updates are available sometimes when the device is paired to Tuya gateway. But currently, there are no updates for TS0601.

There is something that I can't understand. The company (companies) that produce this crap should have become broke already - Tuya charges the manufacturers per the number of the API calls or messages sent to the cloud servers - https://developer.tuya.com/en/docs/iot/membership-service?id=K9m8k45jwvg9j

github-actions[bot] commented 2 years ago

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

aaamoeder commented 2 years ago

also noticing this. Is there no way to limit this ? I have 2 and it's very taxiing on my gateway.

jamesanf commented 2 years ago

also researching this too – i get an update every 2-3 seconds on every sensor in the device. it's not needed and is flooding my network. while i wait for a firmware update, is it at least possible for zigbee2mqtt to increase the interval it reports these values to HA?

aaamoeder commented 2 years ago

also researching this too – i get an update every 2-3 seconds on every sensor in the device. it's not needed and is flooding my network. while i wait for a firmware update, is it at least possible for zigbee2mqtt to increase the interval it reports these values to HA?

I have currently excluded these sensors from the recorder to relieve stress on the Database and have created filter sensors for the ones I like to have historical data for. Not a fix, but a workable workaround.

jamesanf commented 2 years ago

That sounds sort of like what I need to do. Does by filter sensor do you mean a derivative sensor for the overactive ones? If so would you mind sharing your code? I'm interested in how you reduced the update rate of the new sensor

jamesanf commented 2 years ago

also researching this too – i get an update every 2-3 seconds on every sensor in the device. it's not needed and is flooding my network. while i wait for a firmware update, is it at least possible for zigbee2mqtt to increase the interval it reports these values to HA?

I have currently excluded these sensors from the recorder to relieve stress on the Database and have created filter sensors for the ones I like to have historical data for. Not a fix, but a workable workaround.

I also wonder if you have tried to use the debounce feature in zigbee2mqtt's individual device.yaml settings? I've tried it, but anything above 'debounce: 2' kills all MQTT reporting altogether. But maybe I'm using it wrong?

aaamoeder commented 2 years ago

That sounds sort of like what I need to do. Does by filter sensor do you mean a derivative sensor for the overactive ones? If so would you mind sharing your code? I'm interested in how you reduced the update rate of the new sensor

look into the recorder and filter sensors ;-)

bartplessers commented 2 years ago

above 'debounce: 2' kills all MQ

same here. It's 'better" but still to much messages.

jamesanf commented 2 years ago

above 'debounce: 2' kills all MQ

same here. It's 'better" but still to much messages.

It basically meant that the device was dead, except for a seemingly random (and seemingly inaccurate) update 2-3 times a day. In the end I gave up; I don't know why the debounce broke it, everything I read seemed to suggest that it would just reduce the messages not eliminate them. I experimented with a few different debounce values before scrapping the device entirely. It will sit in a drawer until somebody can find a good fix – hopefully soon!

All in all, not worth the effort for a cheap and probably not very accurate sensor...

aaamoeder commented 2 years ago

is there any news on this ? I've had to disconnect our sensors due to zigbee network problems caused by the sensors overloading the network apparently..

JoryHogeveen commented 2 years ago

Same issue here, wen't through the available clusters and even the Tuya docs but couldn't find anything relative to this topic...

Related: https://github.com/zigpy/zha-device-handlers/issues/1470 Related: https://github.com/Koenkk/zigbee2mqtt/issues/8154 Related: https://github.com/Koenkk/zigbee2mqtt/issues/8220

@Koenkk Maybe reopen this topic as it's still an issue?

jamesanf commented 2 years ago

Same issue here, wen't through the available clusters and even the Tuya docs but couldn't find anything relative to this topic...

Related: zigpy/zha-device-handlers#1470 Related: #8154 Related: #8220

@Koenkk Maybe reopen this topic as it's still an issue?

I also hit the same brick walls. After my last reply to this thread I told the supplier, who then just gave me the money back straight away no questions asked – that makes me think it's a pretty common/known issue. I'd still love to have it back in my network so do post the fix here if you find one.

And if there's a better/working air quality sensor in a similar price band, I'm all ears.

Saharok14 commented 1 year ago

The same problem... Does anyone have a workaround?

fonsmeesters commented 1 year ago

Same problem here. I have 4 of these sensors and my home assistant database is getting out of control....

kbickar commented 1 year ago

Seeing the same issue with https://www.zigbee2mqtt.io/devices/TS0601_smart_human_presence_sensor_1.html getting a message every second

elupus commented 11 months ago

Seem the issue also exist with ZHA integration in HA. So maybe not anything that can be done about it?

McGiverGim commented 10 months ago

I've just bought this device :( and the problem remains...

I have added a "debounce" value of 100 but with "ignore debounce" for "temperature", in this way at least I spam a lot less HA, only when "temperature" changes... It continues being a lot but is a lot less than default. But this is only from z2m to HA, the device continues spamming the zigbee network.

Another question: in theory according to the manual:

Do you have this high values too? To me it seems the units are wrong and they must be converted, probably dividing by 1000.

amateurishere commented 9 months ago

Any updates yet?

Koenkk commented 9 months ago

AFAIK it is not possible to reduce the reporting interval of these TuYa devices, so not fixable from Z2M

kbickar commented 9 months ago

Is it possible to rate limit the messages sent over MQTT from the device?

Koenkk commented 9 months ago

Using the debounce option.

amateurishere commented 9 months ago

AFAIK it is not possible to reduce the reporting interval of these TuYa devices, so not fixable from Z2M

Thanks for the reply mate!

RuneNyhuus commented 9 months ago

debounce works great!

crowbarsolutions commented 4 months ago

What value are you setting debounce to that shows success? Even setting debounce to 1 with this device results in it stopping reporting.

Pontina commented 3 months ago

What value are you setting debounce to that shows success? Even setting debounce to 1 with this device results in it stopping reporting.

Any news on this? Can confirm that every debounce interval set instantly stops MQTT messages from the device.

crowbarsolutions commented 2 months ago

I ended up putting a smart outlet to power this sensor and setting up an automation in home assistant to turn it on for 5 seconds once an hour. It's primitive, but does the trick.

Just be aware to only use the latest value or max value when doing any reporting. Since in the case of my sensor it will start spitting out a default reading for a few seconds before starting to report the actual values in the air.

alias: Schedule - Throttle Carbon Dioxide Sensor
description: ""
trigger:
  - platform: time_pattern
    hours: /1
action:
  - service: switch.turn_on
    metadata: {}
    data: {}
    target:
      entity_id: switch.co2_sensor
  - delay:
      hours: 0
      minutes: 0
      seconds: 15
      milliseconds: 0
  - repeat:
      sequence:
        - delay:
            hours: 0
            minutes: 0
            seconds: 5
            milliseconds: 0
      until:
        - condition: template
          value_template: >-
            {{ states.sensor.carbon_dioxide_co2.last_changed >
            state_attr('automation.schedule_throttle_carbon_dioxide_sensor',
            'last_triggered') }}
  - service: switch.turn_off
    metadata: {}
    data: {}
    target:
      entity_id: switch.co2_sensor
mode: restart
ivanfmartinez commented 2 months ago

I ended up putting a smart outlet to power this sensor and setting up an automation in home assistant to turn it on for 5 seconds once an hour. It's primitive, but does the trick.

I made a small change in code to ignore reports from the "SPAMMER" devices. Not a clean job but easier to make

https://github.com/Koenkk/zigbee2mqtt/issues/17984#issuecomment-2267638647

Wheemer commented 2 months ago

I ended up putting a smart outlet to power this sensor and setting up an automation in home assistant to turn it on for 5 seconds once an hour. It's primitive, but does the trick.

I made a small change in code to ignore reports from the "SPAMMER" devices. Not a clean job but easier to make

#17984 (comment)

How can I implement this change?

ivanfmartinez commented 2 months ago

I ended up putting a smart outlet to power this sensor and setting up an automation in home assistant to turn it on for 5 seconds once an hour. It's primitive, but does the trick.

I made a small change in code to ignore reports from the "SPAMMER" devices. Not a clean job but easier to make #17984 (comment)

How can I implement this change?

I made the changes directly in the indicated file on my docker container. As there are a lot of cases like this and no recommended solution to be used. A better sollution will be to have it configurable like debouncer but I did not have time to check how to make all necessary changes in the UI.

ft276 commented 2 months ago

Is it possible to set up an automation that sets debounce to 0 for 2s every minute and the rest of the time sets it to whatever (even 0.01 doesn't allow any reporting with my TS0601)? I can't see how to set such advanced settings except through the settings page :(

TomNOYB commented 6 days ago

Is it possible to set up an automation that sets debounce to 0 for 2s every minute and the rest of the time sets it to whatever (even 0.01 doesn't allow any reporting with my TS0601)? I can't see how to set such advanced settings except through the settings page :(

I second this ^ My tuya TS0601 Model [ZN2S-RS3E-DH] https://www.zigbee2mqtt.io/devices/ZN2S-RS3E-DH.html#zemismart-zn2s-rs3e-dh) makes my network unusable when left chatting like crazy. Any debounce value solves the issue, but blocks all communication from the device.