-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZY-M100-S_1 sensors report every second #19045
Comments
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. |
I have the same problem, and I suspect it's the reason for my Zigbee network performance issues. Ever since I added 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 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 |
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. |
I have the same problem, the sensor overloads the network and every 1 second it communicates this information. |
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. |
ok thank you very much for your information. |
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. |
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. |
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. |
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? |
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. |
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 #20261 |
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 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. |
It's a pity that this is so difficult. I wonder whether there is a way to get the configuration |
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. |
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! |
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. |
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. |
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. |
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. |
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? |
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. |
It's not a detection problem but it's actually the zigbee chip that transmits fast I bought 20 zy-m100-v1.4 to put on the same network with 40 other devices, the network collapsed almost immediately I thought of a drastic solution silent for 4 seconds 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 |
Put the spammy mmWave radars on a separate Zigbee network ... Just add a second Zigbee dongle. |
that's 20 spam radars talking over each other all the time |
@markhaines I have the exact same PIN lineup (so... that's pretty suspicious). I also adjusted the cables. And my presence sensor also blinks and communicates with Home Assistant as if it was "properly" powered up. It's simply not properly discovered by the OS, that's all. |
I managed to get it working on MacOS straight away in the end so assume it was just a windows / driver thing. |
For ref, based on detailed comment from @tandarra, my simplified steps for a ZY-M100-24G on windows:
|
I flashed 5 pcs TZE204_qasjif9e and the sensors work great! My network is finally working properly. Thank you❤️ |
thank you all! |
New problem here. I now discovered that my BHT-006 (Tuya/Moes) thermostats are also spamming the network like crazy. Any ideas on how to get new firmware for this? |
1 similar comment
New problem here. I now discovered that my BHT-006 (Tuya/Moes) thermostats are also spamming the network like crazy. Any ideas on how to get new firmware for this? |
I think you should open a new issue for that device. |
I just bought Wenzhi presence sensor (Zigbee 24G). In Z2M I've noticed "Found switch (distance switch)". When I turn it off I see less reports in logs. It means that I have already proper firmware and don't need to flash additionaly or should I because it's not enough to keep it stable? |
Please dump the firmware and share.
…On Wed, Dec 18, 2024 at 5:00 PM orzechszek ***@***.***> wrote:
I just bought Wenzhi presence sensor (Zigbee 24G). In Z2M I've noticed
"Found switch (distance switch)". When I turn it off I see less reports in
logs. It means that I have already proper firmware and don't need to flash
additionaly or should I because it's not enough to keep it stable?
Additionally what I've noticed is that - when sensor loose power "Found
switch" back to ON.
—
Reply to this email directly, view it on GitHub
<#19045 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ATUKSJ4M7ZDOHZNIBYMQIXD2GE2UPAVCNFSM6AAAAAA5CFPYD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJQG42DENJRGI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I've flashed _TZE204_ya4ft0w4 with mentioned procedure - should I additionaly disable with Find_switch? |
I'm trying to connect a ST-Link V2 to the ZY-M100-V1.4-24G wall mounted board (the box says it's a WZ-M100-W) and homeassistant reports this as TS0601 by _TZE204_ya4ft0w4 . However when the wires are connected the red LED lights up but then shuts off. When trying to run the firmware backup:
I get
|
Try to switch data cables on the board, power cables should be ok, I had similar problem and it helps. |
glad I found this thread. thank you all! got a few TZE204_qasjif9e and TZE204_sxm7l9xa flashed and quietened down |
Thank you so much this resolved my issue. When I flashed the "ZY-M100-24GV3_TZE204_ya4ft0w4_increased_report_interval_TD_0_disable.bin", HA now shows the device as TS0601by _TZE200_ya4ft0w4 instead of TS0601by _TZE204_ya4ft0w4 on a second unit. But I forgot to do the backup step on my second unit :( Hope I didn't brick it. |
I also tried flashing the other variants in https://github.com/Andrik45719/ZY-M100?tab=readme-ov-file and the device always show TZE200 instead of TZE204. So first attempt after flashing shows TS0601by _TZE200_ya4ft0w4 Subsequent attempts with other variants of ZY-M100-24G firmware makes HA display the devices as: |
Hello, I followed the instructions and I have the same issue: unable to connect to the target
I tried many approaches, like changing the cable, changing the sensor (I have many of them), etc., and nothing. How can I debug it to understand and fix the issue? |
How are you connecting the programmer to the sensor? Are you sure that there is good contact and all pins in the right order? I had that error when the contact with the board was not good (I did not solder it). |
I had the same issue a couple of times, for me it was just bad contacts on the pins. Used dupont cables and no soldering, so needed to hold them in place correctly.
Some flashing when plugging in the ST Link (so providing power to the board). It will also flash if you just power the board with 3.3 volts and have the data pins incorrectly placed. If I remember correctly it will not flash any more after plugging in the ST Link |
I had the same error. This error is caused when you have not connected the cables from the board to ST Link correctly. The square pad always goes to 3v3 on ST Link (you might have two so try either one) You can try switching SWDIO and SWCLK on ST Link. The best way is to post a picture of your ST Link. |
I finally found the problem. It was my ST-Link device. I bought a new one and it worked like a charm! Thanks! |
There is a new version out which has the Find switch/distance switch in Z2M. _TZE204_ya4ft0w4/ZY-M100-24GV3 Still spams the network. I have attached the original firmware. Hopefully @Andrik45719 or someone else can create a new firmware for this device. _TZE204_ya4ft0w4_ZY-M100-24GV3.zip If anyone else has problems connecting to their ST-Link, try switching the connection points for SWDIO and SWCLK from the guide. I don't think there is a set order the manufacturer of these devices follow for which pad is SWDIO and SWCLK. Ever board I have gotten seems to have a different order of pads for SWDIO and SWCLK. |
I’ve tested this custom firmware on my ZY-M100-24G too, but it still sends bursts of duplicate messages and delays illuminance, which is important to me. |
I have this version too and I'm struggling to tell whether setting the find switch to on or to off is supposed to reduce the spam if I'm honest - does anyone know? |
If anyone is interested, I've managed to flash WZ-M100-W with the modified firmware for ZY-M100-S_1 following the steps by @tandarra |
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:
![Screenshot_20230921_231622](https://private-user-images.githubusercontent.com/615816/269760719-61428dc1-59d0-4cdd-8b1a-91e50d19af7d.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzg5NDg5NTMsIm5iZiI6MTczODk0ODY1MywicGF0aCI6Ii82MTU4MTYvMjY5NzYwNzE5LTYxNDI4ZGMxLTU5ZDAtNGNkZC04YjFhLTkxZTUwZDE5YWY3ZC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUwMjA3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MDIwN1QxNzE3MzNaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jNGRlOThlMDJiZGYzOTQ0MzJiYmFiNjU4ZDNjYmJhYzkyYjliMDc3ZTM2ZWY3YTk3YzBkYWIzN2Y0OGE5NTUyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.pY7shnL2sQZ64rHZEb9v8G8-0_HAgWekoSNM6M9ro3E)
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
The text was updated successfully, but these errors were encountered: