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

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

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 122 (89 by maintainers)

Most upvoted comments

HI all…so this is crazy, the stick works just fine on a Windows VM. I followed the VMWare instructions here: https://www.home-assistant.io/installation/#windows

It paired with my hue and ecosmart bulbs first time! I installed the integration the exact same way as on my RPi4… Unfortunately this is not a real fix since I dont use VMWare for my normal HA install but I can at least confirm the stick works.

image

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

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.

I heard back again from ITEAD, they suggest I try the dongle on a VMWare installation. Will figure that out and let everyone know…

Thanks for your feedback. Our technicans give a test of WIN10+VMware+Home Assistant Operating System, it can work normally. Please try again to test it:https://www.home-assistant.io/installation/linux

@Adminiuga I did get a response and they suggested I flash to the 6.7.9 firmware which most of us on this thread have already tried. I responded back that I did flash to the suggested version but no dice. I re-linked them this thread for more visibility.

My crystal has 38.4 T 0L printed on it.

IMG_8515

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.

So, either it’s not transmitting at all, or it is transmitting at the wrong channel? Do you see any markings on the onboard oscillator? Is it 40MHz crystal?

@Adminiuga I don’t see ITEAD/Sonoff sending beacons in response to beacon requests, nor do I see it sending a ZDO broadcast or anything what so ever.

This is a sniff on channel 25 after factory resetting a new bulb and while opening the network for joining:

Screenshot from 2021-04-19 10-38-39

Nothing but beacons from the bulb.

@xsp1989 – I get 1a c1 02 02 9b 7b 7e with both https://github.com/grobasoz/zigbee-firmware/blob/master/Sonoff-ZBBridge/NCP_USW_115k2_ZBBridge_690.gbl and https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle/ncp-uart-sw_679_115200.gbl

$ minicom -b 115200 -H -D /dev/ttyUSB2

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyUSB2, 10:42:12

Press CTRL-A Z for help on special keys

1a c1 02 02 9b 7b 7e 

Hrm, I’m out of ideas

i dont know why my stick works, but im using HA on docker, nothing fancy. its been a few days now, and nothing has dropped connection, battery life on my aqara sensors are looking normal.

@walthowd wanna try something crazy? If you have another ezsp adapter to test with, form network on that one and join a router. 2. Backup and restore it on ITEAD without overwriting the ieee address, no need for binding 3. Check that the router you joined, is seen by Itead and you can read attributes from it. 4. Issue network wide permit join and see if you get beacon replies from router when trying to join

@kewvention Which firmware did you end up using and having success with?

@Hedda I don’t quite grasp how to use the husbzb-firmware updater image. Not very familiar with docker. I did have success with the https://github.com/Elelabs/elelabs-zigbee-ezsp-utility/ however as I can figure that out from HA SSH webui.

i ended up using ncp-uart-sw_679_115200.gbl on april 11th i used the tool to flash it on the pi:

#python3 Elelabs_EzspFwUtility.py flash -f data/ncp-uart-sw_679_115200.gbl -p /dev/ttyUSB0 #python3 Elelabs_EzspFwUtility.py probe -p /dev/ttyUSB0

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

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

If you don’t see the Link Status Zigbee broadcasts from the coordinator every 15s or so, then something is very wrong with the TX portion of the dongle.

I am measuring 3.3V between the pin circled in both red and blue compared to ground.

@kewvention Thanks! I managed to update to the ncp-uart-sw_679_115200.gbl version! I had previously used the nsw version to no avail. I will also pull a few never paired bulbs out of storage to try out to ensure it has nothing to do with my previously paired (but factory reset) bulbs. Will report back soon!

@lonelyseraphim If you have time to chase it, try leaving and reforming your network on some different channels and see if you get any different results.

Shutdown Home Assistant – then on any computer that has a recent version of Python and bring along your zigbee.db from your HA config directory

pip install bellows
export EZSP_DEVICE=/dev/ttyUSB1
bellows -b 115200 info
bellows -b 115200 leave
bellows -b 115200 form -D /data/zigbee.db -c 25

Where /dev/ttyUSB1 is the path to your stick and 25 is the channel you want to try – I’ve tested 11 and 15 without any luck on z2m and ZHA. Channel can be anything from 11 to 26. 20 and 25 would be good to test, and maybe 19, 21, 24 and 26.

Integration installed using nsw 6.7.9 firmware, software flow control in ZHA. Here are my logs when searching for devices:

[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>] 0x0000: started initialization 0x0000:ZDO: ‘async_initialize’ stage succeeded 0x0000: power source: Mains 0x0000: completed initialization

Was not able to locate either hue or ecosmart bulbs. Again validated that I can find them with my Abode hub.

i landed here looking for a solution. i am having the same problem. i can add the zigbee adapter but unable to add devices to it.