CC2652R7: ZC coordinator sample application does not responding the IAS Zone Enrll Reqest for sleepy end device while it is working fine for Router device.

New folder (2).zip

please also have a look of attached log "IasZoneTestingWithTiSampleApp_zr_zone"  with the same code other application is working have a look at line number 310 and 329 New folder (3).zip

let me know if it is something to do with how many message an parent holds for sleepy end device. I have also debugged the code in both the case test with sleepy or Zr device code goes to same place but then the behaviour is different.

I have used zcl_ss.c module for implementing IAS zone feature, I can see in both case ( when this is ZR device and Sleepy end device ) "zclSS_ProcessInCmd_ZoneStatus_EnrollRequest" is called and then after method "zclSS_IAS_Send_ZoneStatusEnrollResponseCmd" also called. but on ubiqua logs I see different behaviour in case of sleepy end device, it does not produce response which in case of ZR it does. 

please let me know why this have different behaviour when device are different. 

Hi Jagdish,

Thank you for providing the detailed sniffer logs with packet numbers of interest provided.  What SIMPLELINK-CC13XX-CC26XX-SDK version are you referencing?  What IAS examples are you using for the ZC and ZR (CIE, warning device, or zone) respectively?  Have you tried testing with a ZED TI device instead of the third-party node?  What changes have you made to the ZC project's default settings?  With the ZR zone enrollment request, the ZC's response appears to be exceedingly delayed (occurring 1 minute and 17 seconds afterwards) which is not expected.  Does the same delay occur between the start of zclSS_ProcessInCmd_ZoneStatus_EnrollRequest" and reaching "zclSS_IAS_Send_ZoneStatusEnrollResponseCmd" in your ZC project for the ZED?  We should further determine what is causing the zone enrollment response delay.

Regards,
Ryan

Hi Ryan,

thanks for the response.

please find answers of your queries.

1. Sdk version is simplelink_cc13xx_cc26xx_sdk_6_20_00_29

2. a. For ZC I am developing application based on zcl thermostat.c but I have copied code as was in zc_cie for Zone implementation. i have interrogated zcl_ss.c file same as it is used in ZC_Cie sample application.

2. b. for Zr i am using test application, zr_zone sample application, this is present in "C:\ti\simplelink_cc13xx_cc26xx_sdk_6_20_00_29\examples\rtos\LP_CC2652R7\zstack"

3. I will test with TI ZED device and will share results.

4. I did not made much changes to ZC project's default settings, I can share project file or anything else if required let me know which file have default settings.

5. 1 minute and 17 seconds delay for Enroll response might be coming because of some identify query going in between but I don't know its the stack behaviour, I have tested it again and this delay reduced to 24 seconds.

6. zclSS_ProcessInCmd_ZoneStatus_EnrollRequest seems to be immediate as soon as frequentest appear on Ubiqua Protocol analyzer.

7.   zclSS_IAS_Send_ZoneStatusEnrollResponseCmd in case of end device it is not even sending the enrolment response that is the main issue, what causing delay can be a root cause of it.

let me know if you need any other information to fix this issue. 

regards 

Jagdish k

Do you add ZCL ACE cluster in InCluster and ZCL IAS zone cluster in OutCluster of your coordinator?

Hi Yikai,

thank for your response, i don't want to impliment ZCL ACE I just want to impliment IAS Zone only, and yes I have added ZCL_CLUSTER_ID_SS_IAS_ZONE in my out cluster list.

want to let you know, this are working for ZR device and for End device the behaviour is different. that is the issue. 

A standard CIE device should contains both ZCL ACE cluster in InCluster and ZCL IAS zone cluster in OutCluster. I suggest you add both of them to test to see if it works first.

Hi Ryan,

I did test with same coordinator with zed_zone and I observed this time I have received the response for Zone enroll Request, please have a look of line number 132 and 136.

the difference between the earlier sensor and this is that, the timing for Zone Enroll request command,  in "zed_zone" the request is performed whenever the button 2 is pressed, and at this  time no other communication over with ZC.

while in my third part end device sensor, it send Zone Enroll request command without user action and as a part of communication. that is because I think ZC cant able to respond.

Is there any setting that increase the number of holding number of packets by parents for a child device. may be this causing the issue. 

regards

Jagdish K

please find attached log of above testing 1425.New folder.zip

Another difference between the Zone Enrollment Requests from the zed_zone example and third-party device is the contents of the ZCL payload, both Zone Type and Manufacturer Code.  You can replicate the third-party data on the zed_zone example (ZDO_Config_Node_Descriptor.ManufacturerCode in zd_confg.c and zclSampleZone_ZoneType in zcl_samplezone_data.c) to further compare results.

Does the ZC respond to the Zone Enroll Request of the third-party device if you reset the ZED device after it has already joined the Zigbee network?   This may validate whether large message traffic is the issue.  You can try increasing NWK_MAX_DATABUFS_* in nwk_globals.c and it would help to further debug the zclSS_IAS_Send_ZoneStatusEnrollResponseCmd function of the ZC for when a ZED sends the Zone Enroll Request.

Regards,
Ryan

Hi Ryan,

on the second Zone Enroll Request, ZC respond, but as it already assigned a zone number to it thus the response is No Enroll Permit, please have a look of line number 97 and 105 of attached log.

in previous request as well it respond with default response but not with enroll response, have a look at line number 79, while in the second observation it does not respond with default response.

please not I debugged it, in both case the code reached to zclSS_IAS_Send_ZoneStatusEnrollResponseCmd so then after it must respond but it does not.

let me know if you need further information.

regards

Jagdish KEcolinkDoorWindow Sensor testing.zip

with problematic case I have debugged till " status = Zstackapi_AfDataReq(zclPortFindEntity(srcEP->endPoint), &req);" the value of status is coming 0, but I cant see anything on Ubiqua, its becoming I really cant able to understand this strange behaviour 

Hi Ryan,

i have tested the third party sensor with CIE sample application as well, I can see this is sending Zone enroll response have a look at line 66, now you would probable say my application is having problem but, this is again executing the same code that is "

SS_IAS_ZONE_STATUS_ENROLL_RESPONSE_CODE_NO_ENROLL_PERMIT is only returned if zclSS_AddZone fails because zcl_mem_alloc returns with a ZMemError.  You could be constrained on the heap memory which is causing messages to not be sent out.  The heap is statically allocated in Z-Stack provided with the SIMPLELINK-CC13XX-CC26XX-SDK v6.20 so you could try increasing the HEAPMGR_SIZE inside of app.cfg, however updating the v6.30 or newer will also allow for an automatic heap size allocation.

Please try increasing MAC_CFG_TX_* in Stack/Config/f8wcoord.opts as you did previously with the NWK_MAX_DATABUFS* values.  Are you using the Ecolink 4655BC0-R or any other device supported by Zigbee2MQTT?  If so then you may consider evaluating how their CC26X2 ZNP firmware responds to the third-party devices when communicating with their environment.

You could also debug zcl_ProcessMessageMSG to further determine why a zcl_SendDefaultRspCmd is not sent.  Otherwise, I will need time to recreate the issue on my end to further investigate the behavior.

Regards,
Ryan

Hi Ryan,

have you simulated this issue at your end, please let me know. 

ZC_CIE_ZED_ZONE.cubx

Attached is a ZC CIE correctly responding to a ZED Zone Enroll Request which is sent immediately after commissioning.  This is using the default SIMPLELINK-CC13XX-CC26XX-SDK v6.40 zc_cie project.  Please let me know what steps should be attempted to recreate the behavior you've observed. 

Regards,
Ryan