"Sonoff Zigbee 3.0 USB Dongle Plus" by ITead is based on Texas Instruments CC2652P can be pre-ordered for $10.99

FYI, ITead has about a week ago announced on Facebook that their CC2652P based “Sonoff Zigbee 3.0 USB Dongle Plus” will be released soon and it sounds like a premium product at a low-cost price.



Update! Initial batch(es) have already sold out, however, pre-ordering is available at Itead official store.

Note! It’s strongly recommended to use with long USB extension cable to avoid EMF interference!



Texas Instruments CC2652P is together with the competing Silicon Labs EFRMG21 chips at this time the most capable and most powerful multi-protocol MCU with 2.4 GHz radios on the market. CC2652P radio chip is currently also the most popular as a Zigbee Coordinator and Zigbee Router in the DIY Zigbee userbase community because it is newer so the firmware is well maintained and is stable/mature in both Zigbee2MQTT and the built-in ZHA integration for Home Assistant. Just like Silabs EFRMG21, TI’s CC2652P feature an integrated Power Amplifier that is technically capable of +20 dBM amplification (though legally the firmware is probably not allowed to be configured to use more than +10 dBM amplification).

According to their marketing material, it will come pre-flashed with Texas Instruments Z-Stack 3.x.0 coordinator firmware and it should work out-of-the-box with either Zigbee2MQTT (which uses zigbee-herdsman so will probably work with IoBroker too) and Home Assistant ZHA integration (which uses zigpy so will probably work with Jeedom too), but is will however not yet work with OpenHAB’s Zigbee-Binding since the zstack driver for zsmartsystems’s com.zsmartsystems.zigbee library which it relies on does not yet support the new/updated TI Z-Stack 3 (Z-Stack 3.0.x and Z-Stack 3.x.x) serial API commands:


Interested developers should note cdjackson did start work on initial Z-Stack 3 driver 2-years ago here:


In addition, ITead specifically mentions that this TI dongle can alternatively function as a Zigbee router (presumably by flashing Zigbee router firmware instead and open access buttons as pressing a button to enable pairing/joining mode is usually required).

I also read that this time they have also added proper electromagnetic shielding to the radio chip and antenna parts onboard the board itself, meaning they must have learned from some of their design flaws in regards to electromagnetic interference and radio signal reception.



It is based on Texas Instruments CC2652P (CC2652 with integrated +20 dBm amplifier) Zigbee radio and features a metal casing + an SMA connector with an external antenna. It looks a little on the large side for USB 2.0 Type-A but still recommend using a USB extension cable.

Interestingly it uses a Silabs CP2102N UART-to-USB chip so wonder if it will have unique ITead VID and/or PID strings specific for this adapter so could be added via automatic USB discovery, like in HA:

PS: I understand ITead went with CC2652P instead of Silicon Labs EFR32MG21 for this “Plus” dongle version because of the current silicon chip shortage (which Silabs parts suffered for more than most).

Hopefully, we will also see ITead release a new fixed revision of their cheaper Zigbee 3.0 USB dongle with proper RF shielding and either corrected PCB antenna design or better yet a ceramic chip antenna.


As we know, ITead’s previous ‘non-Plus Zigbee 3.0 USB dongle’ is/was based on Silabs EFR32MG21 SoC which has just as powerful MCU and radio, but sadly was proven that implementation in ITead’s first Zigbee 3.0 USB Dongle PCB board revision had a badly designed integrated PCB antenna with poor tuning and no electromagnetic shielding which caused huge issues in radio reception, and to this date, it has been listed as “out-of-stock” since after the initial batch was sold out. Again, very sad since that could also have been a great Zigbee Coordinator adapter if it had been properly engineered. Hopefully, they will decide to take another stab and redesign that as a new product after the chip shortages as it would be great if they could also offer a Silabs EFR32 based alternative for extended compatibility.

1 Like

Wondering if this CC2652P serial port will have pins connected for RTS / CTS Hardware Flow Control?

Update: ITead now posted some documentation which states that this hardware donle does support “Hardware Flow Control” but default firmware that it ships with does not so community need to build it:


The dongle is pre-flashed with the official Zigbee 3.0 coordinator firmware, which does not support software flow control. The dongle supports hardware flow control, if you want to enable it, please set the dip switch to on, and generate the firmware that supports hardware flow control before running, see the following document for details on how to generate the corresponding firmware.


Enable hardware flow control and generate firmware (optional) If you need to enable the hardware flow control of the CC2652P USB Dongle, you need to use CCS to import the ZNP project to configure and compile the firmware that supports the hardware flow control.

Initial batch already sold out, however pre-orders for next batch is now available at Itead’s official store.

Koenkk from Zigbee2MQTT got info from ITead/Sonoff that this dongle comes pre-flasded with older “CC1352P2_CC2652P_launchpad_coordinator_20210120” firmware from https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin but specifications around 50 direct children, 100/200 routes, and a maximum of 200 Zigbee 3.0 devices that is listed here should still apply → https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md

FYI, Mat from NotEnoughTech has posted both written and video reviews about this new USB dongle.

Note! Before reading/watching that review, know it is now believed that Mat flashed the wrong firmware image when updating it and that was the reason he was having problems after upgrading the firmware:






At least no one else appear to be having issues pairing devices like Mat from NotEnoughTech is having.

Mat also tested the range and noted that range performance does not seem to be better than Electrorama’s zzh dongle which is based on CC2652R that is physically only capable of +20 dBm output which is curious since transmission range should be better with CC2652P +20 dbm output.

FYI, Koenkk from the Zigbee2MQTT project most have tested as he now added it to their supported list:


He also added it to his repository of precompiled Z-Stack 3.x.0 Zigbee coordinator firmware images:


It has been confirmed to also works as a Zigbee router if flash it with this Z-Stack 3.x.0 router firmware:


how can we use this device with OH3?

You can currently use Z-Stack 3.x based adapters via Zigbee2MQTT with MQTT in openHAB, see:


In practical terms today check out → “openHAB and zigbee2mqtt Tutorial for Beginners

In the future, can hopefully use these newer adapters directly via openHAB binding for ZigBee, but…

…while openHAB binding for ZigBee (openHAB’s native Zigbee) does support the older Z-Stack Home 1.2 API, it does not yet support the newer Z-Stack 3.x API. Meaning that openHAB binding for ZigBee does support Texas Instruments (TI) adapters based on the old CC253x chips (CC2530/CC2531) with ZNP 1.2 firmware, but it does not support new TI adapters based on the newer CC2652 or CC1352 chips with ZNP 3.x firmware. Note! Other communities like that of Zigbee2MQTT recommend not using CC253x based adapters since the chip is obsolete with does not work well when having more than 20 devices in the network and does no longer get Zigbee stack or firmware updates.

There’s is an issue raised for openHAB binding for ZigBee supporting CC2652 with Z-Stack 3 here:


That in turn refers to an issue in com.zsmartsystems.zigbee lib which openHAB’s ZigBee depends on:


So until the com.zsmartsystems.zigbee library get extended support for Texas Instruments updated Z-Stack 3 API (a.k.a. ZNP 3) you can not natively use any CC2652/CC1352 based adapters in openHAB.

PS: This means that want to use a modern Zigbee adapter with openHAB binding for ZigBee today then you need to stick with Silicon Labs (a.k.a. Silabs) adapters based on EFR32MG21 or EFR32MG12 (like ex. ITead Zigbee 3.0 Dongle, Elelabs Zigbee USB Adapter or POPP ZB-STICK but that is off-topic).

1 Like

Thanks for the info.
The price, including shipping, is pretty reasonable. I wish the CC2652 was available earlier. I started my Zigbee network around 3 years ago with the CC2531. And it was a lot of hair pulling due to the range limitation. I ended up adding 2 more routers and things are stable then. At the time, the CC2531 was the recommendation. The list of supported adapters are so much richer now. But the supply chain issue is probably causing a lot of delay.

If you are using Zigbee2MQTT then it is today easy to upgrade from any older CC2530 or CC2531 hardware to any newer CC2652 hardware (though recommend doing backup so can restore). See:


You do not even need to repair your devices:


As for Zigbee coordinator and network range limitation, these are general tips that I have connected:

Tips on improving Zigbee network range

Both poor signal quality or signal interference can lead to transmission errors and related issues. This section contains fundamental troubleshooting tips on how to improve signal quality plus optimize range and coverage. Improving signal quality and removing sources of signal interference can in most cases maximize range and resolves problems related to transmission errors. Please try to follow at least some of these recommendations before posting on the community forums or reporting issues to developers.

  1. Adding more Zigbee routers between devices far away and the next closest router or your Zigbee coordinator. Zigbee network topology uses a “mesh network” design which means that each device that acts as a Zigbee router will extend the total range and coverage of your Zigbee network as a whole. The solution is to distribute more Zigbee routers in areas with poor reception. Note that while there are exceptions, understand that almost all permanently powered devices will serve as a Zigbee router. Thus adding more permanently powered Zigbee devices will allow greater range better coverage. There are also dedicated Zigbee routers which you can find by doing a community search for “Zigbee signal repeater” or “Zigbee range extender”) (an example being IKEA Tradfri Signal Repeater). Devices that can not act as routers are typically battery-operated and known as “end devices”. There are some exceptions as some end devices (e.g. Xiaomi/Aqara devices) have issues connecting through routers that are not from the same manufacturer.
  2. Use a long USB extension cable with your Zigbee coordinator adapter. This not only enables you to position the Zigbee coordinator adapter for better signal quality, but it also allows you to locate the Zigbee coordinator further away from Wi-Fi access-points/routers or other sources of 2.4GHz signals to avoid signal interference. Optimally in the best area in your home depending on your building’s floorplan. Ideally, you want to place the Zigbee coordinator somewhere in the middle of your house/apartment. Building materials influence signal quality, for example, dense/thick concrete, bricks, masonry, etc. dampen all wireless signals. Place the Zigbee coordinator with some distance from walls, ceilings and floors. Also, try different orientations of your Zigbee antenna (or your whole Zigbee coordinator adapter if it has an internal antenna). Some Antennas have a stronger signal in a certain direction. Simply changing orientation can improve signal quality already. Note: A bad USB extension cable may lead to connection issues between the system and the Zigbee coordinator adapter, symptoms of this are disconnection messages.
  3. Zigbee and Wi-Fi can operate on various channels in the 2.4GHz spectrum. A busy Wi-Fi access-points/routers that are operating in the same frequency range (overlapping channels) as your Zigbee coordinator will drown out the Zigbee traffic, especially if they are located close to each other. To avoid interference between Zigbee and Wi-Fi try to choose channels without overlap. Check the channel your Wi-Fi access-points/routers are using (either by checking on the router’s web interface or using a Wi-Fi analyzer app). Changing the channel of the Zigbee network usually requires reforming it and re-join/re-pair all of your Zigbee devices. It is therefor typically it’s a lot easier to just change the channel used by your Wi-Fi router and/or access-points. See this article for Wi-Fi and Zigbee channels coexistance to avoid using overlapping frequency ranges.
  4. Check if updating the firmware on your Zigbee coordinator adapter and your Zigbee end devices is possible. Note that depending on your hardware the latest Zigbee coordinator firmware might not always be the one recommended by the community so it is advised to ask before upgrading.
  5. If your Zigbee coordinator adapter has a removable antenna (e.g., with an SMA-connector) then you have the option of replacing it with a high-gain antenna. Note that antennas with higher gain usually have directionality: You might have better reception on the same floor, but reception across floors might suffer. In addition, you also have the option to use an antenna extension cable if needed (usually using just a USB extension cable for your Zigbee coordinator adapter is the better alternative). This should really only be needed if you are trying to cover a long distance, like to another building or very dense/thick walls, ceilings and floors.
  6. Buy more powerful Zigbee radio hardware with a better radio range, preferably with an external antenna and based on a newer chip that offers up-to-date firmware. If you are not only experimenting with Zigbee but want a permanently stable and healthy Zigbee mesh network with potentially many devices then you should consider upgrading to a more powerful and newer Zigbee coordinator USB adapter or Ethernet to serial gateway/bridge. Generally, Zigbee adapters with an external antenna will have a better range and offer you more flexibility, therefore you will also want to avoid buying an internal Zigbee adapter unless it has a port for an external antenna.

FYI, Koenkk from Zigbee2MQTT now stated that current firmware does not yet support +20 dbm output:


That means that this CC2652P based Sonoff Zigbee 3.0 USB Dongle Plus adapter with its current firmware version only operate at +5 dBm output, so no wonder it does not perform better when compared to Electrorama’s zzh dongle which is based on CC2652R that physically only capable of +20 dBm output. Thus only once we get a new community firmware with RF switch configured will enabling +20 dBm output in application settings actually work.

chiakikato also manually tested Sonoff Plus dongle hardware and confirms it support +20 dBm output:


Guess that means that Mat will have to do another test and update his review when get new firmware.

1 Like

FYI, I have now also confirmed that running the attached uartLog.py script from Sonoff docx part from ITead’s HOW TO FLASH FIRMWARE TO CC2652P instructions do indeed make ITead’s Sonoff Zigbee 3.0 Plus Dongle automatically enter bootloader mode and after running that script just to get into BSL mode I could flash it directly using llama-bsl.py and cc2538-bsl.py scripts without having open the enclosure and pressing the BTL button which I too indeed found very convenient.

I first tested with llama-bsl GitHub - electrolama/llama-bsl: Python cross-platform script to upload firmware via the serial boot loader onto the CC13xx, CC2538 and CC26xx SoC.

python llama-bsl.py -p COM5 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex

I then also tested running the uartLog.py script again to test cc2538-bsl GitHub - JelmerT/cc2538-bsl: Python cross-platform script to upload firmware via the serial boot loader onto the CC13xx, CC2538 and CC26xx SoC.

python cc2538-bsl.py -p COM5 -evw CC1352P2_CC2652P_launchpad_coordinator_20210708.hex

Both upgrades worked fine.

You might have to manually install/upgrade a few dependencies if do not installed/upgraded properly:

python -m pip install --upgrade pip setuptools wheelpy gevent llama-bsl

python -m pip install --upgrade pip setuptools wheelpy gevent cc2538

Though it might be better to download latest llama-bsl master branch or cc2538-bsl main branch versions from https://github.com/electrolama/llama-bsl and https://github.com/JelmerT/cc2538-bsl as latest fixes might not be in a release published on PyPi via pip

Other prerequisites is that had already installed CP210x USB to UART Bridge VCP Drivers from Silicon Labs and Python for Windows (Windows Installer 64-bit version)

As mentioned the uartLog.py script also lists all active COM ports on MS Windows (tested on Windows 10) so only have you enter the number of the COM port, but note that the script is currently hardcoded for Windows COM ports so would need to be modified before it can be used under Linux.

PS: Submitted as a feature request for llama-bsl here → Add option for Auto BSL to try both high and low signals to enter bootloader? · Issue #11 · electrolama/llama-bsl · GitHub

Guide for how-to upgrade firmware on Sonoff USB Plus Dongle without openning its enclosure

The main benefit of this method is that don’t need to open the dongles enclosure/casing, (this method could also be made to work across Windows, MacOS and Linux platforms if modify uartLog.py or better yet patch cc2538-bsl with working delays for CP2102N dongle uses).

  1. Install Silabs CP210x drivers (if not already installed/available, at least needed on Windows).
  2. Install Python for Windows (Windows Installer version)
  3. In command-prompt run: python -m pip install --upgrade pip setuptools wheel ​gevent cc2538
  4. Get “uartlog.zip” ZIP file package from either Sonoff docx or cc2538-bsl issue #113, open/unpack “uartLog.py” to ex. “C:\temp” then in command-prompt run: C:\temp\uartLog.py to get option and enter correct number for COM port (note that this step would no longer be needed in the future if and when “Auto BSL” gets patched with working delays for Sonoff USB Plus dongle in the cc2538-bsl script).
  5. Download latest firmware from Z-Stack-firmware/coordinator/Z-Stack_3.x.0/bin at master · Koenkk/Z-Stack-firmware · GitHub and unpack to example “C:\temp” then in command-promt run: python cc2538-bsl.py -p COM5 -evw C:\temp\CC1352P2_CC2652P_launchpad_coordinator_20210708.hex (replacing COM5 with correct COM port and right name/version and location of unpacked firmware file).

Again, this guide could relatively easily be translated to Linux or Mac OS and be further automated via scripting, (the problem there is that the uartLog.py script from Sonoff has been hardcoded for Windows COM ports so the port manager in it needs to be modified).

Tip! cc2538-bsl can be replaced by experimental llama-bsl fork if willing to test it, though it has same “Auto BSL” delay issue with Sonoff USB Plus dongle, but developer of llama-bsl is considering adding several additional features that will make it more user-friendly than cc2538-bsl:


PS: ITead/Sonoff own developers could of course have made this much simpler if they themselves submitted patches to cc2538-bsl script.

FYI, Koenkk made a “dev” pre-release of Z-Stack_3.x.0 20211114 community version for this as others:


Note! CC1352P2_CC2652P_launchpad_coordinator_20211114 is a pre-releaser so not fully tested yet!

Z-Stack_3.x.0 20211114 community firmware is based on latest SDK which contains many bug-fixes:



20 dBm output power still not enabled so CC2652P will perform as 5 dBM CC2652R/CC2652RB, see:


Also, FYI, there is no real news on community firmware with Hardware Flow Control enabled, see: