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

lonelyseraphim commented 3 years ago

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

Hedda commented 3 years ago

i know it took my aqara sensors several attemps, mybe like 5-6 times to get it to recognize. hue bulbs took about 3 attempts.

FYI, submitted https://github.com/home-assistant/home-assistant.io/pull/17466 to ZHA documentation with best practices for avoiding pairing difficulties:

General best practices for avoiding pairing difficulties when adding Zigbee devices to ZHA

If possible try to pair your Zigbee devices in their intended final location, (instead of next to the Zigbee coordinator and then move it).
- Pairing a Zigbee device next to the Zigbee coordinator and then moving it later can result in dropped and lost connections or other issues. A "weak" Zigbee network mesh (e.g., the device is too far from the hub or a repeater)
Zigbee devices that have in the past been connected used to a other Zigbee coordinator (hub/bridge/gateway/controller) can usually only be added/paired in ZHA after they have been restored to their factory reset settings.
- If the device you want to add is not brand new and as such never paired before then you always have to make sure to first manually reset the device to its factory default settings before you will be able to add/pair it.
Some battery-operated Zigbee devices are known to have problems with pairing if they have low battery voltage.
- Some people have reported replacing the battery on their newly received Xiaomi/Aqara devices solved pairing issues.
Check that you have enough Zigbee router devices (also known as Zigbee signal repeaters or range extenders) and if you do not have any, invest and add some mains-powered devices that will work as Zigbee routers.
- Aim to start out with mains-powered devices before adding battery-operated devices as a "weak" Zigbee network mesh (e.g., the device is too far from the Zigbee coordinator or a Zigbee router) may prevent some devices from being paired. Zigbee router devices are also needed to increase the maximum of devices that can be connected to your Zigbee mesh network.
- Note that some Zigbee devices are not fully compatible with all brands of Zigbee router devices. Xiaomi/Aqara devices are for example known not to work with Zigbee router devices from Centralite, General Electrics, Iris, Ledvance/OSRAM/ LIGHTIFY/Sylvania, Orvibo, PEQ, Securifi, and SmartThings/Samsung. Better results can usually be achieved by using mains-powered devices IKEA and Nue/3A Home or dedicated DIY routing devices based on Texas Instruments CC253x/CC26x2 and XBee Series 2/3 Zigbee radios.
Be patient as the pairing of some Zigbee devices may require multiple attempts and you may sometimes need to try again and again.
- Some devices, like example those from Xiaomi/Aqara, are known to not be 100% compliant with the standard Zigbee specifications and may therefore require many paring attempts over 10-20 minutes or longer.

PS: Might also want to review pull requests https://github.com/home-assistant/home-assistant.io/pull/15789 and https://github.com/home-assistant/home-assistant.io/pull/17134

lonelyseraphim commented 3 years ago

I flashed back to the nsw firmware as stated here for best compatibility with ZHA, the integration sets up with 115200 rate and software flow control. Restarted host and reseated stick. Still unable to pair any devices after many attempts.

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

I heard back from ITEAD support and they simply suggested I try the 6.7.9 firmware which I am using. Any other debugging ideas?

I am using HA OS on a RP4, just the standard install here.

walthowd commented 3 years ago

I'm somewhat familiar with zigbee @lonelyseraphim and I also haven't had any luck pairing anything either -- I did verify again I can see everything when sniffing, which according to Chris Jackson, initialized the adapter in MFGLIB (sort of a promiscuous mode)

https://www.silabs.com/documents/public/application-notes/an1162-using-manufacturing-library.pdf

I also reversed my sniffing setup, and tried ZHA with the sonoff as the coordinator on channel 25 and sniffed with a HUSBZB-1 on channel 25. I attempted to join a single Ecosmart bulb, and I could see via the sniffer it's beacons every 10 seconds, but never a reply from the sonoff coordinator.

Screenshot from 2021-04-15 15-40-56

home-assistant.log of failed join: https://paste.c-net.org/TemporalOffence

root@b70818103f99:/tmp/silabs# bellows -b 115200 -d /dev/ttyUSB2 info
[84:71:27:ff:fe:c9:a6:60]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=d6:a6:a2:3f:47:91:d3:18, panId=0x81f5, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.TRUST_CENTER_USES_HASHED_LINK_KEY|64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 244>, trustCenterLongAddress=84:71:27:ff:fe:c9:a6:60)]
Manufacturer: 
Board name: 
EmberZNet version: 6.7.9.0 build 405

Adminiuga commented 3 years ago

That's interesting. Per se, zigpy does not control sending of the beacon replies. Iirc those should be sent out automatically by the network stack.

MattWestb commented 3 years ago

If its one firmware problem then trying Garys Sonoff ZBB that shall have the same pin out as the USB-stick but not patched RF tuner but is working.

MattWestb commented 3 years ago

https://github.com/grobasoz/zigbee-firmware/tree/master/Sonoff-ZBBridge

xsp1989 commented 3 years ago

I also spun up latest z2m dev running with the sonoff stick and it had the exact same behavior. (can't join any devices, full debug logs looks like no frames being received)

I wonder if this problem with paring Zigbee devices to new ITead Zigbee 3.0 USB dongle could also be replicated in OpenHAB?

https://www.openhab.org/addons/bindings/zigbee/

If the issue is the same in OpenHAB and zigbee-herdsman (Zigbee2MQTT and IoBroker) then hopefully ruled out ZHA and zigpy.

Koenkk/zigbee-herdsman#319

Anyone here who owns an ITead Zigbee 3.0 USB dongle and would be willing to test your same problem devices in OpenHAB?

PS: Probably unrelated but FYI; CH340E (WCH CH340 E) USB to Serial chip dongle uses is known to have issues in Linux and mac os.

I tested the following working conditions and the results are as follows(using ncp-uart-sw_679_115200.gbl):

Win10+vmware+Home Assistant Operating System+zigbee 3.0 dongle(CH340+EFR32MG21A020F768), It works great
Win10+vmware+lubuntu18.04+python3.9+home assistant+zigbee 3.0 dongle(CH340+EFR32MG21A020F768), can't add dongle to ha.
Win10+vmware+lubuntu18.04+python3.9+home assistant+zigbee 3.0 dongle(CP2102+EFR32MG21A020F768),It works great.

Is this a CH340 driver problem?

Home Assistant Operating System: https://www.home-assistant.io/installation/linux

walthowd commented 3 years ago

I tried with the 6.9.0 Sonoff Bridge firmware from Garry's repo ( https://github.com/grobasoz/zigbee-firmware/tree/master/Sonoff-ZBBridge ) with the same results .

Still just beacons when sniffing, no responses.

Screenshot from 2021-04-16 10-05-57

Post upgrade:

root@510f177ea203:/tmp/silabs# bellows info
[84:71:27:ff:fe:c9:a6:60]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=d6:a6:a2:3f:47:91:d3:18, panId=0x81f5, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.TRUST_CENTER_USES_HASHED_LINK_KEY|64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 244>, trustCenterLongAddress=84:71:27:ff:fe:c9:a6:60)]
Manufacturer: 
Board name: 
EmberZNet version: 6.9.0.0 build 178

home-assistant.log during attempted join:

https://paste.c-net.org/IrvingCoughing

These lines stood out to me, basic cluster missing and delivery failed post permit joining:

2021-04-16 09:51:24 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0000](EZSP): Attempting to checkin with device - missed checkins: 1
2021-04-16 09:51:24 DEBUG (MainThread) [homeassistant.components.zha.core.device] [0x0000](EZSP): does not have a mandatory basic cluster
2021-04-16 09:53:12 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_BROADCAST: 6>, 65532, EmberApsFrame(profileId=0, clusterId=54, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=173), 2, <EmberStatus.DELIVERY_FAILED: 102>, b'']

MattWestb commented 3 years ago

Its looks like one hardware failure and the chip is not sending any thing but the receiver is working (as you can sniffing with it).

Have you time testing Garys 6.7.8.0 ? That is working for the tasmota devs and i think the 6.9 is not so god tested (but Gary have 110% testing its loading and working) as the 6.7.8.0.

Adminiuga commented 3 years ago

@walthowd wanna try something crazy? If you have another ezsp adapter to test with, form network on that one and join a router.

Backup and restore it on ITEAD without overwriting the ieee address, no need for binding
Check that the router you joined, is seen by Itead and you can read attributes from it.
Issue network wide permit join and see if you get beacon replies from router when trying to join

MattWestb commented 3 years ago

If paring on light and one remote and binding the remote to on ZB group that light is in you can see if commands being sent and revived with the sniffer and also hopefully with USB stick then using the remote.

kewvention commented 3 years ago

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 commented 3 years ago

@Adminiuga Setup a network with a HUSBZB-1 on channel 25, joined Ecosmart bulb no problems. Backed up and restored on to sonoff stick with force.

Can't read any attributes.

2021-04-16 12:19:41 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0x51CD, EmberApsFrame(profileId=260, clusterId=0, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=19), 20, b'\x00\x13\x00\x05\x00')
2021-04-16 12:19:41 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'207b21a9602a157f08904b25aa5493099d4e27b8f9cb6798fdc3637d387d5e7e'
2021-04-16 12:19:41 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'037ba1a9602a15b8d2157e'
2021-04-16 12:19:41 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8160597e'
2021-04-16 12:19:41 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 52 (sendUnicast) received: b'000a'
2021-04-16 12:19:46 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'137bb1a96b2a157f08904b25aa5493099d4e27a1f9a867ad437e'
2021-04-16 12:19:46 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'82503a7e'
2021-04-16 12:19:46 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 63 (messageSentHandler) received: b'00cd51040100000101400100000a146600'
2021-04-16 12:19:46 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 20941, EmberApsFrame(profileId=260, clusterId=0, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=10), 20, <EmberStatus.DELIVERY_FAILED: 102>, b'']
2021-04-16 12:19:46 DEBUG (MainThread) [zigpy.device] [0x51cd] Delivery error for seq # 0x13, on endpoint id 1 cluster 0x0000: message send failure
2021-04-16 12:19:46 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection] [140604860521392] Error handling message: Unknown error
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 18, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/zha/api.py", line 683, in websocket_read_zigbee_cluster_attributes
    success, failure = await cluster.read_attributes(
  File "/usr/local/lib/python3.8/site-packages/zigpy/zcl/__init__.py", line 291, in read_attributes
    result = await self.read_attributes_raw(to_read, manufacturer=manufacturer)
  File "/usr/local/lib/python3.8/site-packages/zigpy/device.py", line 216, in request
    raise zigpy.exceptions.DeliveryError(
zigpy.exceptions.DeliveryError: [0x51cd:1:0x0000]: Message send failure

Full home-assistant.log https://paste.c-net.org/ChefsPirates

HUSBZB-1 Info and backup

root@8b84b1d3a55a:/tmp/silabs# bellows -d /dev/ttyUSB1 info
[00:0d:6f:00:0a:ff:70:a8]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=24:1a:32:fc:39:6f:d9:d0, panId=0xd3aa, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.TRUST_CENTER_USES_HASHED_LINK_KEY|64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 244>, trustCenterLongAddress=00:0d:6f:00:0a:ff:70:a8)]
Manufacturer: HubZ ZigBee
Board name: HUSBZB-1
EmberZNet version: 6.7.8.0 build 373
root@8b84b1d3a55a:/tmp/silabs# bellows -d /dev/ttyUSB1 backup > husbzb-1-backup.txt

Sonoff Initial info, restore and post restore info

root@8b84b1d3a55a:/tmp/silabs# bellows -d /dev/ttyUSB2 -b 115200 info
[84:71:27:ff:fe:c9:a6:60]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=d6:a6:a2:3f:47:91:d3:18, panId=0x81f5, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.TRUST_CENTER_USES_HASHED_LINK_KEY|64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 244>, trustCenterLongAddress=84:71:27:ff:fe:c9:a6:60)]
Manufacturer: 
Board name: 
EmberZNet version: 6.9.0.0 build 178

root@8b84b1d3a55a:/tmp/silabs# bellows -d /dev/ttyUSB2 -b 115200 restore -f -B husbzb-1-backup.txt 
Restoring NCP

root@8b84b1d3a55a:/tmp/silabs# bellows -d /dev/ttyUSB2 -b 115200 info
[84:71:27:ff:fe:c9:a6:60]
[0x0000]
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, EmberNetworkParameters(extendedPanId=24:1a:32:fc:39:6f:d9:d0, panId=0xd3aa, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)]
[<EmberStatus.SUCCESS: 0>, EmberCurrentSecurityState(bitmask=<EmberCurrentSecurityBitmask.64|32|HAVE_TRUST_CENTER_LINK_KEY|GLOBAL_LINK_KEY: 116>, trustCenterLongAddress=84:71:27:ff:fe:c9:a6:60)]
Manufacturer: 
Board name: 
EmberZNet version: 6.9.0.0 build 178

MattWestb commented 3 years ago

TRUST_CENTER_USES_HASHED_LINK_KEY is missing on the Sonoff

Adminiuga commented 3 years ago

Hrm, I'm out of ideas

Adminiuga commented 3 years ago

@walthowd do you see the becons send by the coordinator in response to beacon request? Here's a screenshot of a becon response, without network being opened for joining. If you don't get beacon responses, then I believe the problem is with the firmware, as zigpy does not control sending of the beacon replies

Adminiuga commented 3 years ago

and second question: when you open network for joining, do you see ITEAD sending out the ZDO broadcast? I don't have an ITEAD router, but SM-011 with EFR32MG21 chip, running grobasoz's firmware replies to beacon requests and once the reply is sent, the device immediatly sends the association request. If itead does not reply to beacons, then the device would never try to join.

xsp1989 commented 3 years ago

@walthowd Does the firmware work properly? When you connect to Terminal, then press the RST button. If you use software flow control firmware, you will see the following information on the serial port： 11 1A C1 02 02 9B 7B 7E or 1A C1 02 02 9B 7B 7E (no flow control)

Adminiuga commented 3 years ago

this looks like an ASH frame, so seems normal. It is RTSACK frame

check https://www.silabs.com/documents/public/user-guides/ug101-uart-gateway-protocol-reference.pdf

MattWestb commented 3 years ago

Can some one with one volt meter checking if pin 14 (PAVDD = Power for the Power Amplifier) is having around 3.3V ?

I have making the coil with blue that shall getting VDD from the 3.3V rail to the PIN14 and with red the PIN14 side that shall having around 3.3V. SonOffUSB01_LI

The coil and the 2 capacitors is on the lower right corner in the schematics.

If the chip is not getting enough power on PIN14 then it can receiving OK but the RF Amplifier is not working so it think its transmitting but no RF is sent to the antenna then the PA is not working (in first gen its the problem with using the internal DC-DC with high power chips that was making on large mess on the software side).

It can being one reason way the hardware is receiving but cant transmitting and with the experience of Sonoff ZBB . . .

jds11111 commented 3 years ago

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

MattWestb commented 3 years ago

Thanks @jds11111 so then the PA is having OK voltage for working so it shall not being the problem :-(((

So still one open question what is doing all the strange problems.

walthowd commented 3 years ago

@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

Adminiuga commented 3 years ago

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?

MattWestb commented 3 years ago

Shall being . . https://github.com/zigpy/zigpy/discussions/635#discussioncomment-620777

Adminiuga commented 3 years ago

So what is it? I don't know how to read the that marking. Is it a 33.4MHz oscillator? Cause most likely by default simplicity studio assumes 40MHz crystal and specifying wrong freq in CMU hal config would make it tune to the wrong channel. Did it come with firmware from Itead or was it upgraded?

MattWestb commented 3 years ago

Sorry is was not minted as one quest only as reference. From EFR32MG21 manual:

3.4.2 Internal and External Oscillators The EFR32MG21 supports two crystal oscillators and fully integrates five RC oscillators, listed below. • A high frequency crystal oscillator (HFXO) with integrated load capacitors, tunable in small steps, provides a precise timing reference for the MCU and RF synthesizer. The HFXO provides excellent RF clocking performance using a 38.4 MHz crystal. The HFXO can also support an external clock source such as a TCXO for applications that require an extremely accurate clock frequency over temperature.

So shall being one 38.4 MHz and its the master clock for the RF part (that Sonoff having problem with).

MattWestb commented 3 years ago

The photo with the X-tall is not from my device its from found photos online !!

Adminiuga commented 3 years ago

Yeah, but what's nthe actual oscillator installed on the board?

Adminiuga commented 3 years ago

@lonelyseraphim did you get any reply from Itead support?

walthowd commented 3 years ago

My crystal has 38.4 T 0L printed on it.

Adminiuga commented 3 years ago

Ok, so it is the standard 38.4MHz then. I think on some other pictures it looked like 33.4

lonelyseraphim commented 3 years ago

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

Adminiuga commented 3 years ago

@walthowd if you do bellows scan to scan for networks, while Itead dongle is running, do you see that network on any channel?

walthowd commented 3 years ago

@Adminiuga No, I don't see anything other then my production network on channel 15:

root@2a54f1d491a9:/tmp/silabs# bellows scan
Scanning channels 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 255, -45]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 132, -79]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 255, -70]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 198, -79]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 255, -74]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 244, -76]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 253, -73]
[EmberZigbeeNetwork(channel=15, panId=0xe278, extendedPanId=a9:e3:59:fc:d8:59:ea:a8, allowingJoin=<Bool.false: 0>, stackProfile=2, nwkUpdateId=2), 255, -68]

I tried doing some energy scans as well, but I'm in enough of a RF noisy environment and the test network on channel 25 is so quiet that I can't definitively state anything.

Adminiuga commented 3 years ago

But when you start HA, in the logs you do see that it formed network on channel 25? It should print a line with the ncurrent net info

walthowd commented 3 years ago

Yes, reports channel 25.

2021-04-19 16:24:29 DEBUG (MainThread) [bellows.zigbee.application] APS_UNICAST_MESSAGE_COUNT is set to 10
2021-04-19 16:24:29 DEBUG (MainThread) [bellows.zigbee.application] Ezsp adding endpoint: [<EzspStatus.SUCCESS: 0>]
2021-04-19 16:24:29 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: 
2021-04-19 16:24:29 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: 
2021-04-19 16:24:29 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.9.0 build 405
2021-04-19 16:24:29 INFO (MainThread) [bellows.zigbee.application] Node type: EmberNodeType.COORDINATOR, Network parameters: EmberNetworkParameters(extendedPanId=24:1a:32:fc:39:6f:d9:d0, panId=0xd3aa, radioTxPower=8, radioChannel=25, joinMethod=<EmberJoinMethod.USE_MAC_ASSOCIATION: 0>, nwkManagerId=0x0000, nwkUpdateId=0, channels=<Channels.ALL_CHANNELS: 134215680>)
2021-04-19 16:24:30 DEBUG (MainThread) [bellows.zigbee.application] EZSP nwk=0x0000, IEEE=84:71:27:ff:fe:c9:a6:60

MattWestb commented 3 years ago

@walthowd have you measuring the PAVDD on pin14 ? If you is having 3.3V i saying the PA is broken in the chip for 95% :-(((

I have not looking if the PA is having separate GND that can having bad connection but i think all GND is common for the chip.

Adminiuga commented 3 years ago

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.

walthowd commented 3 years ago

Yes, no Link Status broadcasts at all on channel 25 -- I also sniffed on channel 23, 24 and 26 -- nothing.

Adminiuga commented 3 years ago

Well, too bad there's no PTI on this dongle :)

In the debug log, can you confirm you are getting stackStatusHandler frame with b'90' shortly after the networkInit()

2021-04-19 17:06:34 DEBUG (MainThread) [bellows.ezsp.protocol] Send command networkInit: ()
2021-04-19 17:06:34 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'775421a9432aa0b97e'
2021-04-19 17:06:34 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'7054a5a9432a15fcec7e'
2021-04-19 17:06:34 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e'
2021-04-19 17:06:34 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 23 (networkInit) received: b'00'
2021-04-19 17:06:34 DEBUG (MainThread) [bellows.ezsp.protocol] Send command getNetworkParameters: ()
2021-04-19 17:06:34 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'0054b1a94d2a856d697e'
2021-04-19 17:06:34 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8160597e'
2021-04-19 17:06:34 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 25 (stackStatusHandler) received: b'90'

That would indicate the network is up. If after that you don't get link status messages, then something is very wrong with the dongle.

MattWestb commented 3 years ago

RFVSS PIN 11 Radio Ground = the ground for the PA but its looks going under the chip to the common ground plane so shall being very well grounded.

I think one return to sender is the only way getting on working device :-((

walthowd commented 3 years ago

Yes, receiving b'90' frame:

home-assistant.log:2021-04-19 16:24:29 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 23 (networkInit) received: b'00'
home-assistant.log:2021-04-19 16:24:29 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 25 (stackStatusHandler) received: b'90'

Adminiuga commented 3 years ago

Well, from the host side it behaves as it should, but nothing on RF side. Probably bad hardware, assuming the posted firmware was nominally tested.

lonelyseraphim commented 3 years ago

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

lonelyseraphim commented 3 years ago

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.

kewvention commented 3 years ago

weird right. i've only used HA on docker without issue, but never tried it directly on the pi or anything.

Adminiuga commented 3 years ago

@lonelyseraphim interesting. Pi4 has some weirdness about their USB ports. Maybe some usb incompatibility issues? Have you tried different ports on Pi4? Maybe try a powered usb hub?

MattWestb commented 3 years ago

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

lonelyseraphim commented 3 years ago

@lonelyseraphim interesting. Pi4 has some weirdness about their USB ports. Maybe some usb incompatibility issues? Have you tried different ports on Pi4? Maybe try a powered usb hub?

I have tried various ports BUT I also have an SSD connected (unpowered) so the RPi is also powering that. Do you suspect it cannot power both the SSD and dongle?

home-assistant / core