Hi All,
today I’ve got my ZBMINIs, not the ‘-L’ version but the normal one. Interestingly the internal chip is a TI CC2652, and on the board it states ZBMINI V2.0 (manuf date: 2021.04.28). On the ITEad sites it states, that the ZBMINI can act as a router. Did anyone check this?
I do not own one mysef but if it requires a neutral wire to work then chances is it will be a Zigbee Router.
Wierd and bad marketing if they are not calling a “ZBMINI V2.0” product for “ZBMINIR2” or"ZBMINI2"?
ITead are usually good with adding an “R” and a number after the model to indicate revision changes.
I’m still wondering/investigating if it’s possible to create/upload a ptvo firmware using the serial interface (I don’t have a jtag at hand). I think I’ll give it a try within days - my goal is to have a sensor connected to s1/s2.
ITead use same CC2652P chip in ZBMINI-L, S26R2ZB, and Sonoff Zigbee 3.0 USB Dongle Plus now.
Note that Sonoff S26R2ZB which has same chip has reported work terrible as a Zigbee Router which is likley due to a firmware bug, read → https://github.com/Koenkk/zigbee2mqtt/discussions/10909
CC2652P1 / CC2652P1F → https://dev.ti.com/tirex/explore/node?node=AP7vVb5x.JDz3X9XOCv9Zw__coGQ502__LATEST
It should be however…
Note! CC2652/CC1352 uses cJTAG (IEEE 1149.7) interface with no SWD (Serial Wire Debug) access using TDI/TDO so only exposes TMS/TCK instead of SWD/SWDCLK thus needing (c)JTAG debug probe which supports cJTAG programming mode which can send required magic byte array.
Read:
https://electrolama.com/radio-docs/advanced/flash-jtag/
https://gist.github.com/hwhw/fc43892785aa84913d03495c97b0f25a
The cheapest option for an officially supported debugger is Texas Instruments CC-DEVPACK-DEBUG:
https://www.ti.com/tool/CC-DEVPACK-DEBUG
The official TMDSEMU110-U XDS110 JTAG Debug Probe is better option though as offer more options:
https://www.ti.com/tool/TMDSEMU110-U
Texas Instruments XDS110 JTAG debug probe is a bit expensive but cheap clones of it should work, ex:
https://aliexpress.com/item/4000751867419.html
Also, note that original Segger J-Link V9 (legacy) debug probes does not support cJTAG, so need at least a Segger J-Link V10:
https://wiki.segger.com/J-Link_Model_Overview
Similarly, if you messed up the bootloader firmware when flashing a CC2562/CC2352 based Zigbee Coordinator USB adapter like Sonoff Zigbee 3.0 USB Dongle Plus then the only way to unbrick the hardware is to flash with cJTAG via the TMS/TCK port:
Would be great if it could set TX power (transmission amplification) to whatever you want and support some standard external sensors that PTVO custom firmware support like temperature and humidity.
https://ptvo.info/zigbee-configurable-firmware-features/
For those who are still wondering if ZBMINI-L is a router, please read the info on the website more careful.
SONOFF ZBMINI-L Zigbee 3.0 Smart Switch - No Neutral Wire Required (itead.cc)
ITEAD clearly states it is an end-device.
That webpage did not state that before so they must have updated it after hearing about the confusion.
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.
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…
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.
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 https://github.com/Koenkk/zigbee2mqtt/issues/
@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
