ZHA: Unable to Pair Devices w/ ITEAD Zigbee 3.0 USB Dongle

[lonelyseraphim]

The problem

When using the ZHA integration with the ITEAD Zigbee 3.0 USB dongle I am unable to pair a variety of devices (Phillips Hue & Ecosmart) bulbs. The integration seems to install correctly and I can initiate a device search but no devices show. I have factory reset both kinds of bulbs and attempted. Additionally, I have validated that the bulbs can be successfully paired using my Abode Zigbee hub.

What is version of Home Assistant Core has the issue?

core-2021.3.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

ZHA

Link to integration documentation on our website

https://www.home-assistant.io/integrations/zha/

Example YAML snippet

No response

Anything in the logs that might be useful for us?

When selecting "add device" on the integration the logs show the following:
[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]

Included link to pastebin log during device search in additional info section.

Integration details:

Radio Type: EZSP = Silicon Labs EmberZNet protocol: Elelabs, HUSBZB-1, Telegesis by ZHA Path: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 Power Source: Mains Quirk: bellows.zigbee.application.EZSPCoordinator Dongle is seated in the USB 2.0 slot on a RPi4

Pastebin of log during device search using ZHA integration recommended debug level: Pastebin

[lonelyseraphim]

RF interference ala "ConBee" so trying with USB extension cable.

The SM-011 module and the USB-stick is not shielded and have no FCC cert = very likely !!

Are you saying I just need to get the dongle AWAY from the RPi/SSD and not necessarily use a powered hub?

[MattWestb]

No.

I dont knowing how the Sonoff dongle is working but with CornBee is working. I think its best having on powered hub but i can being that its not working if the SSD is connected to it.

Try and see what is working and not.

[Adminiuga]

Yeah, unpowered ssd is likely to cause power issue on RPi4, don't know if it was fixed or not. And in one user report, interference from a ssd enclosure was so severe, the ConBee stick would not work at all. A ssd enclosure of a better quality and Physical separation solved the problem in that case.

If you have a spare sd card, try hass on it and try on RPi4 without any ssd attached and preferably using a 1' usb extension cable. And try different bush ports, i don't remember which of usb ports on Pi4 share power with ethernet or something like that

[lonelyseraphim]

@walthowd @Adminiuga OK, so I do not have a powered hub BUT I do have a 6ft USB extension cord. I plugged that into my RPi and the dongle into the extension cable. Sure enough it picked up my hue bulb on the first try! Will continue to play around with it...

[walthowd]

Broke out a 3 meter USB extension cable, can also confirm it works!

My test platform is a NUC, and I had previously tried on two different USB3 hubs, onboard USB3 ports and onboard USB2 ports. I don't have any external USB3 devices, or external hard-drives or any other source of typical interference.

HUSBZB-1, Elelabs ELU13, CC1352P2, CC2652 and others all worked in above ports without extension cable as well.

When sniffing, I was sniffing with HUSBZB-1 which was about 10cm away from the Sonoff/Itead stick, so I'm still really baffled on why RF interference would prevent transmission?

EDIT: Tried live moving stick to all other non extension cable ports, waited for watchdog reset, no transmission detected or sniffed. Moved test bulb from 12.5cm (2.4ghz wavelength) to directly touching (0cm) the sonoff/itead stick -- no control, no transmission, all logs from bellows delivery failed.

[MattWestb]

So some signals is nuking the HFXO or some other component on the PCB so one more "CornBee scenario" (that is FCC certed).

Great findings and feed back @lonelyseraphim and all other !!

[MattWestb]

@walthowd wrapping it in some isolating and the aluminium folie and letting it grounding by the USB but dont cover the antenna and trying.

[lonelyseraphim]

I went through my home and unpaired all 14 bulbs and repaired to the ITEAD stick without any issues. Amazed that it was interference from something, likely the SSD.

[Adminiuga]

I guess we finally found a stick more sensible to interference than a ConBee stick :D

@walthowd out of curiosity, if you leave the Itead directly connected to the port and run it for a few hours. What the CCA counter shows, still 0? Cause if you don't get any link status updates, then the only explanation ncp did not transmit it because it thought the channel was busy. But to be so severe that it s busy all the time???

[MattWestb]

And @Adminiuga have getting after Xiaomi and tuya one new user problem device ;-((

[walthowd]

@Adminiuga CCA counters go straight up, seem to track total of broadcast+unicast (this is with Sonoff/itead stick back on directly attached USB2 port)

$ egrep EZSP.Counters home-assistant.log |sed -e 's/.*Counters..//' | sed -e 's/,/\n/g'  | egrep -e UNICAST\|BROADCAST\|CCA  | egrep -v " 0" | sed -e 's/\(.*CCA.*\)/\1\n/' | tail -n42

COUNTER_MAC_RX_BROADCAST: 37
COUNTER_MAC_TX_BROADCAST: 39
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_PHY_CCA_FAIL_COUNT: 39

COUNTER_MAC_RX_BROADCAST: 38
COUNTER_MAC_TX_BROADCAST: 40
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_PHY_CCA_FAIL_COUNT: 40

COUNTER_MAC_RX_BROADCAST: 39
COUNTER_MAC_TX_BROADCAST: 41
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_PHY_CCA_FAIL_COUNT: 41

COUNTER_MAC_RX_BROADCAST: 39
COUNTER_MAC_TX_BROADCAST: 41
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_PHY_CCA_FAIL_COUNT: 41

COUNTER_MAC_RX_BROADCAST: 40
COUNTER_MAC_TX_BROADCAST: 42
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_PHY_CCA_FAIL_COUNT: 42

COUNTER_MAC_RX_BROADCAST: 40
COUNTER_MAC_TX_BROADCAST: 42
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_PHY_CCA_FAIL_COUNT: 42

COUNTER_MAC_RX_BROADCAST: 43
COUNTER_MAC_TX_BROADCAST: 53
COUNTER_MAC_TX_UNICAST_FAILED: 50
COUNTER_APS_DATA_RX_BROADCAST: 2
COUNTER_APS_DATA_TX_BROADCAST: 2
COUNTER_APS_DATA_RX_UNICAST: 1
COUNTER_APS_DATA_TX_UNICAST_RETRY: 4
COUNTER_APS_DATA_TX_UNICAST_FAILED: 2
COUNTER_PHY_CCA_FAIL_COUNT: 103

Full log is here: https://paste.c-net.org/TolerantActivity

(Just using my gist which doesn't handle counter resets currently)

[Adminiuga]

Well, Itead then should borrow Conbee's recommendation to use an usb extension cable.

[Hedda]

The SM-011 module and the USB-stick is not shielded

Are you referring to the ITead dongle lacking a grounded metal shield cover plate such as for example MGM210L and MGM210P?

https://fccid.io/QOQMGM210L/Internal-Photos/Internal-Photos-4211021

https://fcc.report/FCC-ID/QOQGM210P/4460964

MGM210 (MGM210L and MGM210P) are official EFR32MG21 Series 2 Modules from Silicon Labs so should be good references.

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

[MattWestb]

Both modules is well known and designed of Silabs Finland and is FCC and many more certified nut expensive. Both is well known from new IKEA devices like Silverglans and CWS3 / @tube0013 master creations.

Yes is one must for FCC and many other certifications and is protecting the sensitive parts like X-tall and FR receiver from radio interference and can helping (with RF you cant saying it is doing but you must testing it in real) and also some more decoupling capacitors is needed for both EFR and the USB chip.

[MattWestb]

By the way the ceramic antenna is very god but expensive and is way deCONZ adapter have god RF data but not so god on other HW things,

[Hedda]

ceramic antenna is very god but expensive and is way deCONZ adapter have god RF data but not so god on other HW things

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

Ceramic chip antenna is probably worth the ~ $1 that it would add to total BOM cost, even if raising retail price of the product.

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

[MattWestb]

Better technical description https://www.mouser.co.id/pdfDocs/ceramicchipantennasvspcbtraceantennasacomparison.pdf

[Hedda]

Sounds as if the root cause for the problem with pairing due to Electromagnetic interference (EMI) / radio-frequency interference (RFI) issues is still related to a hardware design flaw as I now read that EFR32 with a properly designed circuit board design for a PCB trace antenna hardware should not need to change the HFXO CTUNE from the default parameter.

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

It sounds more and more like ITead engineers needs to take this board back to the drawing board and redesign the antenna circuits. As noted before, the ITead Zigbee 3.0 USB Dongle Model 9888010100045 with hardware revision version 1.3 currently do not follow Silabs reference antenna design.

I guess until hardware is redesigned with a better antenna design the recommendation to users should simply be to warn just not buy this ITead Zigbee 3.0 USB Dongle Model 9888010100045 with hardware revision version 1.3 if want a stable Zigbee network?

[silabs-RaoulvB]

as I now read that EFR32 with a properly designed circuit board design for a PCB trace antenna hardware should not need to change the HFXO CTUNE from the default parameter.

I really would like to know where you read this? The HFXO CTUNE has ONLY to do with the Crystal being used (and NOTHING with PCB layout around the Antenna). Every Crystal required specific optimal capacitors and the MG21 has these capacitors in the chip. The CTUNE value needs to be set to the right value corresponding to the Crystal as it basically sets the capacitance value for the on chip capacitors for the connected HFXO.

The SiLabs modules obviously know what crystal is installed and have a default value corresponding to what the manufacturer of this crystal recommends, combined with the parasitic capacitance coming from the PCB design and cannot be used as reference for a different design with different BOM and PCB layout. If you are interested in the details, please read https://www.silabs.com/documents/public/application-notes/an0016.2-efr32-series-2-oscillator-design-considerations.pdf

Disclaimer: Although I work for SiLabs, my participation here is pure personal/private and does not, in any way, represent the company SiLabs. I also have no connection at all to company ITEAD or any of their employees and must assume they are using the correct CTUNE value for the Crystal used (in fact many findings in this threat indicate there is no issue with HFXO).

[MattWestb]

I agree for 95%. Only the quality of the x-tall and the repression PCB can making its not being stable in the production. But all is very well documented in the production manual and is doing it by it and have on good quality in the manufacturing process it shall not being no problems in the end product.

SL Oy Espoo Finland ? = HW master cookers :-))

[Hedda]

As suggested by MattWestb elsewhere; 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).

[Adminiuga]

This is offtopic. The root OP cause is the dongle particular design being susceptible to RF interference.