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

[robmac (R Macdonald)]

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 lumi.weather'

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,

[Hedda]

@robmac

I am still using 6.7.9.0 SW flow control and the zigbee network is behaving though the RF range is limited. I am getting about 50% less range than the zwave stick installed in the same machine for direct communication.

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.

@robmac

I do have an AP in the same room so there could be interference for ZigBee which would not impact zwave.

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:

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

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.

[robmac (R Macdonald)]

Thanks for all of that info.

Especially useful if I was running Home Assistant

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?

[Hedda]

@robmac

Thanks for all of that info. Especially useful if I was running Home Assistant

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

[Hedda]

@robmac

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

It is not yet well-tuned from the discussion in https://github.com/xsp1989/zigbeeFirmware/issues/15

[chris (Chris Jackson)]

@robmac

I am sure there are neighbours

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.

[chris (Chris Jackson)]

@robmac

and possibly sleeping aqara devices

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.

[Hedda]

@Hedda

Note! Developers and users who tested this as a Zigbee coordinator now believe that device paring issues with this Zigbee 3.0 dongle from ITead seem to be due to extreme sensitivity to component and environmental noise in the form of electromagnetic interferences as they discovered that device pairing works much better if use a long USB extension cable and get it as far away from other electronic appliances as possible (including the computer that you run your home automation application software on as well as any devices such as example external harddrives or storage devices, and power-supplies, etc.).

Their troubleshooting has revealed that CCA fail count gets much lower with a USB extension cord.

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

It is true that using a USB extension cable and trying to keep it away from other possible sources that can interfere with receiving signals is the general recommendation for all RF radio dongles for home automation control, but in this specific case, the interference symptoms are so extreme that users are reporting not being able to pair any devices at all unless getting it some distance away from their computer plus devices/appliances like external harddrives (and of course any WiFi access points, etc.).

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

https://en.wikipedia.org/wiki/Heat-shrink_tubing

https://en.wikipedia.org/wiki/Kapton

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

https://en.wikipedia.org/wiki/Electrically_conductive_adhesive

https://en.wikipedia.org/wiki/Copper_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!

Reference:

https://en.wikipedia.org/wiki/Electromagnetic_shielding

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

[Hedda]

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

https://community.openhab.org/t/itead-sonoff-zigbee-3-0-usb-dongle-plus-based-on-texas-instruments-cc2652p-coming-soon/126738

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.

ITead's "Sonoff Zigbee 3.0 USB Dongle Plus" (model "ZBDongle-P") based on Texas Instruments CC2652P +20dBm radio MCU now sold for $19.99

UPDATED! The announced TI CC2652P based “Sonoff Zigbee 3.0 USB Dongle Plus” from ITead, later renamed to “ZBDongle-P”, has been released and looks to be great value for a premium hardware package sold for a low price. It is based on Texas Instruments CC2652P radio chip and this “ZBDongle-P” variant is to be sold side-by-side as an alternative to their new “ZBDongle-E” variant that is based on Silicon Labs EFR32MG21 that SoC chips both practically have the same specifications on paper but uses di…

[noryn (Ronny)]

Thanks for sharing

[Hedda]

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

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

https://github.com/xsp1989/zigbeeFirmware/issues/18

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

[FranzS]

Hi Hedda,

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

BR
/Franz

[NilsOF (Nils)]

@FranzS

Everything is still working

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.

[FranzS]

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

[FranzS]

@NilsOF

[chris (Chris Jackson)]

@NilsOF

Do you have the zigbee routing and neighbour info in the UI for the devices?

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

[NilsOF (Nils)]

@chris

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.

[chris (Chris Jackson)]

@NilsOF

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.

[NilsOF (Nils)]

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.

[FranzS]

@NilsOF , now it’s shown