ZY-M100-S_1 sensors report every second

[seblu]

What happened?

The Tuya ZY-M100-S_1 (_TZE204_sxm7l9xa) is reporting its values every second. This values can or can not changes.

Here is an example with values not changing:

What did you expect to happen?

A delay or minimal value change that can be configured in the Reporting tab.

How to reproduce it (minimal and precise)

Pair the sensor and it starts sending data every second or 2.

Zigbee2MQTT version

1.33.0

Adapter firmware version

20221226

Adapter

Silicon_Labs_Sonoff_Zigbee_3.0_USB_Dongle_Plus_0001

Debug log

debug 2023-09-21 23:20:33: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":6912}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:33: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:33.910Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:35: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7168}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:35: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:35.506Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:37: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7424}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:37: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:37.101Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:38: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7680}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:38: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:38.697Z","linkquality":102,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:40: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":7936}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:40: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:40.293Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:41: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8192}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:41: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:41.889Z","linkquality":109,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:43: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8448}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:43: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:43.684Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:45: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8704}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:45: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:45.081Z","linkquality":102,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:46: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":8960}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:46: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:46.674Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:48: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9216}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:48: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:48.272Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:49: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9472}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:49: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:49.866Z","linkquality":109,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:51: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9728}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:51: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:51.462Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:53: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":9984}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:53: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:53.058Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:54: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":10240}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:54: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:54.653Z","linkquality":105,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'
debug 2023-09-21 23:20:56: Received Zigbee message from 'Toilet Presence', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,0,0],"type":"Buffer"},"datatype":2,"dp":109}],"seq":10496}' from endpoint 1 with groupID 0
info  2023-09-21 23:20:56: MQTT publish: topic 'zigbee2mqtt/Toilet Presence', payload '{"detection_delay":0,"fading_time":5,"illuminance_lux":3,"last_seen":"2023-09-21T21:20:56.250Z","linkquality":109,"maximum_range":1.95,"minimum_range":0.75,"presence":false,"radar_sensitivity":0,"target_distance":0}'

[Koenkk]

This is a TuYa device, these doesn't support to configure reporting. AFAIK there is no way to reduce the reporting interval for these kind of TuYa devices.

[adiov]

I have the same problem, and I suspect it's the reason for my Zigbee network performance issues. Ever since I added ZY-M100-S_1 to the network, I've been noticing lags and slower response times.

I bought 3 identical TuYa mmWave radar human presence sensor from the same AliExpress listing, and when I paired them they were recognised by Zigbee2MQTT as 2 ZY-M100-L devices and 1 ZY-M100-S_1 device. The noisy, repeated messages are mostly coming from ZY-M100-S_1.

I suspect that the suppliers are mixing different hardware revisions in the same inventory. My solution is to buy a couple of these sensors from different AliExpress listing until I hit ZY-M100-L again, and replace the noisy ZY-M100-S_1 with it.

[bsaurusrex]

Having the same issues and it is crashing my network. About 50% of my ZY-M100-L are joining as S_1 devices and reporting every second.
Next steps: remove all the S_1 revisions and see if I can get stability with only the -L on the network. Alternative: I might try to convert them to ESPhome/wifi: https://blakadder.com/replace-tuya-esp12/

[Faraday76]

I have the same problem, the sensor overloads the network and every 1 second it communicates this information. I'm also looking for an "L" type version but how can I be sure before buying, there is generally not this information on the AliExpress seller's sheets. It's a shame because it seems to be very precise for me.

[adiov]

I spent a few weeks sifting through several of these sensors, and the "L" type seems to not exist anymore as I suspect it's now an older hardware revision. I gave up on it and replaced one of my offending sensors with the WiFi equivalent. Unfortunately, I have one outside the WiFi range that will have to keep being noisy on the Zigbee network until something new comes to market or there's a firmware update for it.

[Faraday76]

ok thank you very much for your information. I'm going to do like you, that is to say buy the wifi version. I think a lot of people will want to know why their network is unstable and slow because of this sensor.

[jpettitt]

I had 7 of these on my network and it was crashing (all devices unavailable, z2m UI non-responsive) regularly. I removed all but one and I'm back to stability.

[RikJ01]

Having the same issues and it is crashing my network. About 50% of my ZY-M100-L are joining as S_1 devices and reporting every second. Next steps: remove all the S_1 revisions and see if I can get stability with only the -L on the network. Alternative: I might try to convert them to ESPhome/wifi: https://blakadder.com/replace-tuya-esp12/

Any luck with converting to ESPhome? I can only find replacement guides on the WBR3 module (the WiFi version of this sensor) and not the ZT3L chip (Zigbee version).

[adiov]

Any luck with converting to ESPhome? I can only find replacement guides on the WBR3 module (the WiFi version of this sensor) and not the ZT3L chip (Zigbee version).

Follow the same procedure. All 3 comms modules (WBR3, ZT3L, and ESP-12) support UART for talking with the mmwave module, and all 3 have the same pin layout for the pins you care about (UART TX/RX, VCC, and so on). The result should be identical whether you start with the Zigbee version or the WiFi version.

Let us know how it goes for you.

[bsaurusrex]

Has anyone tried the new 24Ghz in ceiling zigbee models to see if they have the same problem?

[jpettitt]

Has anyone tried the new 24Ghz in ceiling zigbee models to see if they have the same problem?

Yes and yes. Same behavior in terms of once a second update, I won't install the ceiling sensor becasue the mains 110/220 connection is dangerous (connectors with no strain relief and inadequate separation, poor isolation of low and high voltage components). It's a fire waiting to happen.

I've just bough 2 athom esphome sensors to play with which are wifi, have both PIR and MM Wave and so far work great. They run on 5v usbc. and the connector is on the back so if you ceiling mount them it's invisible.

[JanHACS]

I have exactly the same problem here, my ZY-M100-S_1 is reporting every second, apart from that works perfectly, but obviously is not very good for the zigbee network.

I have seen that there is a possible update of this wall sensor called WZ-M10024, anybody tested?

[pmrosa]

Using the 24G (both ceiling and non-ceiling) that are identified as ZY-M100-24G (_TZE204_ijxvkhd0) on zigbee2mqtt and are spanning the zg network every second. Since i'm using a cheap CC2531 with >60 devices on the network, i was suspecting that the problems were arriving soon, thats why i was looking into the sky connect from home assistant. Should it be more stable? Any feedback?

[rhuss]

I'm using a WZ-M100-W (Wenzhi Human presence sensor) and have the very same issue as described in #20261 (and probably also in #17824 ). 'guess it's all the same firmware anyways.

[rhuss]

For the WZ-M100-W it's also spamming when there is no presence detected, every 0.5 seconds a MQTT message is created. See the log example in https://github.com/Koenkk/zigbee2mqtt/issues/20261

[adiov]

At the bottom of the ZT3L board, there's an SWS pad, allowing it to be flashed with custom firmware using the Single Wire interface. I got a suitable programmer from AliExpress, which was a little pricey for what it does.

After some intense desoldering and soldering, I successfully dumped the firmware out of the ZY-M100-L's ZT3L board and flashed it on the noisy ZY-M100-S_1 one. That didn't change the noisy behaviour, which tells me the bug isn't there.

I don't quite understand this sensor's architecture, but the only remaining place is the MCU on the 4th board, which is the one directly connected to the mmwave sensor. It's an ARM Cortex M23 chip. If somebody knows how to dump and flash its firmware, we can try to revert it back to the older firmware and see if that fixes the issue.

My worry is this approach is way too coarse, and it's possible the older firmware wouldn't work with the newer daughterboards in the newer version of the firmware.

[rhuss]

It's a pity that this is so difficult. I wonder whether there is a way to get the configuration detection_delay set to 10 (the documented maximum, default is 0.5 s) and be honored. I don't know how this configuration can be set so that it is taken over. According to https://www.zigbee2mqtt.io/devices/WZ-M100-W.html this should work e.g. with mosquitto_pub ... 'zigbee2mqtt/motion_human_presence_1/set' -m '{"detection_delay": 10.0}', but it doesn't. See https://github.com/Koenkk/zigbee2mqtt/issues/20261 for more info.

[esj006]

Hello everyone,

I wanted to provide an update on the ZY-M100-S_1 sensor's excessive reporting issue. After contacting Tuya, it's evident that the device's frequent reporting is governed by the MCU's firmware, developed using the Tuya MCU SDK. Tuya's module, part of this setup, does not fully support the standard Zigbee 3.0 protocol and is mainly for data transmission.

This clarifies that resolving the issue is beyond Tuya's direct scope, as they only supply the networking module, not the device firmware. Consequently, any changes to the reporting frequency would require modification at the firmware level, controlled by the developers who created it. Unfortunately, Tuya could not provide contact details for these developers, suggesting we reach out to the device suppliers or check for contact information on the product packaging.

For those interested in a deeper technical dive, Tuya referenced their Zigbee MCU SDK protocol, which might offer more insight into how their modules work: Tuya Zigbee MCU SDK Protocol.

[jvdburgt]

Thank you for these insights. I have spent the last two weeks trying to figure out what was wrong with the network in my new apartment, starting to setup home assistant from scratch multiple times. I have 9 of these sensors, and the network kept failing when more than 5 of these sensors were included.

I solved the issue for now by creating a second zigbee network (a Z2M besides the already existing ZHA network) and dumping all the sensors on there. It seems to work (for now). But a more direct solution to the problem (lower update frequency / less chatter) is of course preferable, and it seems this necessarily has to be done via the firmware route (switching to another sensors is not really a viable option for me, because I prepared all the in-ceiling sensors in my new apartment).

Is there any way for a custom firmware, or can it only come from the developers? I really hope there is a solution, because - besides the spamming by these sensors - they work great!

[rhuss]

Besides spamming the Zigbee network, directly forwarding all messages as MQTT messages also spams the computer network. One could reduce the frequency of issues MQTT messages, e.g., if there have been any changes? I think, this should be possible on the Zigbee2Mqtt handler level.

[adiov]

Besides spamming the Zigbee network, directly forwarding all messages as MQTT messages also spams the computer network.

I would probably not worry about the MQTT side of this issue. For MQTT server running on the same machine that runs Zigbee coordinator, it's all cheap operations in memory and occasional disk commits. It's peanuts in terms of the overall level of activity of your Home Assistant setup. For MQTT server running on another machine, the TCP protocol is more than capable of handling frequent transmissions at pretty much any data rate, and the same applies to the physical layers (Ethernet and WiFi). I don't think any component in your system or network even notices them.

I guess in theory I could see those additional MQTT messages being unnecessary spam, but architecting and writing code and tests to rate limit them is probably way too costly compared to the benefit.

The biggest issue is the spam on the Zigbee network. It's way more vulnerable to this problem. If you have 2-3 misbehaving devices like this, they can really clog up the Zigbee network, cause lags and delays. When I had 3 of those senors in my network, doing firmware OTA on any of my other Zigbee devices was basically out of the question.

[bsaurusrex]

Anyone able to find any guides on dumping the firmware and modifying it? I have a ton of these devices.

At the same time, I ordered a 24Ghz model (MTG235-ZB-RL) with the local switched relay. It is significantly higher quality and a lot safer. It has a power line tie down and plastic cover to protect the power wire screw terminals. Pending installation this week.

[jvdburgt]

Anyone able to find any guides on dumping the firmware and modifying it? I have a ton of these devices.

At the same time, I ordered a 24Ghz model (MTG235-ZB-RL) with the local switched relay. It is significantly higher quality and a lot safer. It has a power line tie down and plastic cover to protect the power wire screw terminals. Pending installation this week.

Curious if the TS0225 sensor your getting is any different (in terms of chattiness). Can’t find a lot of info on it, so look forward to your update on that.

[bsaurusrex]

Additionally, the 24Ghz model moved the re-pairing button to the front of the unit so that it is not required to pull the unit out of the ceiling and risk getting shocked.

As for testing, the original model is spamming every 1-2 seconds whereas this 24Ghz model is bursty at random. Sometimes no updates for up to 1 minute apart and other times it will send 3 messages a few seconds apart.

The is a difference in the size though. This model is 60mm wide instead of 55mm.

https://www.aliexpress.com/item/1005006102760484.html?spm=a2g0o.order_list.order_list_main.24.579d18021ch3hM

[jvdburgt]

And with “at random” you mean when there is no presence detected?

Overall, the way you describe it, it seems like less messages per minute though, correct?

[bsaurusrex]

Even when presence is detected, the messages from this new model are much less frequent.

I don't see any impact on accuracy. While it has only been installed for 12 hours, the presence history looks perfect.

[cangaroo82]

It's not a detection problem but it's actually the zigbee chip that transmits fast I tried deleting the sensors but nothing changed

I bought 20 zy-m100-v1.4 to put on the same network with 40 other devices, the network collapsed almost immediately Z2M restarts

I thought of a drastic solution if we added an external timer that reset the ZT3L chip

silent for 4 seconds it restarts and talks for 2seconds by trying empirically he makes a communication

https://www.google.com/aclk?sa=l&ai=DChcSEwiWweTBmviDAxV5kmgJHTrBAxEYABADGgJ3Zg&gclid=EAIaIQobChMIlsHkwZr4gwMVeZJoCR06wQMREAQYAiABEgLQBfD_BwE&sig=AOD64_3ig1-E7qMxFLqak9DkC-0Dllz6NA&adurl&ctype=5&ved=2ahUKEwjmzNPBmviDAxV8g_0HHf0CCAEQvhd6BAgBEFg&nis=8

https://futuranet.it/prodotto/micro-modulo-timer-programmabile-2-secondi-1000-ore/

Already ordered, I'll try as soon as they arrive

do you think damage could be caused with all these resets Any suggestions are welcome

[kkossev]

I bought 20 zy-m100-v1.4 to put on the same network with 40 other devices,

Put the spammy mmWave radars on a separate Zigbee network ... Just add a second Zigbee dongle.

[cangaroo82]

that's 20 spam radars talking over each other all the time

[kkossev]

You can experiment with purchasing one of the new Tuya Matter Bridges (get the cheapest one; all different 'brands' like Zemismart M1, Moes, etc, etc... have the same firmware inside, developed by the Tuya software engineering team) , and then expose the Occupancy state of the radars via Matter Bridge to HA.

This way, the spammed Zigbee network managed somehow by the Tuya hub will not interfere with the Z2M (make sure the Tuya hub is on another channel).

[esj006]

Following our discussions on the ZY-M100-S_1 sensor's high reporting frequency, I've come across an alternative sensor, the ZG-205Z, that seems to offer a more balanced reporting interval. Unlike the ZY-M100-S_1, which reports every second or two, the ZG-205Z reports approximately every 5 seconds. This could potentially reduce the network congestion issues we've been experiencing.

For those looking for a solution to the excessive reporting of the ZY-M100-S_1, the ZG-205Z might be worth exploring. I'm interested to hear if anyone else has tried this sensor or found other viable alternatives.

https://www.zigbee2mqtt.io/devices/ZG-205Z_A.html

https://www.aliexpress.com/item/1005005909805375.html?spm=a2g0o.order_detail.order_detail_item.3.1749f19c0fYTok

[jvdburgt]

Thanks for that, I checked the AliExpress link you provided, but can’t find information on the chipset (or did I miss it?). And also, is that chipset also included in the in-ceiling version?

[echupin]

Perhaps there is a solution. Set Debounce = 3 or 5 sec

[esj006]

@jvdburgt, I don't have specific information about the chipset used in the ZG-205Z sensor. However, I am currently testing two of these units, and they are performing well. They report approximately every 5 seconds, which aligns with the expected behavior and is certainly an improvement in terms of network congestion compared to sensors that report more frequently.

@echupin, it's important to understand that setting a "debounce" value in Zigbee2MQTT can help reduce the amount of data being published to the MQTT server, but it doesn't actually reduce the frequency at which Zigbee devices send their messages. The debounce setting only controls how often these messages are forwarded from Zigbee2MQTT to MQTT.

In your situation, where you're dealing with sensors like the ZY-M100-S_1 that report very frequently, setting a debounce time can help lessen the load on the MQTT server by reducing the number of messages it processes. However, this will not reduce the workload on the Zigbee controller itself, as it will continue to receive messages from the Zigbee devices at the same high frequency.

Switching to a sensor like the ZG-205Z, which naturally reports less frequently (approximately every 5 seconds, as you mentioned), can indeed help alleviate network congestion. This is because the Zigbee controller will receive fewer messages from these devices, thereby reducing the overall network traffic.

In summary, while debounce settings can help manage MQTT traffic, they don't address the root cause of network congestion in a busy Zigbee network. Using devices with lower reporting frequencies, like the ZG-205Z, is a more effective way to reduce network load.

[djcrawleravp]

What about Qos? HAving the same problem it's driving me nuts:

I have 6 ZY-M100_S1 and they take turns to disconnect, one day it's the one from the bedroom the other day the one from the living room and some weeks they work perfectly

But now that I have activated "Last seen" look at this packet madness!

[echupin]

@esj006, it's clear. How about installing a second zigbee coordinator?

[bsaurusrex]

@esj006, it's clear. How about installing a second zigbee coordinator?

That can certainly work as it will spread the rf utilization across more channels. There's still a risk of the rf being overloaded and causing slowness or missed messages.

I tried running two coordinators with z2m in parallel with z2m-edge but had oddities with device id in HA so I gave up and just moved to the 24ghz version of these sensors... higher quality, more accurate, more stable.

[djcrawleravp]

@esj006, it's clear. How about installing a second zigbee coordinator?

That can certainly work as it will spread the rf utilization across more channels. There's still a risk of the rf being overloaded and causing slowness or missed messages.

I tried running two coordinators with z2m in parallel with z2m-edge but had oddities with device id in HA so I gave up and just moved to the 24ghz version of these sensors... higher quality, more accurate, more stable.

Any link recomendation? Dont want to make the same mistake again

[djcrawleravp]

It's not a detection problem but it's actually the zigbee chip that transmits fast I tried deleting the sensors but nothing changed

I bought 20 zy-m100-v1.4 to put on the same network with 40 other devices, the network collapsed almost immediately Z2M restarts

I thought of a drastic solution if we added an external timer that reset the ZT3L chip

silent for 4 seconds it restarts and talks for 2seconds by trying empirically he makes a communication

https://www.google.com/aclk?sa=l&ai=DChcSEwiWweTBmviDAxV5kmgJHTrBAxEYABADGgJ3Zg&gclid=EAIaIQobChMIlsHkwZr4gwMVeZJoCR06wQMREAQYAiABEgLQBfD_BwE&sig=AOD64_3ig1-E7qMxFLqak9DkC-0Dllz6NA&adurl&ctype=5&ved=2ahUKEwjmzNPBmviDAxV8g_0HHf0CCAEQvhd6BAgBEFg&nis=8

https://futuranet.it/prodotto/micro-modulo-timer-programmabile-2-secondi-1000-ore/

Already ordered, I'll try as soon as they arrive

do you think damage could be caused with all these resets Any suggestions are welcome

Looking forward to see how it goes!!

BTW, Can you provide the links again? I think they're both broken

Thanks in advance!

[djcrawleravp]

I got my 7 ZY-M100_S1 sensors working again! no issues so far,

It's true they're spamming the network but rolling back to firmware 20221226 on my SLZB-06 solved the issue, even overall LQI improved by a lot.

Nevertheless I'll change all my sensors to less spammy ones ASAP (Suggestions much appreciated)

Hope this helps

[kenni]

Follow the same procedure. All 3 comms modules (WBR3, ZT3L, and ESP-12) support UART for talking with the mmwave module, and all 3 have the same pin layout for the pins you care about (UART TX/RX, VCC, and so on). The result should be identical whether you start with the Zigbee version or the WiFi version.

Let us know how it goes for you.

@adiov @RikJ01 However, that would still require ESPHome to support the fairly unknown(?) chinese X-RA2413MT mmWave sensor module (https://vi.aliexpress.com/item/1005005262959472.html), which it doesn't natively as far as I can tell. However, I found this third party project which actually seems to implement it in Esphome, so if the code works, it might be a viable solution: https://github.com/liwei19920307/ESPMMW/

[orzechszek]

Hello,

Any news regarding mentioned issue? Any known firmware updates for ZY-M100-S_1 to reduce reporting?

[jvdburgt]

Very curious about that as well, cause I’d really like to solve this problem properly. But honestly, since I dumped all (10!) sensors on their dedicated MQTT network I had 0 issues ☺️

[djcrawleravp]

Just got in my hand these ones for replacement.

Even they're working very well, the ZY-M100-S_1 are going to a drawer until further workaround is found.

[victordqa]

I solved the issue for now by creating a second zigbee network (a Z2M besides the already existing ZHA network) and dumping all the sensors on there. It seems to work (for now). But a more direct solution to the problem (lower update frequency / less chatter) is of course preferable, and it seems this necessarily has to be done via the firmware route (switching to another sensors is not really a viable option for me, because I prepared all the in-ceiling sensors in my new apartment).

Hello all, @jvdburgt Thanks for the ideia! Could you please provide more details on this solution? Do you still use only one zigbee dongle? Do you add both Z2M and ZHA integrations and only pair the presence detection devices to one of them?

[orzechszek]

Buying additional dongle and creating new network is rather not a solution for me :( . It should be fixed on firmware level. A question is to sell and buy suggested replacement or wait... but how long :)

[jvdburgt]

I agree with the sentiment @orzechszek , but wanted a workable solution for now.

@victordqa : pretty straightforward, bought a second SkyConnect stick and configured it for Z2M. Put all the chatty sensors on the new network, and kept all my other devices on my old ZHA network. Result: the peace is restored on ZHA where it again is nice and silent, and the sensors are free to shout at eachother over Z2M without disturbing their peace-loving neighbours ☺️

HA manages both networks and just passes on the relevant information, everybody’s happy … at least funtionally. Me, I’m still somewhat annoyed that I had to bend over backwards to facilitate these buggy sensors but at least it works now

[vitkolar]

besides the spammy behavior, are you happy with the performance? I have bad occupancy readings (on similar Tuya sensors), they are quite random: is it working for you?

I'm using the plugin file (or how is it called). Tuya_presence__TZE204_mtoaryre.txt

[jvdburgt]

I’m quite happy with them. They’re not perfect, but I’d say 98-99% perfect with the very rare false positive or false negative.

it is important though that you have them on ZHA with the right quirk or on Z2M, as this allows you to finetune their settings (max distance, sensitivity, etc). Also it takes a bit of tweaking with regard to fade time (both device setting and home assistant automation) to make it work as desired. For instance in the bedroom I have a quite long fade time of about 30 secs, in the living room about 20 secs, while in hallway, bathroom and home office about 10 secs. Rule-of-thumb here is the more physically active you are in a certain room, the shorter the fade time can be).

[mattc157]

I really like the performance these sensors give. I have tried most of the hilink and dfrobot sensor but I keep coming back to this one sen0521 (ZY-M100) it has the right balence of sensitivity and works best through my ceiling material for the way I like to use mmwave. One thing to note is the fov of the sensors, I notice other sensor may be better at detection and clearing but the fov is poor when mounted in a ceiling position, mostly only work well at about 2-3m where the tuya sensor works well up to about 4m. I was using the zigbee sensors but like so many I purchased a few and after pairing more than 5 my network started crashing, I split my network into 2 and that mostly helped but not 100% solved, I would still wake up to no devices responding. tried multiple sticks but no luck. removing all the mmwave sensors and the zigbee network is rock solid again. so I wnt down the rabit hole of esphome but still wanted these sensors. I found you can cut the mmwave sensor of the tuya board and solder it to an esp32 and for the most part you can use the esphome yaml from the dfrobot sen0395 that so many love. I have made a working config if anyone wants it. I have been mounting these sensors in 3d printed cases abouve my ceiling material in each room completly invisable and powering them over poe cat6 I ran in the roof space. I also connect a pir sensor mounted in the ceiling near the door that triggers just as you enter the room. this is because the pir is instant and reliable for detection. I dont use the mmwave for detection, I use PIR lights on and PIR + mmWave cleared for lights off. this gives me the best of both worlds and makes up a complete fast and 99% accurate presence system in each room. Pics attached.