30+ seconds sound way too long for you to not have other issues in your Zigbee network/environment.
Clearly, not everyone using it have a 30 second delay or more so must be something in your setup.
Before doing anything begin by upgrading the firmware and put your Zigbee Coordinator dongle on a long USB extension cable and use a USB 2.0 port (or USB 2.0 hub) as well as upgrading its firmware.
Your RF environment is likely too noisy so should also take actions to avoid interference sources, see:
PS: If you have done all that, including updating Zigbee Coordinator firmware and adding more known good permanently powered Zigbee Router devices, and yet still have such long delays then consider trying to enable “source routing” in your Zigbee network to see if that makes a difference or not. Read:
its not always a 30 second delay! it adds up to that until it doesnt respond to zigbee commands anymore (but still visible, when i use the real rocking switch the state changes immediately, which also is an indicator that the network is fine)
what makes me wonder is that the device works like a charm after paring it and then gets worse and worse… you could say every hour adds a second to the delay… it’s also the only device which has a noticeable delay in my whole network. it isnt that far from the coordinator (3m max) so it should have actually the best environment in the whole house. after repairing it, it works again as it should for the first few hours…
i will see if there are new updates for my conbee, but the fact that it works perfect for a amount of time still makes me wonder… also the fact that every other device in my house works as it should keeps me thinking that the issue is not in my network
Ah, ok, yeah that description does make it sound more like a memory leak bug in íts Z-Stack firmware.
While not directly related, FYI, Zigbee2MQTT users discovered that the CC2652P based Sonoff S26R2ZB does contain a memory leak bug in the firmware which makes it go offline after a while, see:
The workaround there has been to manually flash the CC2652P chip insider Sonoff S26R2ZB with the latest Zigbee Router firmware from https://github.com/Koenkk/Z-Stack-firmware/tree/master/router/Z-Stack_3.x.0/bin but they have already reported the issue to ITead who replied that they will release a new firmware via OTA (but as you mention that will only be updated if you use ITead Sonoff ZBBridge).
Maybe if you could also test and replicate the problem with Zigbee2MQTT then their community might be able to troubleshooting this further under Issues · Koenkk/zigbee2mqtt · GitHub
@davidaichi FYI, the upstream Texas Instruments SimpleLink SDK 5.40.00.40 does contain at least one memory leak fix related to Z-Stack Router based TL Devices so maybe ask ITead/Sonoff about it?
Hi @davidaichi did you ever find any updated firmware for the Sonoff ZBMINI-L? I tried the device on a Sonoff Zigbee hub with their control app on iOS (which sux IMHO) and found nothing that looked like you could even find the current version of firmware on the device or do any upgrade. Thx!
I was following this thread. I ordered 12 of these switch and I’m facing the same delays
I Integrated only 4 of them right now … Since with this issue the automation I was planning to make has nearly no sense .
I created the Issue on the Zigbee2mqtt Github as you suggest.
I also tried to contact ITead without success.
i am using zha btw. but i am glad you also wrote them. their reaction to my mail was “we never heard that from any other customer. must be your fault because you arent using our bridge” (in short)
Good idea if everyone that has experienced delay problems with SONOFF ZBMINI-L post there in Zigbee2MQTT issue #11676 explaining their setup, including Zigbee2MQTT version, exact Zigbee Coordinator model and firmware version, and whether or not the device is connected directly to the Zigbee Coordinator and though a Zigbee Router as well as which Zigbee Router model and firmware if it goes through one.
Probably also a good idea if everyone reporting these problem systems to ITead/Sonoff also refer to that Zigbee2MQTT issue #11676 ir here to this thread if using ZHA.
Again, such issue reports in issues trackers are better for tracking specific problems and links can be given to ITead support for reference so that they too can track only that specific issue one a platform.
You jusut can not expect ITead support to track or even read about issues on a forum thread because that one thread could contain man different problems with multiple platforms and different setups and envioments.
With issue trackers you can at least referece to a specific problem on a specific platform, and still with the issue tracker being for a third-party application we have to be paitient and hope that ITead will take note that the problem is real once enough people have reported the problem and reference same issue.
PS: Fact remains that with ITead Sonoff products you are really only paying for the hardware and not for their great first-line support. ITead have stated several times that they rely on communities for support.
The tip is that might be a good idea to try PTVO firmware but select the CC2652R chip type (and not CC2652P) in the PTVO firmware configurator to get firmware omage without power amplifier enabled.
Manually configuring the transmit power to 5 dBm or less in the firmware should probably also work?
So as a workaround to use PTVO firmware it is probably very likely that selecting CC2652R chip type in the PTVO firmware configurator will result in a working firmware image on the ITead Sonoff ZBMINI-L similar to the new Sonoff ZBMINI (01MINIZB) as both use CC2652P (CC2652 P1F) chip model and their radio modules have same design flaws/limitations/optimizations?
PS: Again, to manually flash a new firmware image to CC2652 based devices like these you need cJTAG (c/JTAG) compatible adapter like TI CC-DEVPACK-DEBUG adapter or Texas Instruments XDS110. See → https://electrolama.com/radio-docs/advanced/flash-jtag/
I’ve just got one of these and installed it on my bathroom lights. I only use the attached switch to turn it on/off (no automations sets up etc.) but twice now I’ve had the lights randomly turn themselves off after I’ve turned them on ( between 2-15mins after they’ve been switched on)
I’m also experiencing this problem. You refer to /core and to report it there. I assume someone already created an issue for it that we can use but i cannot seem to find it. I’ll be happy to create it if it doesn’t exist but don’t want to create duplicates.
Anyways, besides the delay problem, after a certain amount of time (couple of weeks) the switch becomes unresponsive. Even when operating it manually. After unplugging the lightbulb and plugging it back in, the switch comes back to life. Is there anyone else with similar experiences?
Also, my SNZB becomes unavailable since a couple of days after a month of working without any isues. Taking out the battery and putting it back in solves it for a couple of hours, then becomes unavailable again.
I have several other Zigbee devices which work flawless and i therefore assume my Zigbee network is fine.
ZBMINI-L @230V / SNZB (03) / ZHA / SONOFF ZigBee 3.0 USB Dongle Plus (Z-Stack 3.30+ (build 20211217))
Based on history they had a tendency to not react to reports of clear firmware bugs until enough people have reported the same problem, even if some in community show how to replicate issue to prove fault.
I installed one for my living room lights - I’m experiencing the lights sometimes turning on and off a load of times… no automations in place yet (confirmed via logbooks as well etc).
I might return and go for the ZBMINI now that I’ve figured out how to grab a neutral at the fielding rose (and also discovered ikeas amazing huge light fittings!!)
FYI, zigbee-herdsman developer Koenkk has implemented a Zigbee converter workaround for sonoff devices (like ITead’s Zigbee End-Device such as Sonoff ZBMINI-L) in zigbee-herdsman-converters that should at least solve the slow polling issue which causes delay issues in Zigbee2MQTT (and IoBroker).
Looks like workaround chosen now is to unbind genPollCtrl to prevent the device from sending checkin message which causes Sonoff Zigbee End-Devices poll slower about 1-hour after powering the device.
The fix is available in the very latest dev branch of Zigbee2MQTT and does require you to repair the Sonoff ZBMINI-L device (after updating to latest Zigbee2MQTT dev, a.k.a. Zigbee “edge” version).
If can work around this slow delay problem in a Zigbee converter for zigbee-herdsman-converters then maybe it is also possible to do the same in a “quirk” for ZHA Device Handler for the ZHA integration?
