Very well documented review, I still have mine in the drawer though. I got it during the first batch and took just 4days to arrive in the uk after dispatch.
I have mine installed for 2 weeks. Has been rock solid with no issues at this stage.
I have recorded the lqi of two devices separately with the Sonoff dongle:
Then I have removed the Sonoff Dongle and replaced it with the old fashioned CC2531… I could not pair the devices at 15 meter distance…
I rest my case
@Doublet , Do you recommend the sonoff 3.0 dongle plus? I am currently using CC2531 but I am having occasional device dropping . I have the sonoff dongle but want to know if it is reliable before I start the tedious pairing.
I had similar issues with the CC2531, especially if you are expanding your network with more than 20 Zigbee devices. The chipset in the Sonoff is lot more powerfull.
I’m still confused by the specification of this device. It states its pre flashed with Z-Stack_3.0.x and supports 20 direct devices up to a maximum of 40 per mesh? However Z2M shows this firmware as Z-Stack_3.x.0 which should support 100-200 devices. Itead/sonoff have failed to answer this question.
states its preflashed with 3.x.0 according to website
and an old post from october on the web mentions it always was using 3.x.0
I would still love a comparative test between a popular alternative.
Considering going from Conbee II to this, but only if it would decrease LQI values.
It uses 3.x.0. I’m using the updated firmware CC1352P2_CC2652P_launchpad_coordinator_20210708.zip
Works well. There’s an update sitting in the develop branch that adds support for those new aqara sensors but I didn’t have much luck getting it to work.
I believe even though the dongle is advertised at +20dBm, it is still operating at +5dBm since the firmware needs to support running at that value. So not sure if the LQI comparisons would be accurate without having +20dBm
Uh I didn’t know there were new sensors coming. That is good info.
While the old ones are rock solid, I wonder what the new iterations bring to the table besides the battery life (which is a big plus!)
I guess not so much new but the version is different from MCCGQ12LM to MCCGQ14LM for the door sensors for example. And they’re different enough that it warrants some change firmware wise.
The reason is ITead missed they need to write “description” to EEPROM on USB-to-UART chip, see:
Great if more people report this issue to ITead as they need to make and release a script that writes a “description” to the CP2102N EEPROM so will no longer discovered using Silabs default description.
Hopefully, they will at least fix this in the next batch (or the next batch after that) so discovery will work.
You do not need to repair any devices if you backup your CC253x to an image file and restore that image file to a new CC2652 based adapter, (with that backup and restore method you can even migrate from Silicon Labs based adapters and vice versa). The migration procedure is shortly described here:
You do however usually have to power-cycle some or all of your devices that do still not connect even after you left it alone for a while, (then easiest for mains-powered Zigbee devices is probably to start by just temporary pull the main circuit-breaker for the house/apartment in order to power-cycle them all).
Specifications on ITead’s website is wrong, so see correct specs for Z-Stack_3.x.0 on CC2652P here:
https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md
CC2652 can have 50 direct children = 50 direct attached devices, and each of those 50 directly attached devices can route another 50 devices, but in the end, 200 is the maximum of Zigbee 3.0 devices.
So in theory, it should be able to control 200 new Zigbee 3.0 devices + 1000 older Zigbee Home Automation 1.2 devices at the same as Zigbee Home Automation 1.2 devices have almost no overhead.
The 200 limit for Zigbee 3.0 devices is because security for Zigbee 3.0 devices have a lot of overhead.
Poor advertisement as yes the CC2652P hardware does support 20 dBm transmit power, however the current firmware is configured to use 5 dBm transmit power (same at the hardware limit for CC2652R).
It now sounds as ITead will work with the community to make a firmware for it that does 9 dBM because that will result in a dongle that achieves less than 10 dBm in ETSI spectral density test and that is a requirement for commercial certification.
https://github.com/Koenkk/zigbee2mqtt/discussions/9744
Meaning even if the hardware can do 20 dBm to transmit power, ITead can not legally sell and ship it with firmware a higher transmit power configuration if they want it to get commercially certified.
There is however nothing that is stopping you from building and compiling your own firmware configured to use 20 dBm to transmit power and then flash that, though it would be illegal to use in most countries.
2 Likes
Thanks for the info. I ended up switching to the Edge release of Zigbee2MQTT and was able to get the develop firmware of Z-Stack 3.x.0 working. Still doesn’t make sense to me but I bet if I switch back to ZHA, it will probably also work. Might have just needed a good reboot/replug dongle/power on/off devices. But thanks!
By the way, also vote + comment in this request for backup features in ZHA’s UI and nightly backups:
Having such automatic backup features in ZHA’s GUI would also enable users to do migrations easily.
1 Like
I had my Dongle Plus working well for a month. Then some time during the night it quit working, and HA would fail to set up ZHA on reboot. after many different attempts, I gave up, uninstalled ZHA and tried to reinstall it with the Dongle Plus. HA saw it on the USB, but could not set up. I think the dongle is dead.
Did you make a backup? If so then could restore to a new/spare hardware hardware as backup plan:
With the cost of Sonoff Zigbee 3.0 USB Dongle Plus being so relativly low priced and it as a Zigbee coordinator being so relativly essential in a Zigbee network it is a good idea to have spare hardware.
FYI, JelmerT made a “sonoff” patch for cc2538-bsl flashing tool that I confirmed working on Windows:
https://github.com/JelmerT/cc2538-bsl/pull/114
Hopefully, that will get merged as then users only need to use --bootloader-sonoff-usb parameter.
If you test it under other operatingsystem or other condications then report any issues to the PR there.
You can get it to test yourself from here:
https://github.com/JelmerT/cc2538-bsl/tree/feature/ITead_Sonoff_Zigbee-delay
Example:
cc2538-bsl.py -p COM5 -evw --bootloader-sonoff-usb CC1352P2_CC2652P_launchpad_coordinator_20210708.hex
Yeah, I had it backed up when I transferred everything over from my HUSBZB-1. I kept that as a backup coordinator just for such emergencies. However, lasting only a month is discouraging. Maybe I just happened to get a rare bad one.
1 Like