CC2530: Coordinator not response of IAS Zone Enroll request

Hi Ryan,

I working for coordinator device to support all zigbee sensor device.
Please suggest coordinator config, if I am missing.

Hi sanjay,

You should be doing a diff compare between the working and non-working vendor switch sniffer logs to discover the issue. Can you confirm that the non-working switch performs as intended with a different ZC? This would be another interesting sniffer log to compare against.

Regards,
Ryan

Do you try to do binding to IAS zone cluster to make context switch do IAS Zone report?

Hi Chen/Ryan,

                   Yes, I am binding device for cluster ID 0x0001 (Power Configuration Report), device reporting power configuration data.

                   I have attached attached working and not working sniffer log.

                  Please check, late me know if find any issue.

context_switch_sniffer_log.zip

Regards,

 Sanjay

Do you do binding to IAZ Zone cluster?

No, Only binding cluster 0x0001

Hi,
I check Simple Descriptor response packet, in working context switch 0x0001 cluster is not there, but in another context switch it there.
let me know any issue binding power cluster ?

I suggest you to do binding to IAS zone cluster to make context switch do IAS Zone report.

Hi Chen,

Cluster 0x500 is not reporting cluster.
I remove binding cluster 0x0001, still same issue.

The standard way is to do enroll process successfully to IAS zone device and the device would send IAS Zone report. However, do binding to IAS zone cluster should do the trick too.

Hi chen,

                One difference found if compare working log and not working log.

               In Transport key exchange "Security Enabled is [0x0] No"

               Can you suggest how to enable "Security Enabled [0x1] yes"

Can you attach not working log?

Cheers!

Hi Chen,

I have one question, for final release which option choose
1. ZNP with SBL
2. ZNP without SBL

I would suggest you to use ZNP with SBL so you will be able to update ZNP from SBL if you need it.

Thanks chen

Are both of your coordinator and end device based on Z-Stack 3.0.1?

Coordinator is Z-stack 3.0.1 but end device ZHA 1.2.2

I suppose you have to set bdbTrustCenterRequireKeyExchange to FALSE on Z-stack 3.0.1 coordinator to allow ZHA 1.2 devices to join.

Alredy set #define BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE FALSE

Which Coordinator example in Z-stack 3.0.1 and end device example in ZHA 1.2.2 do you test this? Do you revise any other source code?

Issue with z-stack 3.0.1 coordinator and end device 1.2.2
if z-stack Z-Stack Home 1.2.2a.44539 and end device 1.2 working fine
Let me now how to solve issue with z-stack 3.0.1

I still suspect you don't setup bdbTrustCenterRequireKeyExchange to false correctly. I would suggest you to check this again to rebuild coordinator and erase chip to test it again.

in znp.cng all three device type required required ? -DZSTACK_DEVICE_BUILD="(DEVICE_BUILD_COORDINATOR | DEVICE_BUILD_ROUTER | DEVICE_BUILD_ENDDEVICE)"

or

-DZSTACK_DEVICE_BUILD="(DEVICE_BUILD_COORDINATOR | DEVICE_BUILD_ROUTER)"

for coordinator

Cross check, getting same result

if set BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE TRUE then device not join., leave after join.
I checked bdbTrustCenterRequireKeyExchange value, and value is
.bdbTrustCenterRequireKeyExchange = BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANG

Both work for coordinator.

Can you device join after you set BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE to FALSE?

I using with BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE = FALSE

Run out of idea. Ryan Brown1 Do you have any suggestion?