• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 1070 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: Number of beacon requests during commissioning

AlexTim
Expert 1270 points

Part Number: CC1352R

When we start commissioning on the ZED, it sends only one Beacon Request.

We would like to make ZED sending a few Beacon Requests.

Is it possible to configure the number of beacon requests?

  • 0
    Guru 735705 points

    You can call start commission again to send beacon request again.

  • 0 in reply to YiKai Chen
    Expert 1270 points

    What callbacks do we have to know if the commissioning was successful or failed?

  • +1 in reply to AlexTim
    TI__Guru**** 223827 points

    Hi Tim,

    You cannot configure the number of beacon requests, but you are able to use the BDB_COMMISSIONING_NWK_STEERING case inside the zcl*_ProcessCommissioningStatus of your zcl_*.c file to determine whether commissioning was successful (BDB_COMMISSIONING_SUCCESS) and determine further action.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1270 points

    Thanks, it works.

    But now I have another question, similar to this one https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/988550/cc1352p-zed-device-joining-the-zc-device-even-after-zc-device-is-reset-to-factory-defaults/3651423?tisearch=e2e-sitesearch&keymatch=Zstackapi_bdbZedAttemptRecoverNwkReq#3651423

    I see a similar effect as descriped in that topic. But ZED joins to the new ZC network not every time. I see Beacon Requests, but Rejoin Request appears in the sniffer very rarely. ZED is in Orphaned/Discovering state. But when the Rejoin Request appears, then the ZED can connect to ZC and stay in the network. When  I reboot the ZED, I see that in the CUI status [PAN ID] shows the oldest address shortly, then ZED changes state Discovering/Rejoining/Orphaned and the new [PAN ID] addres is shown in the CUI. So it looks like the PAN ID was not updated after Request Rejoinig. And then ZED stays in Orphaned state. And in sniffer I see ZC "Leave" messages.

    So questions are:

    1. Why Rejoin Request is not sent by ZED after Beacon Request/Respond every time? It takes a few Beacon Request (~3 times), then Rejoin Request is sent.

    2. Why after succesful Rejoin Request, the ZED doesn't remember the new PANID? If I reset ZED, I see that the old PANID appears in the CUI and then ZED gets stuck in discovering/orphaned and never rejoin and never sends the rejoin request.

    3. Why ZC send "Leave" messages and ZED ignores them?

  • +1 in reply to AlexTim
    TI__Guru**** 223827 points

    Please provide your sniffer log if possible.  I assume that in this case, the ZC has factory reset and started a new network?  Or has it retained the network information and only changed its PAN ID?  By your description it appears that the ZED recognizes the EPID of the ZC and tries to rejoin the network under the new PAN ID, however if the NWK key has changed then the secure rejoin will fail.  After BDB_MAX_SECURE_REJOIN_ATTEMPTS, the ZED will then attempt an unsecure rejoin (TC rejoin) but if the ZC does not recognize the device and zgAllowRejoinsWithWellKnownKey is FALSE then the TC will not send the NWK key.  The ZC is instead sending encrypted Leave messages which the ZED most likely ignores because it does not understand the new NWK key encryption.  If the ZC cannot be modified to allow the TC rejoins then the ZED's application will need to recognize that the rejoin process is failing and factory reset so that it can perform a fresh join.  This will only succeed of course if permit join is enabled on the ZC.

    Regards,
    Ryan