Glad they picked it up then. 
Yaay for clarity.
In a small test setup, I have found the device to be a bit ‘sleepy’/slow to respond to on/off commands from the coordinator. I’m not sure if that reflects its low power vampire setup in a no neutral environment. It does work fine with a momentary wall switch, which IMHO is the only useful way to set up on of these type controls. It does take a couple tries to get the device to change the switch roll. I’m still not sure I understand all of the switch wiring diagrams shown on their web site. For safety, I assume there is mains voltage possible on all the connectors. But some of their other devices talk about 3.3 volts, no mention I can find of voltages on the ZbMINI-L anywhere.
It is not a Zigbee router and generally devices without neutral cannot be either.
On my blog I published a small review of this module, focusing on integration into the Philips HUE Bridge as well.
There’s also an illustrative YouTube video where you can see nicely the possible control delay from the HUE Dimmer Switch.
2 Likes
I flashed my ZBMINIs (normal 01MINIZB, not ZBMINI-L) with ptvo FW using cJTAG probe, but ran into very interesting problem on all 3 modules:
Has anyone else tried to flash and got the same or different results?
same here… the delay is terrible… fine in the first few hours and then gets worse and worse… after repairing its fine again for a few hours…
1 Like
I’m doing some simple comparisons between two ‘no neutral’ zigbee solutions:
SONOFF ZBMINI-L
–and–
MOES ZigBee Smart Touch Wall Light Switch ZTS-US
They are different in their approach in two main ways:
1 - Style and look
SONOFF uses the existing switch, no change to look if you do not change switch
MOES uses a modern glass touch UX replacing the existing switch.
2 - Switching device
SONOFF uses a mechanical relay, that brings along a fairly noticeable ‘click’
MOES uses some type of MOSFET or similar for switching, no noise.
So far, still needs some more time, however I am NOT seeing the remote switching delay on the MOES that is noticeable on the SONOFF.
The MOES switch is not too deep, so install in older boxes should be okay. I would cover the screw taps on the unit with electrical tape. A plus for the SONOFF device, they do a nice job with a cover for the screw taps.
If you are okay with the ‘high tech’ look of the MOES, so far, I am giving it the lead. However, I did pay 50% more for the MOES. USD 30 vs. USD 20 via Amazon for MOES. Perhaps a AliExpress purchase would reduce the difference.
I purchased the ‘3 gang’ MOES unit, just for kicks. I am pretty sure, the 1, 2, 3, and 4 gang all work the same. 4 gang most different button layout.
I was hoping that one of these devices offered a ‘disconnect’ between the switch and the relay. However, no luck on this with either SONOFF or MOES.
If the significant other could deal with it, the 2, 3 and 4 gang Moes devices do offer somewhat of an added control, in that I only have to hook up the 1st gang in the middle of the load wire to power the switch. But the remaining buttons ‘work’ in that they send state changes that you can use to create ‘virtual’ switches and control other things in Home Assistant. Note, the MOES, similar some other devices tends to ‘repeat’ messages a couple of times, sometimes. SO that will have to filtered.
I am doing my testing on zigbee2mqtt 1.23-dev with a SONOFF Zigbee 3.0 dongle with the Dec 2021 firmware.
I have been testing with two different loads, a 60 watt incandescent bulb and a 10.5 watt 800 lumen dimmable LED bulb. Swapping them to see if there is an effect on the switching, so far no changes on either switching devices behavior due to bulb.
2 Likes
There should not really be a noticeable delay even if the Sonoff ZBMINI-L with neutral is a sleepy device (similar to Sonoff SNZB-01 Zigbee Wireless Switch battery-powered “button” Zigbee end-device), the wake-up and response should still be relatively fast, so there might be an issue with its firmware and if so then should report that as a possible bug to ITead, otherwise keep troubleshooting your enviroment.
The point is that even battery-operated Zigbee buttons in deep sleep should wake up very fast and the response should really be within a second in a properly setup Zigbee network environment without issues. The video posted above shows there is a small delay with Philips Hue Bridge but no huge delay.
Great test setup as incandescent lightbulbs will usually have a faster response time than any LED lights.
already reported to itead because the delay in my setup is 30+ seconds. Unfortunately i have no sonoff bridge so i am not quite sure yet how to update the firmware, when that issue is fixed :-/
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:
https://github.com/home-assistant/home-assistant.io/pull/18864
Then later after getting check all that also read this too before unpairing and re-pairing trouble devices:
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:
https://www.digi.com/resources/documentation/Digidocs/90002002/Concepts/c_zb_source_routing.htm
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:
https://github.com/Koenkk/zigbee2mqtt/issues/10282
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?
| TI Z-Stack ID | Summary |
|---|---|
| ZIGBEE-1736 | Z-Stack Router based TL Devices contain memory leak |
Koenkk does post experimental firmware in his develop branch but latest is based on older 5.30.01.01
Koenkk also also adds a few custom patches to his Zigbee Router and Zigbee Coordinator releases:
https://github.com/Koenkk/Z-Stack-firmware/tree/develop/router/Z-Stack_3.x.0
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!
not so far, no. i wrote sonoff/itead but they just tried to get rid of any problem with a discount instead of talking about the problem…
If you guys are using Zigbee2MQTT then suggest submitting a new separate issue to Issues · Koenkk/zigbee2mqtt · GitHub about “Delays or slow response with SONOFF ZBMINI-L Zigbee 3.0 Smart Switch by ITead” for tracking as any issues posted there is more likely to get noticed by more users and then hopefully draw the attention of ITead employees (similar to how the issue in Sonoff S26R2ZB Smart Plug Zigbee Router devices by ITead disconnect from network after a day or two - Firmware bug or? · Issue #10282 · Koenkk/zigbee2mqtt · GitHub was verified as a real problem and a report eventually accepted by ITead/Sonoff).
1 Like
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.
2 Likes
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)
I switch all my setup from ZHA to Zigbee2Mqtt … Thinking it could be linked !
And it change nothing as you can see.
Great so that new Zigbee2MQTT issue #11676 issue should be used as a reference for Z2M tracking:
https://github.com/Koenkk/zigbee2mqtt/issues/11676
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.
If you are seeing the same types of delay symptoms in ZHA then it would be great if you could also create a similar issue report to Home Assistant core → GitHub - home-assistant/core: 🏡 Open source home automation that puts local control and privacy first.
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.