search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
74.04k stars 31.07k forks source link

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

Closed lonelyseraphim closed 3 years ago

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

dmulcahey commented 3 years ago

Please try the firmware linked here https://github.com/home-assistant/core/issues/43969#issuecomment-811840742

walthowd commented 3 years ago

Can confirm same issue. Running latest dev HA instance, Itead/Sonoff dongle tried with 6.7.8 and 6.7.9 firmware from https://github.com/xsp1989/zigbeeFirmware

Adminiuga commented 3 years ago

Does it work with other EZSP radios?

lonelyseraphim commented 3 years ago

Can confirm same issue. Running latest dev HA instance, Itead/Sonoff dongle tried with 6.7.8 and 6.7.9 firmware from https://github.com/xsp1989/zigbeeFirmware

Is this what you use to upgrade the firmware? EZSP Firmware Update Utility? I should be able to do this within HA using the SSH/Web Terminal correct?

walthowd commented 3 years ago

@lonelyseraphim You need exclusive access to the stick, so wouldn't work with HA with SSH/terminal add/on unless you have ZHA disabled.

You can upgrade fw on any system though, if you have another linux system around you can use the elelabs tool or my docker container here- https://github.com/walthowd/husbzb-firmware -- You'll have to put the 6.7.9 firmware in your bind mount to access it from the container.

Doesn't seem like that 6.7.9 does fix the issue though, but YMMV

walthowd commented 3 years ago

@Adminiuga Join logs (looks like it's just not receiving anything) when trying to join Aqara sensor and Ecosmart light bulb:

https://paste.ubuntu.com/p/s2tFbNQQnV/

But what's weird is if I use https://github.com/zsmartsystems/com.zsmartsystems.zigbee.sniffer to sniff using the adapter, it can see all radio frames on my production network (channel 15) and everything at reasonable LQI/RSSI values:

https://paste.ubuntu.com/p/8GvFk9pwCy/

Adminiuga commented 3 years ago

I can't really read that log on mobile. But are there: Beacon requests? Beacon responses?

What's strange from the original log, is that the outbound broadcast has failed. Dunno if that is supposed to happen

walthowd commented 3 years ago

Yes, the second log is just all normal production traffic. ZCL on/offs, route requests, etc. I can share the keys and PCAP file if it would be helpful. Spot checking LQI and RSSI seems to match up with what I would suspect -- I would assume frequency mismatch would lead to attenuation and artificially low numbers, but really no idea what root cause is at this point.

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)

Adminiuga commented 3 years ago

Is this your production network? Do you have any other ezsp stick to try?

Adminiuga commented 3 years ago

Just trying to figure out if it is items specific

MattWestb commented 3 years ago

If the radio is miss tuned i think you can "hearing" devices that is offset in the same direction (plus X or minus X) but is loosing devices that is miss tuned in the other direction.

Have you trying the Garys firmware that is without the patched CTun that Sonoff have putting in there firmware ?

MattWestb commented 3 years ago

Do you have one more EZSP for sniffing if the NCP is sending / broadcasting one permit joining "in the air" and also parent contentment then its (re)joining the network ?

Can EZSP getting on lock in the firmware if being shunted down and being in premising mode and saving it in NVRAM ?

Deleting all key tokens in the NVR if some is doing strange things (tuya ZBGW is doing strange things then going from factory 6.5.0 to newer versions).

Leaving and forming on new network for deleting old settings.

lonelyseraphim commented 3 years ago

Unfortunately I do not have a second Zigbee stick :(

jactora commented 3 years ago

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.

Adminiuga commented 3 years ago

@jactora what radio and version are you using? Post your debug logs

dmulcahey commented 3 years ago

I suggest folks contact ITEAD. It sounds like these sticks may have a hardware issue that they are attempting to fix with firmware (seemingly unsuccessfully atm)

MattWestb commented 3 years ago

I agree with David. Little strange that the sniffing part is working so the radio cant being completely messed up but looks being enough for making stable communicating with devices.

Wold being interesting sniffing with one WTSK so can analyzing the packages after the radio and the first processor and see if its low LQI and if getting CRC problems but i think no devs or user with WSTK dont have the device.

lonelyseraphim commented 3 years ago

I submitted a new support ticket to ITEAD with links to the various threads and this Github issue. Will reply back here with anything they send back!

JayRama commented 3 years ago

@lonelyseraphim Any response yet? I also picked up a couple of these and have the same result.

Adminiuga commented 3 years ago

Can't reproduce with non Itead radio. Joined aqara temp sensor and Ikea two button remotes to Elelabs raspbee shield or EByte module running 6.7.8.0 or 6.8.2.0

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

https://github.com/Koenkk/zigbee-herdsman/issues/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.

MattWestb commented 3 years ago

Then sniffing is working is the NCP communicating with the host system. If the USB chip was doing the problems then the sniffing shall having the same problem.

lonelyseraphim commented 3 years ago

@lonelyseraphim Any response yet? I also picked up a couple of these and have the same result.

No response yet :(

jds11111 commented 3 years ago

I have a stick just sitting around doing nothing, and am willing to test, if that would help out (use Ha).

xsp1989 commented 3 years ago

Please use the following firmware test: https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle/ncp-uart-nsw_679_115200.gbl

image

Homessistant Info: image

PS:In the file name nsw=no flow control sw=software flow control

lonelyseraphim commented 3 years ago

@xsp1989 When using that firmware and the update utility do I use the FLASH command? It does not appear that update command supports anything but the v6 or v8 firmware.

python3 Elelabs_EzspFwUtility.py flash -f ncp-uart-nsw_679_115200.gbl -p /dev/ttyusb0

MattWestb commented 3 years ago

EZSP 6.7.0.0 and higher is protocol version 8 all before is 7 or lesser and can going down to version 4.

The problem can being software flow control or no.

walthowd commented 3 years ago

I've tried the 6.7.9 software flow control image previously and it still didn't work to "see" any beacons for joins under ZHA or zigbee2mqtt.

Does no software flow control even work with ZHA???

@lonelyseraphim -- If you want to test this image, do you have ncp-uart-nsw_679_115200.gbl in the data subfolder where the elelabs python script is?

Alternatively you can also use this docker utility (substituting /dev/ttyUSB1 for the actual path to your stick)

wget https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle/ncp-uart-nsw_679_115200.gbl
docker run --rm --device=/dev/ttyUSB1:/dev/ttyUSB1 -it -v `pwd`:/data walthowd/husbzb-firmware bash
./ncp.py flash -p /dev/ttyUSB1 -f /data/ncp-uart-nsw_679_115200.gbl
./ncp.py scan

However, I don't think it will work for any other then the "sw" flow control version images.

lonelyseraphim commented 3 years ago

I just updated to the 6.7.9 NSW firmware and for the first time I got this new "data flow control" drop down when I add the ZHA integration. Should I try hardware or software?

image

walthowd commented 3 years ago

@lonelyseraphim Have you setup ZHA at all yet? If no, you won't break anything in trying either, worst case you remove ZHA and retry adding it.

Hardware flow control was just added -- but I'm not clear if the nsw image posted is hardware flow control or NO flow control.

MattWestb commented 3 years ago

With software or no flow control is is normally no problems as long all is not going to fast on the line. Hardware flow control on one side and not on the other = no communication at all.

If trying with SW you is seeing in the log if you is having problem sending / receiving and getting time outs or ZHA is not starting at all.

MattWestb commented 3 years ago

nsw = no (software (and hardware)) flow control.

Adminiuga commented 3 years ago

Use software flow control for zha setup. I'm not positive hw flow control is connected on Itead.

lonelyseraphim commented 3 years ago

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.

walthowd commented 3 years ago

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

MattWestb commented 3 years ago

If not getting the 6.7.9.0 working its possible using the 6.7.8.0 that Gary was cooking for Sonoff ZBB then its the same pin outs but dont have the RF tuning patch (and shall not working so god as the 6.7.9.0 with RF tuning patch) then both is un signe.

Hedda commented 3 years ago

When using that firmware and the update utility do I use the FLASH command?

Try flashing with husbzb-firmware updater image as @walthowd suggested -> https://github.com/walthowd/husbzb-firmware

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

It is important to understand that if a Zigbee device is not brand new then you will proactically always have to first manually reset each device to its factory default before you will be able pair to a other Zigbee coordinator that it has never been paired to before.

Still, even so, pairing may require multiple attempts and you may need to try pairing again and again (even after resetting them).

Also, note and remember that resetting devices to factory default settings can be different for each device model and manufacturer and there are also several different methods for factory resetting each type of device.

Recommend lookup each device in Zigbee2mqtt + Blakadder lists for some tips on both resetting to default as well as pairing tricks:

https://www.zigbee2mqtt.io/information/supported_devices.html

https://zigbee.blakadder.com/](https://zigbee.blakadder.com/

Example: Simply removing/deleting Hue devices from a Philips Hue Bridge does not actually reset the device to their defaults. See:

https://www.home-assistant.io/integrations/zha/#add-philips-hue-bulbs-that-have-previously-been-added-to-another-bridge

Another example are Xiaomi and Aqara devices which can be tricky to reset and pair so tip is to read and follow this Hubitat guide:

https://community.hubitat.com/t/xiaomi-aqara-devices-pairing-keeping-them-connected/623

Devices that follow standard Zigbee specifications device should be paired in ZHA after you have done a factory reset of the device.

kewvention commented 3 years ago

i flashed the recommended fw a few days ago and then the device started to find my zigbee devices.

I am using home-assistant on docker and the zigbee stick is on an RPI3. I'm sharing the device via usbip if anything. launching the container i've set the device by serialID mapped to ttyUSB0 into the container. when adding the device, i selected /dev/ttyUSB0 and the baudraude of 115200 and software flow.

I then paired a bunch of door and motion sensors from my xiaomi aqara sensors (had them for 4yrs). it took several tries to pair them, aka having to keep resetting them but eventually, they were all found.

also have some hue bulbs which were paired to a hub. I attempted to use hue-thief but that did not work. in the end, I bought the new hue dimmer switch and was able to reset the bulbs. that took a few attempts but they also got found. since the dimmer switch is the new one, this is what i found on how to reset it. https://mobile.twitter.com/tweethue/status/1365225032918716418

image

i also paired the sonoff snzb-01 wireless button without issue.

dmulcahey commented 3 years ago

For anyone wondering what they did in this firmware this is worth a read: https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2019/03/18/hfxo_capacitor_bank-7uRt

based on the firmware release notes they set CTUNE to 128 I believe. This supports the notion that things aren’t quite right OOTB with radio frequency on the stick.

lonelyseraphim commented 3 years ago

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

MattWestb commented 3 years ago

If you is baying one Silabs module its calibrated (In DI = Device Information = in protected hardware inf aria with the MAC address and so on) from the factory. If you is baying EFR32MG2X chip from Silabs they is not calibrated (in ID) and shall being done in the factory processes if reading Silabs manufacturing papers (in DI or with manufacturing token).

So if you have not doing that .... Is one work around patching the firmware and hoping the manufacturing process is god so your patch is working for all your manufactured devices.

Wot i have seen of the Sonoff ZBB and its SM-011 module its the quality of the manufacturing process not wot normal user wont to have from it (Com from the ESP to EZSP broken, unstable devices and not miss tuned hardware in the RF stage compared with Silabs reference design for 20 dBm devices).

I hope tuya is doing it right and calibrating there EFR32MG2x in the production or we is getting more problems with sleeping end devices is having problem having some devices as there parents and draining batteries (some user have getting it on tuya ZBGW but its needs more digging for potting it in stones).

So tube013 have making all right going with one real Silabs module.

MattWestb commented 3 years ago

If interested of the process: AN700.1: Manufacturing Test Guidelines for the EFR32.

kewvention commented 3 years ago

@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

lonelyseraphim commented 3 years ago

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

kewvention commented 3 years ago

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

no problem. it took me 3-4 tries to get the hue's to connect. and i kept them very close. whats interesting is that for testing sake, i kept the pi in the corner of the basement (it'll eventually goto the 1st floor) and so far everything is still working upto the 2nd floor.

lonelyseraphim commented 3 years ago

No dice using two new ecosmart bulbs (not previously paired). I have them sitting right on top of the PI within a few inches of the stick. Is there any way I can actually see if the stick is doing anything? Maybe the stick itself is not working?

lonelyseraphim commented 3 years ago

I also noticed that when I run search it does not always get past this:

[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]

Other times it shows:

[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`

MattWestb commented 3 years ago

Hardware fault is very likely only that @walthowd was possible using the sniffing is saying its not complete dead.

Im not sure the EZSP is initiating every time one ZDO command is executed (i think its one happening after hardware resets)).

kewvention commented 3 years ago

I also noticed that when I run search it does not always get past this:

[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]

Other times it shows:

[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`

ive had that happen. 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. i did get more success when it had the "completed initilization" step. could try just unplugging the device, replug it back it and see if that helps.

i just randomly pulled this from the logs: 2021-04-13 18:09:20 DEBUG (MainThread) [zigpy.endpoint] [0xbea0:11] Manufacturer: Philips 2021-04-13 18:09:20 DEBUG (MainThread) [zigpy.endpoint] [0xbea0:11] Model: LWB014 2021-04-13 18:09:20 INFO (MainThread) [zigpy.endpoint] [0xbea0:242] Discovering endpoint information 2021-04-13 18:09:20 DEBUG (MainThread) [zigpy.util] Tries remaining: 3 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xBEA0, EmberApsFrame(profileId=0, clusterId=4, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=101), 102, b'e\xa0\xbe\xf2') 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'376021a9602a1512e7944a21aa5592099d4e27ce8bca022b4334c41d7e' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'7460a1a9602a158bdf657e' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e' 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 52 (sendUnicast) received: b'0039' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'0460b1a96b2a1512e7944a21aa5592099d4e27928bce673d9f7e' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8160597e' 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 63 (messageSentHandler) received: b'00a0be0000040000004001000039660000' 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 48800, EmberApsFrame(profileId=0, clusterId=4, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=57), 102, <EmberStatus.SUCCESS: 0>, b''] 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'1460b1a9112a15b25990ca25aa1593499c21d85f4d709874eca363294272cd474aacde6f8edec7daf4d2e3707e' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'82503a7e' 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00000004800000400100006ffff4a0beffff116500a0be0cf2e0a1610000012100012100' 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=0, clusterId=32772, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=111), 255, -12, 0xbea0, 255, 255, b'e\x00\xa0\xbe\x0c\xf2\xe0\xa1a\x00\x00\x01!\x00\x01!\x00'] 2021-04-13 18:09:20 INFO (MainThread) [zigpy.endpoint] [0xbea0:242] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=242, profile=41440, device_type=97, device_version=0, input_clusters=[33], output_clusters=[33]) 2021-04-13 18:09:20 DEBUG (MainThread) [zigpy.quirks.registry] Checking quirks for Philips LWB014 (00:17:88:01:02:a1:97:53) 2021-04-13 18:09:20 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.philips.zlldimmablelight.ZLLDimmableLight'> 2021-04-13 18:09:20 DEBUG (MainThread) [zigpy.quirks.registry] Found custom device replacement for 00:17:88:01:02:a1:97:53: <class 'zhaquirks.philips.zlldimmablelight.ZLLDimmableLight'> 2021-04-13 18:09:20 DEBUG (MainThread) [homeassistant.components.zha.core.gateway] device - 0xBEA0:00:17:88:01:02:a1:97:53 entering async_device_initialized - is_new_join: True 2021-04-13 18:09:20 DEBUG (MainThread) [homeassistant.components.zha.core.gateway] device - 0xBEA0:00:17:88:01:02:a1:97:53 has joined the ZHA zigbee network 2021-04-13 18:09:20 DEBUG (MainThread) [homeassistant.components.zha.core.device] 0xBEA0: started configuration 2021-04-13 18:09:20 DEBUG (MainThread) [homeassistant.components.zha.core.channels.base] 0xBEA0:ZDO: 'async_configure' stage succeeded 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0xBEA0, EmberApsFrame(profileId=0, clusterId=33, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY|APS_OPTION_RETRY: 320>, groupId=0, sequence=103), 104, b"gS\x97\xa1\x02\x01\x88\x17\x00\x0b\x06\x00\x03\x80\xa6\xc9\xfe\xff'q\x84\x01") 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'426121a9602a1512e7944a04aa5592099d4e27cc85d800d86a67618874693facedcdddef29363924f2a3ed8d8a537e' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'2561a1a9602a1588dbd07e' 2021-04-13 18:09:20 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'83401b7e' 2021-04-13 18:09:20 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 52 (sendUnicast) received: b'003a'

Hedda commented 3 years ago

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

Note that always need to first stop all applications/integrations connected to the USB adapter, such as ZHA, before flashing it!

Recommend to then unplug and replug USB adapter after successfully flashing new firmware before starting apps/integrations.