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.
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.
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.
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.
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:
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!