ZHA Zigbee Tested Devices...Please add your device results

kbruns · August 28, 2020, 5:48pm

Yeah, there’s a problem with zigpy-cc . you could try switching to https://github.com/zha-ng/zigpy-znp but currently no user friendly way to do the switch.

I copied zha into the custom_components folder, patched it, and restarted HA to check if Zigbee still works.

Then I changed “radio_type”: “ti_cc” in core.config_entries to “radio_type”: “nzp” and restarted HA.

After restarting HA all Zigbee devices were offline.
I also tried rebooting the whole Raspi with or without unplugging the Zigbee USB Stick, same result.

After changing “radio_type” back to “ti_cc”, the Zigbee devices were online again.

I guess I need a different stick.

Quatuor · August 28, 2020, 6:37pm

Should be znp – lowercase. not sure if you did typo here or in the config_entries file. enable debug logging to see more post issue in znp repo

kbruns · August 28, 2020, 7:47pm

Yes, it was a typo.

My report before: “all devices are online” was wrong.
Devices show as online, but I can’t see any Zigbee status updates anymore nor can I set switches (“ti_cc” and “znp”).
Even after restoring a snapshot (made just before znp) an deleting the custom_components/zha folder.

I need to get my sensors online again before I can test further.

Quatuor · August 28, 2020, 8:07pm

I guess YMMV. I have a three gang Tuya wall switch, and basic functions work fine, but:

no group support, having each endpoint in a different group or same
no on_off client cluster, so I can’t bind it directly to other Zigbee lights
But also based on signatures submitted for Tuya devices in zha-device-handlers seems like at least some of their devices not following any standards.

henry8866 · August 31, 2020, 5:30pm

ZHA with Conbee II usb stick, running HA container.

I have sylvania zigbee bulbs in the network. I plugged one bulb at a recessed ceiling housing, but it often doesn’t work after a while, showing unavailable from the UI. The bulb itself works as I tested it in other power outlet. Tested with another bulbs and resulted same. Is this because the housing actually affect zigbee signal? The spot is much closer to the conbee ii stick. Also I noticed the bulb was hot when I took it out. Does anyone have similar experience and is there a way to fix this?

thanks.

JorgeSPNeto · September 1, 2020, 10:46am

Hi.
I’m having some instability with the ZigBee network using the Sonoff bridge with tasmota-zbbridge.bin](http://ota.tasmota.com/tasmota/release/tasmota-zbbridge.bin).
I have about 15 Zemismart switches here, the first 5 were very easy to pair, then a great instability started and the devices did not synchronize with the bridge and I don’t know why.
Here is the Logs

0xf38a:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=121 command_id=1>
[0xf38a:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0xf38a:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0xf38a:1:0x0019] No OTA image is available
[0x0edf:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=89 command_id=1>
[0x0edf:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0x0edf:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0x0edf:1:0x0019] No OTA image is available
Device 0x5479 (00:15:8d:00:04:62:6a:50) left the network

And here

Here is the Log Device 0x5479 (SECRET) joined the network Skip initialization for existing device 00:15:8d:00:04:62:6a:50 Device 0x5479 (SECRET) joined the network Skip initialization for existing device [00:15]:8d:00:04:62:6a:50 [0x5479] Cancelling old group rescan [0x5479:zdo] ZDO request ZDOCmd.Device_annce: [0x5479, SECRET, 142] [0x5479:11:0x0004] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=173 command_id=2> [0x5479:11:0x0004] ZCL request 0x0002: [16, []] [0x5479:11:0x0004] No handler for cluster command 2 [0x5479:11:0x0004] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=175 command_id=2> [0x5479:zdo] ZDO request ZDOCmd.Node_Desc_req: [0x0000] [0x5479:zdo] Unsupported ZDO request:ZDOCmd.Node_Desc_req

Quatuor · September 1, 2020, 12:32pm

add to configuration.yaml the following:

zha:
  zigpy_config:
    ezsp_config:
      CONFIG_KEY_TABLE_SIZE: 12

restart HA and try pairing again

PS: for anyone else trying this remedy in other situation: this only works on later versions of EZSP firmwares, like one running on sonoff

JorgeSPNeto · September 1, 2020, 1:31pm

Thank you very much for the quick response. I made the change and tested it on a switch and it apparently solved the problem. I will test now on all switches in the house. As soon as I have feedback, I’ll post it here. Thank you very much in advance.

Quatuor · September 1, 2020, 4:18pm

this should be fixed in the next HA version. For now it is limited by the KEY table size which is limited on EZSP firmware.

JorgeSPNeto · September 1, 2020, 7:44pm

I would like to thank you again, I managed to synchronize all the switches.

skywise · September 5, 2020, 12:58am

I’m trying to setup zha with ZBbridge and having trouble getting devices to join.
I followed the howto at https://www.digiblur.com/2020/07/how-to-use-sonoff-zigbee-bridge-with.html
The Ota I used is ncp-uart-sw_6.7.6_115200.ota
tamota version is 8.4.0
HA version is 114 (current)
I’m trying an Ikea E1743 on/off switch and here’s what I get…

2020-09-04 19:46:40 DEBUG (MainThread) [bellows.ezsp] Application frame 34 (permitJoining) received: b'00'
2020-09-04 19:46:47 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2020-09-04 19:46:47 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'740521a9512ab42b7e'
2020-09-04 19:46:48 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'4005a1a9512a403e7e'
2020-09-04 19:46:48 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8520dd7e'
2020-09-04 19:46:48 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'5005b1a9772a17b394d4c24cdbab6d1e285a23cc537e'
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8610be7e'
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.ezsp] Application frame 35 (childJoinHandler) received: b'0201cd40886971feff57b41404'
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.zigbee.application] Received childJoinHandler frame with [2, <Bool.true: 1>, 0x40cd, 14:b4:57:ff:fe:71:69:88, <EmberNodeType.SLEEPY_END_DEVICE: 4>]
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'6005b1a9702ad8f2d1fd3bdb5502265d9d4e27abe79c7e'
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'87009f7e'
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.ezsp] Application frame 36 (trustCenterJoinHandler) received: b'cd40886971feff57b41401000000'
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.zigbee.application] Received trustCenterJoinHandler frame with [0x40cd, 14:b4:57:ff:fe:71:69:88, <EmberDeviceUpdate.STANDARD_SECURITY_UNSECURED_JOIN: 1>, <EmberJoinDecision.USE_PRECONFIGURED_KEY: 0>, 0x0000]
2020-09-04 19:46:56 INFO (MainThread) [zigpy.application] Device 0x40cd (14:b4:57:ff:fe:71:69:88) joined the network
2020-09-04 19:46:56 INFO (MainThread) [zigpy.device] [0x40cd] Requesting 'Node Descriptor'
2020-09-04 19:46:56 DEBUG (MainThread) [zigpy.util] Tries remaining: 2
2020-09-04 19:46:56 DEBUG (MainThread) [zigpy.device] [0x40cd] Extending timeout for 0x03 request
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.zigbee.application] Extending timeout for 14:b4:57:ff:fe:71:69:88/0x40cd
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.ezsp] Send command setExtendedTimeout: (14:b4:57:ff:fe:71:69:88, True)
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'070a21a92a2a9ddb286ab5721e41939be47e'
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'710aa1a92a2a9b487e'
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e'
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.ezsp] Application frame 126 (setExtendedTimeout) received: b''
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.ezsp] Send command sendUnicast: (<EmberOutgoingMessageType.OUTGOING_DIRECT: 0>, 0x40cd, <EmberApsFrame profileId=0 clusterId=2 sourceEndpoint=0 destinationEndpoint=0 options=320 groupId=0 sequence=3>, 4, b'\x03\xcd@')
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'100b21a9602a157f19944a27aa5592099d4e27a8e9cd6446bd223b7e'
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'020ba1a9602a157d984e7e'
2020-09-04 19:46:56 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8160597e'
2020-09-04 19:46:56 DEBUG (MainThread) [bellows.ezsp] Application frame 52 (sendUnicast) received: b'00cf'
2020-09-04 19:46:58 DEBUG (MainThread) [bellows.ezsp] Send command nop: ()
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'210821a9512aa6c47e'
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'1308a1a9512adf307e'
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'82503a7e'
2020-09-04 19:46:58 DEBUG (MainThread) [bellows.ezsp] Application frame 5 (nop) received: b''
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'2308b1a9772a17b394d4c24cdbab6d1e285a23de397e'
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'83401b7e'
2020-09-04 19:46:58 DEBUG (MainThread) [bellows.ezsp] Application frame 35 (childJoinHandler) received: b'0201cd40886971feff57b41404'
2020-09-04 19:46:58 DEBUG (MainThread) [bellows.zigbee.application] Received childJoinHandler frame with [2, <Bool.true: 1>, 0x40cd, 14:b4:57:ff:fe:71:69:88, <EmberNodeType.SLEEPY_END_DEVICE: 4>]
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'3308b1a9702ad8f2d1fd3bdb5502265d9d4e27ab69497e'
2020-09-04 19:46:58 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8430fc7e'
2020-09-04 19:46:58 DEBUG (MainThread) [bellows.ezsp] Application frame 36 (trustCenterJoinHandler) received: b'cd40886971feff57b41401000000'
2020-09-04 19:46:58 DEBUG (MainThread) [bellows.zigbee.application] Received trustCenterJoinHandler frame with [0x40cd, 14:b4:57:ff:fe:71:69:88, <EmberDeviceUpdate.STANDARD_SECURITY_UNSECURED_JOIN: 1>, <EmberJoinDecision.USE_PRECONFIGURED_KEY: 0>, 0x0000]
2020-09-04 19:46:58 INFO (MainThread) [zigpy.application] Device 0x40cd (14:b4:57:ff:fe:71:69:88) joined the network
2020-09-04 19:46:58 DEBUG (MainThread) [zigpy.application] Skip initialization for existing device 14:b4:57:ff:fe:71:69:88
2020-09-04 19:47:00 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'4308b1a9772a17b394d4c24cdbab6d1e285a237ff77e'

I’m trying a Xiaomi button as well and get much the same thing.

[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]
Device 0xf135 (00:15:8d:00:02:10:c1:72) joined the network
[0xf135] Requesting 'Node Descriptor'
Tries remaining: 2
[0xf135] Extending timeout for 0x0f request
Device 0xf135 (00:15:8d:00:02:10:c1:72) joined the network
Skip initialization for existing device 00:15:8d:00:02:10:c1:72
[0xf135:zdo] ZDO request ZDOCmd.Device_annce: [0xf135, 00:15:8d:00:02:10:c1:72, 128]

Any ideas what’s going on? I’m pairing very close to the ZBbridge (a couple of inches away)

Quatuor · September 5, 2020, 2:57am

seems similar to https://github.com/zigpy/bellows/issues/329

skywise · September 5, 2020, 12:08pm

Seems like it.
Ok, a bit of patience and a solution will come in the next update or two.
Thanks!

JorgeSPNeto · September 5, 2020, 7:37pm

I’m having a problem with a three-way switch that recognized only one, I deleted the device, put it back in pairing mode, and now it is no longer synchronizing with the Zigbee bridge

It seems like every device that I delete I can’t pair again with the zigbee bridge
Logs
[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
[0x61f5] Requesting ‘Node Descriptor’
Tries remaining: 2
[0x61f5] Extending timeout for 0x5d request
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
[0x61f5] Delivery error for seq # 0x5d, on endpoint id 0 cluster 0x0002: message send failure
Tries remaining: 1
[0x61f5] Extending timeout for 0x5f request
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
[0xc161:11:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=200 command_id=1>
[0xc161:11:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0xc161:11:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW01LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0xc161:11:0x0019] No OTA image is available
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
[0x4eaa:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=112 command_id=1>
[0x4eaa:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0x4eaa:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0x4eaa:1:0x0019] No OTA image is available
[0x61f5] Delivery error for seq # 0x5f, on endpoint id 0 cluster 0x0002: message send failure
[0x61f5] Requesting Node Descriptor failed
[0x61f5] Discovering endpoints
Tries remaining: 3
[0x61f5] Extending timeout for 0x63 request
[0x61f5] Delivery error for seq # 0x63, on endpoint id 0 cluster 0x0005: message send failure
Device 0x61f5 (00:15:8d:00:04:77:4e:89) joined the network
Skip initialization for existing device 00:15:8d:00:04:77:4e:89
Tries remaining: 2
[0x61f5] Extending timeout for 0x65 request
[0x61f5] Delivery error for seq # 0x65, on endpoint id 0 cluster 0x0005: message send failure
Tries remaining: 1
[0x61f5] Extending timeout for 0x67 request
[0x61f5] Delivery error for seq # 0x67, on endpoint id 0 cluster 0x0005: message send failure
Failed ZDO request during device initialization
[0xc161:11:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=6 command_id=1>
[0xc161:11:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0xc161:11:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW01LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0xc161:11:0x0019] No OTA image is available
[0x4eaa:1:0x0019] ZCL deserialize: <ZCLHeader frame_control= manufacturer=None tsn=174 command_id=1>
[0x4eaa:1:0x0019] ZCL request 0x0001: [0, 4478, 0, 1, None]
[0x4eaa:1:0x0019] OTA query_next_image handler for ‘FeiBit FNB56-ZSW03LX2.0’: field_control=0, manufacture_id=4478, image_type=0, current_file_version=1, hardware_version=None
[0x4eaa:1:0x0019] No OTA image is available

Quatuor · September 5, 2020, 8:02pm

yeah, currently if you delete the ZB3 device, it leaves a TC key on the coordinator which prevents device from joining correctly. Fix should be in the beta.

JorgeSPNeto · September 5, 2020, 9:06pm

I understand, it’s good to know that they are already solving this. is there any prediction of when the next version will come out ??

Quatuor · September 5, 2020, 9:28pm

beta is Monday, release should be wed next week

JorgeSPNeto · September 6, 2020, 2:10am

very good, how do i sign up to be a beta tester?
I will wait for this update to transfer the devices from Smartthings to Home Asssistant

JorgeSPNeto · September 8, 2020, 5:04pm

just to find out if the beta came out yesterday? if so how do i update

Quatuor · September 8, 2020, 5:25pm

Depends how are you running HA. if supervised – just join the beta channel. May need to join using CLI like ha supervisor options --channel beta