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

Updated to latest #2354 and I was just watched the log in frontail and had not noticed a couple of errors on start. I think I missed these before as I walked away and only looked later.

I assume they are caused by start order and possibly sleeping aqara devices. I am treating as a test observation as the network is working fine.

2021-04-28 10:10:51.492 [DEBUG] [l.converter.ZigBeeConverterOccupancy] - 00158D0006358113: Initialising device occupancy cluster

2021-04-28 10:11:31.468 [ERROR] [r.ZigBeeConverterAtmosphericPressure] - 00158D0006B2919F: Error 0xffff setting server binding

2021-04-28 10:11:31.470 [INFO ] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006B2919F: Channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_pressure failed to initialise device

2021-04-28 10:11:31.472 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006B2919F: Initializing channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_humidity with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterRelativeHumidity@73c398

2021-04-28 10:11:31.472 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D0006358113: ZigBee node property discovery using OTA cluster on endpoint 826D/1

2021-04-28 10:11:51.469 [ERROR] [r.ZigBeeConverterAtmosphericPressure] - 00158D0006B2919F: Error 0xffff setting server binding

2021-04-28 10:11:51.471 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006B2919F: Channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_pressure failed to initialise device

2021-04-28 10:11:51.472 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006B2919F: Initializing channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_humidity with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterRelativeHumidity@8e8f46

2021-04-28 10:12:11.469 [DEBUG] [converter.ZigBeeConverterTemperature] - 00158D0006B2919F: Failed to bind temperature measurement cluster

2021-04-28 10:12:11.473 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006B2919F: Initializing channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_pressure with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterAtmosphericPressure@38fbdb

2021-04-28 10:12:11.473 [DEBUG] [converter.ZigBeeConverterSwitchLevel] - 00158D0006358113: Level control initialized as client

2021-04-28 10:12:11.475 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Channel initialisation complete

2021-04-28 10:12:11.477 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Thing is RFD, using long poll period of 1800sec

2021-04-28 10:12:11.478 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Setting ONLINE/OFFLINE timeout interval to: 14430

2021-04-28 10:12:11.480 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker added for thingUID=zigbee:device:0963bb1626:00158d0006358113

2021-04-28 10:12:11.481 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:device:0963bb1626:00158d0006358113

2021-04-28 10:12:11.484 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:device:0963bb1626:00158d0006358113 in 14430 seconds

2021-04-28 10:12:31.473 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Channel initialisation complete

2021-04-28 10:12:31.475 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Thing is RFD, using long poll period of 1800sec

2021-04-28 10:12:31.476 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0006358113: Setting ONLINE/OFFLINE timeout interval to: 14430

2021-04-28 10:12:31.477 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker added for thingUID=zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113

2021-04-28 10:12:31.478 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker reset for handler with thingUID=zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113

2021-04-28 10:12:31.479 [DEBUG] [.zigbee.handler.ZigBeeIsAliveTracker] - IsAlive Tracker scheduled task for thingUID=zigbee:xiaomi_lumisensor-motion:0963bb1626:00158d0006358113 in 14430 seconds

2021-04-28 10:12:51.471 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006B2919F: Update ZigBee device zigbee:device with bridge zigbee:coordinator_ember:0963bb1626, label 'LUMI'

2021-04-28 10:12:51.475 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006358113: Initializing channel zigbee:device:0963bb1626:00158d0006358113:00158D0006358113_1_dimmer with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterSwitchLevel@1938ec6

2021-04-28 10:12:51.755 [DEBUG] [ding.zigbee.internal.ZigBeeDataStore] - 00158D0006B2919F: ZigBee saving network state complete.

2021-04-28 10:13:11.471 [ERROR] [r.ZigBeeConverterAtmosphericPressure] - 00158D0006B2919F: Error 0xffff setting server binding

2021-04-28 10:13:11.473 [INFO ] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006B2919F: Channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_pressure failed to initialise device

2021-04-28 10:13:11.475 [DEBUG] [scovery.ZigBeeNodePropertyDiscoverer] - 00158D0006358113: Could not get OTA firmware version from device

2021-04-28 10:13:11.476 [DEBUG] [bee.discovery.ZigBeeDiscoveryService] - 00158D0006B2919F: Initializing channel zigbee:device:0963bb1626:00158d0006b2919f:00158D0006B2919F_1_humidity with org.openhab.binding.zigbee.internal.converter.ZigBeeConverterRelativeHumidity@1bdd3c1

Network working fine after start complete,

That sounds totally normal and should be expected when comparing Zigbee to Z-Wave.

Understand that as Zigbee operate at 2.4GHz frequency bands and Z-Wave operate at sub-1GHz frequency bands (i.e. 868.42MHz in Europe and at 908.42 MHz in North America), Zigbee is not only operating in a more crowded frequency range and as such more likely to have signal interference, the higher frequency range that Zigbee uses also have significantly worse penetration than Z-Wave if all else is equal. This is why it is extra important to add Zigbee Router devices to extend range of Zigbee network mesh.

If possible you really locate/place the Zigbee stick as far away from any other radios or other devices/applicances that can cause signal interference.

You should also add additional Zigbee Router devices so that especially battery-operated devices or devices with poor reception preferably have a main-powered Zigbee routing device that is always online close to where it is located (like in the same room).

Again I proposes that these tips on improving Zigbee network range be added to Home Assistant docs:

Improving Zigbee network range

Low signal quality can lead to transmission errors and related issues. This section has a list of fundamental tips on how to improve signal quality. Improving signal quality also maximizes range and resolves most 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 and submitting debug logs.

  1. Add more Zigbee routers between devices far away and the next closest router. Distribute more Zigbee routers in areas with poor reception. Zigbee network topology uses a “mesh network” design which means that each device that acts as a Zigbee router will extend the range of your Zigbee network as a whole. While there are exceptions, almost all permanently powered devices serve as a Zigbee router. Adding more permanently powered Zigbee devices allows getting 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”). Devices that can not act as routers are typically battery-operated and known as “end devices”. Some end devices have issues connecting through routers (e.g. Xiaomi/Aqara devices).
  2. Use a USB extension cable. This allows positioning the Zigbee coordinator adapter for better signal quality. Position the Zigbee coordinator away from Wi-Fi access-points/routers or other sources of 2.4GHz signals to avoid signal interference. The best location depends on your building’s floorplan. Ideally, you want to place the Zigbee coordinator somewhere in the middle. Building materials do influence signal quality too, 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). The Zigbee channel is currently not shown in the Home Assistant front-end but you can find the channel in the logs (watch out for Network parameters log entry with the channel number, e.g., radioChannel=15). Changing the channel of the Zigbee network needs recreating it and re-join/re-pair all of your Zigbee devices. Typically it’s a lot easier to change the channel used by your Wi-Fi. See this article for Wi-Fi and Zigbee channels coexistance to avoid using overlapping frequency ranges.
  4. Update the firmware on your Zigbee coordinator adapter and your Zigbee devices. 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 using a high-gain antenna. Note that antennas with higher gain 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 better radio range, preferably with an external antenna. If you are not only experimenting but want a permanently stable and healthy Zigbee network with potentially many devices then you should consider upgrading to a more powerful Zigbee coordinator USB adapter. Generally, those with an external antenna will have better range, therefore you will also want to avoid buying an internal adapter unless it has an external antenna.

Thanks for all of that info.

Especially useful if I was running Home Assistant :wink:

The WiFi is on 12 so I put zigbee on 11 so it should not be impacted by the AP closest. The one that serves the middle of the house is on 6 so not so good.

It is interesting what the note says about increased gain but I presume the greater directionality of the higher gain will have other issues. I keep meaning to get one of those cheap spectrum analysers. Possibly it is time to check how well these sticks are working.

Do you know how well tuned the RF on the ITead stick is?

All that specific information is independent of Zigbee implementation so it applies to OpenHAB too :stuck_out_tongue:

1 Like

It is not yet well-tuned from the discussion in

1 Like

This information is not necessarily updated often - it depends on the setting for the mesh update time which I think now defaults to 1 day.

1 Like

Yes, these are caused by sleeping devices - you can ignore them. The binding does this each start as it can’t be 100% sure if it was done previously, but if this configuration was done during the initialisation, then it doesn’t matter.

1 Like

FYI, other than using a very long USB extension cable with your dongle and adding electromagnetic shielding to your other devices/appliances (like your Raspberry Pi enclosure), another tip is to add electromagnetic shielding to all the parts of the dongle circuit board that is not the PBC trace antenna.

This type of electromagnetic shielding can done by first wrapping it in one layer of some kind of isolating film or tape around it and then wrapping a layer of conductive metallic tape on top of that.

Just make sure to not cover the antenna and as well as electrically grounding the conductive metallic tape to the USB jacketing (which act as a point of the electrical ground) checking it makes contact.

Rather than using just any tape lying around a better solution would probably be a good idea try using either heat-shrink tubing or kapton-tape as the isolation layer (both types are widely available online).

Also, rather than using any metallic tape, suggested consider buying conductive copper tape (checking that the adhesive/glue on the metallic tape really is a “conductive” variant as “non-conductive” variant also exist, as then it should be easy to ground that conductive tape by just wrapping part of the USB mantel/jacketing as the point of the electrical ground). Tip is to just search for “conductive metal tape”.

…once I get around to this myself I probably do it overkill style; i.e.:

  1. First wrap a layer of Kapton-tape (no need to touch USB mantel, and making sure not to cover the PCB trace antenna on the board),
  2. Then wrap a layer of conductive metallic tape, (that needs to touch USB mantel/jacketing, and making sure not to cover the PCB trace antenna on the board).
  3. Lastly heat-shrink tubing over everything (here you could probably choose if you also want to cover PCB trace antenna or not).

Again, be sure to touch USB to ground copper-tape but not to cover the tip of the dongle/stick circuit board which has PCB trace antenna!


PS: If you are using a Raspberry Pi or other single-board-computer with wired Ethernet and you do not need to use its WiFi or Bluetooth then you can also add a layer of electromagnetic shielding to its enclosure as well (or just buy a metal case for it).

FYI, ITead just announced an upcoming “Sonoff Zigbee 3.0 USB Dongle Plus” based on TI CC2652P:

I understand ITead only 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 fixes 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 existing ‘non-Plus Zigbee 3.0 USB dongle’ is based on Silabs EFR32MG21 SoC which is just as powerful but sadly was proven that ITead’s first Zigbee 3.0 USB Dongle PCB board revision had a badly designed integrated PCB antenna and no electromagnetic shielding which caused huge issues, and to this date, it has been listed as “out-of-stock” since after the initial batch was sold.

1 Like

Thanks for sharing

FYI, ITead has now released Silabs EmberZNet 6.10 (v6.10.3) firmware for their EFR32MG21 dongle:

xsp1989 also announced the good news is that a router firmware “will be released soon” (so probably).

Hi Hedda,

short feedback also from my side.
Flashed it → Everything is still working :slight_smile:


1 Like

Do you have the zigbee routing and neighbour info in the UI for the devices?
These seems to have gone missing for me on the previous latest firmware…
Will try the latest firmware asap.

Hi Nils,
Where can I find that information?
I just updated because I‘ve started from scratch.


Have you updated the mesh? By default this is only done by the binding once oer day.

Yes, I have. I even tryed every hour.
I see @FranzS have [] for these values…

Yesterday I noticed two of my wallplugs was offline, so I deleted them and included them again.,( these are at the limit of my existing mesh)
Suddenly these got neighbour
Information… so, I do not know yet where it goes wrong.

If you really want to try and work things like this out, then I’d really suggest using debug logging. Without this it’s really impossible to know.

Also, just because the binding doesn’t show this information does not necessarily mean there is any issue with the mesh network routing. To reduce network activity, the binding doesn’t request this too often as it can impose a huge load on the system.

Everything is working fine, so I guess all is OK under the hood.
I will of course enable debug logging, I just want to limit the possibilities first.
I do not see this on any of my Bitronvideo sticks, and @FranzS do not have routing and neighbour info on his Itead stick either.
I will see if I can replicate this on a smaller mesh.

@NilsOF , now it’s shown

1 Like