ITead Zigbee 3.0 USB dongle/stick/adapter based on Silicon Labs EFR32MG21

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:

https://www.itead.cc/zigbee-3-0-usb-dongle.html

Note! Read all updates as the real-life test shows it has hardware issues that need some workarounds:

Update 2021-04-21: People are reporting EMF/EMI/RFI interferences issues causing serious problems with signal reception and especially Zigbee device pairing failures with the initially released hardware revision (HW version “V1.3 2020-12-07”) unless at least use it with a long USB extension cable to get it away from other electronic devices/appliances that are sources of electromagnetic interference and strong radio signals on the same frequency range/band. It is therefore strongly recommended also buy/use a long USB extension cable to get it away some distance from interference made by the computer, other appliances, Wi-Fi access-points or WiFi router. The root cause for this seems to likely be due to a combination of poor antenna design and a lack of electromagnetic shielding in the current design of the initial hardware, (and is maybe something that also can perhaps could be worked around by adding your own DIY electromagnetic shielding to the dongle board by applying a layer of conductive metallic tape over a layer of isolated tape, making sure to ground the conductive metallic tape to USB plug outer metal cover, see idea).

Update 2021-04-16: Pre-flashed firmware it comes with has a bug so requires FW upgrade before use.

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

ITead Zigbee 3.0 USB Dongle Model: 9888010100045 (Hardware Revision Version 1.3)

image

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?

https://www.facebook.com/watch/?v=262086502015726

In that video, they mention that they are targeting DIY home automation users and testing Silabs EmberZNet 6.7.8.0 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?

https://www.openhab.org/addons/bindings/zigbee/#ember-ezsp-ncp-coordinator

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.

Tip! Ember USB Zigbee adapters/dongles/sticks like these are highly recommended over using a remotely connected Ember module using a serial-to-ip bridge / serial forwarding server like ser2net.

https://github.com/zigpy/bellows#warning-about-zigbee-to-wifi-bridges

FYI! Basically the serial protocol API for EmberZNet Zigbee coordinator application running on the Silicon Labs SoC/MCU does not deal well with unexpected loss of communication caused by network drops. The reason Ember remote bridges over serial-to-IP proxy server is not recommended 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.

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:

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle

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

https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/

This firmware upgrade tool has also been packaged by walthowd in a docker image:

https://github.com/walthowd/husbzb-firmware

Note! As you can see from the pictures the radio chip and the crystal does circuit does not have a EMF shielding (metal plate cover) which means that this board will be very sensitive with its current hardware design will have very high receive sensitivity to electromagnetic interference (EMI) / radio-frequency interference (RMI). This means that it will be extra important to keep it away from any other electronic devices or appliances that may generate an electromagnetic field (EMF or EM Field) or send our interfering radio signals. That includes the computer that you run your home automation application software on as well as any devices such as for example external harddrives or storage devices, power-supplies, etc., and of course any Wi-Fi access points or routers nearby. It also means that the dongle in its current hardware revision is unlikley to ever pass FCC certification. If adding electromagnetic shielding to your other devices/appliances is not possible then one workaround is to use the dongle with a long USB extension cable to get it away as far as possible from any sources of electromagnetic interferances.

PS: Also sad ITead didn’t add SMA or IPEX connector + external antenna or used ceramic chip antenna (new dongles with only integrated antenna should use a ceramic antenna, not just PCB trace antenna):

https://resources.pcb.cadence.com/blog/2020-understanding-ceramic-chip-antenna-vs-pcb-trace-antenna

https://www.mouser.co.id/pdfDocs/ceramicchipantennasvspcbtraceantennasacomparison.pdf

https://eu.mouser.com/Passive-Components/Antennas/_/N-8w0fa?P=1y9hq54Z1yu8mv5

1 Like

@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!

Update! Be sure to read the known issue with sensitivity to interferance and follow the advice to use an USB extension cable plus try to keep the dongle away from other devices and appliances: ITead Zigbee 3.0 USB dongle/stick only cost $7 and is based on Silicon Labs EFR32MG21 - #60 by Hedda

@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.

https://www.openhab.org/addons/bindings/zigbee/#ember-ezsp-ncp-coordinator

"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 https://github.com/zigpy/bellows#emberznet-and-ezsp-protocol-version

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:

https://www.itead.cc/zigbee-3-0-usb-dongle.html

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?

@Hedda

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):

https://www.ikea.com/us/en/p/tradfri-signal-repeater-30400407/

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:

https://github.com/home-assistant/home-assistant.io/pull/15789

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

https://github.com/home-assistant/home-assistant.io/pull/17134

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.

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-socs/device.efr32mg21a020f1024im32

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules

https://www.ti.com/document-viewer/CC2652P/datasheet

  • 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

https://community.arm.com/developer/ip-products/processors/trustzone-for-armv8-m/f/trustzone-armv8-m-forum/8338/what-is-the-top-level-difference-in-features-between-cortex-m33-and-cortex-m4

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 ?

4 Likes

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

https://github.com/home-assistant/core/issues/48592

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

https://github.com/walthowd/husbzb-firmware

https://github.com/walthowd/husbzb-firmware/commit/ea9c164651091bd22c55467ec8734985e63c4fd4

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

https://github.com/xsp1989/zigbeeFirmware/tree/master/firmware/Zigbee3.0_Dongle

@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.

https://github.com/zigpy/zha-device-handlers

https://github.com/Koenkk/zigbee-herdsman-converters

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

https://docs.smartthings.com/en/latest/device-type-developers-guide/

https://github.com/SmartThingsCommunity/SmartThingsPublic

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 !

1 Like

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.