ITead Zigbee 3.0 USB dongle/stick only cost $7 and is based on Silicon Labs EFR32MG21

Tags: #<Tag:0x00007fc8fe900528> #<Tag:0x00007fc8fe9003c0> #<Tag:0x00007fc8fe9002f8>

ITead (of Sonoff fame) has announced that will soon sell an inexpensive Zigbee 3.0 USB dongle based on Silicon Labs EFR32MG21 which is a very powerful MCU with an integrated +20 dBm radio amplifier.

Update 2021-40-16: Firmware released with it has a bug so it requires a firmware upgrade before use.

Update 2021-03-16: ITead have manufactured a limited production run and now sell it for $$6.99 (US):

ITead Zigbee 3.0 USB Dongle Model: 9888010100045


They have posted a video on ITead’s Facebook group for Sonoff showing this new dongle working out-of-the-box with the ZHA integration for Home Assistant (via the bellows radio library for its zigpy dependecy), however since it will come with the standard Silabs EmberZNet (a.k.a. “Ember”) Zigbee NCP coordinator firmware with its default EZSP serial protocol interface enabled so I believe that it should also work out-of-the-box with OpenHAB Zigbee Bindings too if it now supports EZSP v8?

In that video, they mention that they are targeting DIY home automation users and testing Silabs EmberZNet firmware on it to ship it pre-slashed for compatibility with ZHA for Home Assistant. EmberZNet 6.7 introduced EZSP v8 which uses a new framing format and expanded command id field from 8 bits to 16 bits. They also mention in the video at this EFR32 Mighty Gecko Series 2 dongle will ship with firmware config for 115200 bit rate speed by default so might have to change flow control configuration in OpenHAB Zigbee Bindings?

I have asked ITead via e-mail and been told that their design phase is completed and got the information ITead will initially only sell this Zigbee 3.0 Dongle without an external antenna (no SMA-connector or IPEX connector, so a built-in circuit board antenna only) and without a plastic-case as an enclosure (same as how they sell their CC2531 dongle today). I was also told that this new dongle will use the exact same Silabs SKU for the EFR32MG21 chip that is used on the board inside their Sonoff ZBBridge Zigbee Bridge (which can use as an alternative Zigbee to WiFi bridge if flashed with Tasmota and other Zigbee coordinator firmware).

I have no idea if they started production run or when it will available for purchase, however, my guess is that it will be sold at a relatively low price from their China store considering that their existing Zigbee Home Automation 1.2 dongle cost $3.99 and their Sonoff ZBBridge cost $16.90 in their China store.

Updated thread with price + links and some new information from ITead after the product was released.

Older and newer firmware as linked to by ITead:

Elelabs EZSP Firmware Upgrade Utility can be used to flash the firmware to a newer or older version:

@cyrilpawelko and others have posted that OpenHAB works with Tasmota’s Serial-to-IP bridge on Sonoff ZBBridge Zigbee Bridge with EmberZNet 6.7 firmware so that should mean that ITead’s upcoming USB dongle will probably work-out-of-box with “Ember EM35x Coordinator” in OpenHAB Zigbee Bindings.

That is as, long have drivers for Silabs CP210x (USB to UART Bridge VCP Virtual COM Port) is already installed in the operating system, (and note reboot is required on Windows OS after install VCP driver).

Note! Ember USB Zigbee adapters/dongles/sticks are highly recommended over using a remotly connected Ember module using a serial-to-ip bridge / serial forwarding server like ser2net. The reazon for this is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios. The developers of the bellows radio library for the zigpy project has more information about this if needed.

I don’t have one of these yet but quoting and paraphrasing @cyrilpawelko installation how-to for USB:

  • Sonoff branded Zigbee 3.0 USB dongle should come pre-flashed with EmberZNet 6.7.8 or later.
  • Install drivers for Silabs CP210x (USB to UART Bridge VCP Virtual COM Port) if not already installed in the operating system, (and note reboot is required on Windows OS after install VCP driver).
  • Install the Serial Binding in OpenHAB.
  • You must also configure OpenHAB startup script to include /dev/ttyxyz for the USB adapter COM port as stated in the documentation: Serial Port Configuration | openHAB
  • Install the Zigbee Binding in OpenHAB.
  • Add a new Zigbee “Ember EM35x Coordinator” thing (set the serial port to /dev/ttyxyz correctly).
  • Start pairing Zigbee devices as stated on the Zigbee Binding documentation: ZigBee - Bindings | openHAB
    • Search for Zigbee things
    • Put your device in pairing mode and it should appear very soon (piring mode is normally only open for 10-60 seconds depending on manufacturer, model and firmware).
    • Wait for the discovery to finish (a name should appear, not “unknow zigbee device”
  • Enjoy!

@chris Does the Zigbee Binding for OpenHAB supports EZSP v8 on EFR32MG2 (EFR32 Series 2)?

Zigbee Bindings documentation does not specifically mention which versions of EZSP are supported.

"EmberZNet and EZSP Protocol Version

Silicon Labs does not currently have a consolidated list of changes by EmberZNet SDK or EZSP protocol version. The EZSP additions, changes and deletions have only ever been listed in the “Zigbee EmberZNet Release Notes” (EmberZNet SDK) under the “New items” section as well as the matching UG100 EZSP Reference Guide included with each EmberZNet SDK release.

The largest change was between EZSP v4 (first added in EmberZNet 4.7.2 SDK) and EZSP v5 that was added in EmberZNet 5.9.0 SDK which requires the Legacy Frame ID 0xFF. The change from EZSP v5 to EZSP v6 was done in EmberZNet 6.0.0 SDK. The change from EZSP v6 to EZSP v7 was in EmberZNet 6.4.0 SDK. EmberZNet 6.7.0 SDK added EZSP v8 (and Secure EZSP Protocol Version 2).

Perhaps more important to know today is that EZSP v5, v6 and v7 (EmberZNet 6.6.x.x) use the same framing format, but EmberZNet 6.7.x.x/EZSP v8 introduced new framing format and expanded command id field from 8 bits to 16 bits."

Quoting bellows library for zigpy

Yes - it has for about 12 months.

1 Like

I guessed so, thank you very much for confirming that!

This inexpensive Zigbee 3.0 USB dongle from ITead is now available for $6.99 (US) directly from China:

Looks like a limited first production run so maybe not get greedy and perhaps let developers order first?

1 Like

CNX Software has now posted a blog-post with some more technical specifications on this new dongle:

I’m having problems of stability with the CC2531 coordinator. Too slow, things are offline when they are actually on and viceversa… Slow to no response…

Is it worth changing the zigbee sniffer? I mean, are there quality difference between dongles?


Maybe, if you have many Zigbee 3.0 devices or got CC2531 without external antenna, but regardless, Zigbee uses mesh network technology at its core so you really first want to add and always have a stable backbone with a few Zigbee Router devices (non-dropping always-on mains-powered devices).

#1 Tip! Buy a few IKEA TRÅDFRI Signal Repeater (different IKEA models available in most countries):

Normally most mains-powered devices act as a Zigbee router but some are bad and some are great.

Suggest read generic Zigbee best practice tips here:

Another suggestion is to read up on the very important purpose of Zigbee routers:

Most definitely between Microcontroller Unit hardware specification (at least MCU performance and SoC radio capability) + antenna design and implementation, as well as possibility or not to change antenna position/orientation. But again, unless have many Zigbee 3.0 devices (which require more flash storage) it is usually most important to just make sure have many good Zigbee router devices in your Zigbee mesh network to allow more devices plus extend network range and coverage.

Today the closest competitor to Silicon Labs EFR32MG21 / MGM210 based USB sticks will be all the upcoming USB sticks that will be based on Texas Instruments CC2652P (CC2652R/CC2652RB variant with an integrated Power Amplifier).

Silicon Labs EFR32MG21 (EFR32 Mighty Gecko Series 2) SoCs and MGM210 modules are newer or released later and on paper, the EFR32MG21A020F1024IM32 used in thís ITead Zigbee 3.0 USB Dongle is more powerful than any currently available in Texas Instruments CC2652 series plus have slightly more onboard resources than the CC2652P, but I think that in practice for average users in a real-world scenario the MCU raw specification of Silicon Labs EFR32MG21 and Texas Instruments CC2652P on a data-sheet comparison will not be as important as antenna quality and antenna positioning.

  • Zigbee Stack = EFR32MG21 support EmberZNet versus CC2652P supporting Z-Stack
  • Both have separate bootloader firmware as standard so can be reflashed without debug adapter.
  • Flash Storage = EFR32MG21 has 1024KB flash versus CC2652P 352KB flash + 256KB ROM
  • RAM = EFR32MG21 feature 96KB RAM versus CC2652P featuring 80KB RAM + 8KB SRAM
  • CPU core = EFR32MG21 80MHz ARM Cortex-M33 versus CC2652P 48-MHz Arm Cortex-M4
  • Both feature 2.4 GHz amplified radio with maximum 20 dBm power transmitter (TX) output
  • Zigbee receive sensitivity (less is better) = EFR32MG21 -104 dBm versus CC2652P -100 dBm

Though you also need to understand that each USB-module/adapter implementation will be different, like for example onboard circuit-board antenna versus SMA-connector or uFL + external antenna and several choices of USB-to-Serial/UART chips, so keep that too in mind when comparing USB dongles.

By the way, you mean “Zigbee Coordinator”, not “Zigbee Sniffer” as that is firmware for ‘eavesdropping’.

Interesting - thanks for posting. This will run the standard EZSP firmware - if I can get one or two I will try (I’m living in a hotel at the moment so things are not so simple).

1 Like

Just received my iTead stick and yes it worked out of the box on my openHABian RPi.

Also tried the Elelabs firmware tool but they don’t recognize it.

Then again I’m still struggling with the Aqara devices I use for testing. My door sensor keeps dropping offline, requires me to reset the coordinator to get back online but even then doesn’t reliably send data until I reset and rejoin the device.
Yes I know they aren’t standards compliant but I thought it’s about difficulties in joining only. But like that it’s completely unusable.
With the deconz binding they seem to work fine but the Conbee is €40 (and of course does not use your binding) but what’s the value in a cheap coordinator when you have to buy more expensive devices ?


Sounds promising because read many Home Assistant ZHA users have issues pairing devices, see:

It suggest try this Docker image with the same firmware updater tool as it’s been modified to support it:

ITead points to xsp1989 GitHub for NCP application firmware images but there might be alöternatives?

@chris Does Zigbee Binding for openHAB have device handlers/converters for ‘quirk’ workarounds?

Home Assistant has “ZHA Device Handlers” and Zigbee2MQTT has “zigbee-herdsman-converters” which have similar concepts of converting non-compliant device attributes to follow Zigbee standards.

SmartThings Classic (Samsung) support similar custom “Device Handlers” concept for Zigbee devices:

These concepts of seperating device handlers/converters makes modular and seperate for core apps.

It doesn’t have a generic system for this, no.

I did a quick test with a Philips Hue bulb and a Datek Apex smart plug.
Both did not work on my Bitronvideo usb stick, they just left the mesh.
Both did work on the Itead stick. And there was no trouble including them.
Same for some Ikea bulbs I used for testing, they all got included on the first try.
I have not tried any batterydriven devices yet.

The Aqara/Lumi sensors was a pain to include on the Bitronvideo, so I guess no change there.

1 Like

Oh yes an ability like that would be a very useful and highly appreciated feature for the OH zigbee binding - pretty please !

That would probably be a good idea. Unfortunatly I do not have the skill (or time) to code that for OH.

That plea was directed at @chris. But I’m well aware he has got definitely more important stuff to get done ATM.

Personally I don’t see a huge utility in this sort of feature. It takes a lot of time to code, and generally doesn’t help many users. It is generally better to resolve the issue with a custom handler.