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.
https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1090711/cc1352r-number-of-beacon-requests-during-commissioning
当我们开始在Zed上调试时，它仅发送一个信标请求。
我们想让Zed发送一些信标请求。
是否可以配置信标请求的数量？
您可以再次调用启动佣金以再次发送信标请求。
我们必须知道哪些回电是试运行成功还是失败？
您好，Tim，
您不能配置信标请求的数量，但可以使用 zcl*_ProcessCommissioningStatus文件中的BDB_Commissioning_Nwk_steering案例来确定调试是否成功(BDB_Commissioning_success)并确定进一步的操作。
此致， Ryan
谢谢，它工作正常。
但现在我有另一个问题，类似于 这个https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/98.855万/cc1352p-zed-device-joining-the-zc-device-even-after-zc-device-is-reset-to-factory-defaults/3651423?tisearch=e2e-sitesearch&keymatch=Zstackapi_bdbZedAttemptRecoverNwkReq#3651423</s>1352 365.1423万365.1423万
我看到了该主题中描述的类似效果。 但Zed并非每次都加入新的ZC网络。 我看到信标请求，但重新加入请求很少出现在嗅探器中。 Zed处于孤立/发现状态。 但当重新加入请求出现时，Zed可以连接到ZC并保持在网络中。 当我重新启动Zed时，我看到在CUI状态中，[PAN ID]很快会显示最早的地址，然后Zed更改状态发现/重新加入/孤立，新的[PAN ID]地址显示在CUI中。 因此，在请求Rejoinig后，PAN ID似乎未更新。 然后Zed保持孤立状态。 在嗅探器中，我看到ZC“离开”消息。
问题包括：
1.为什么每次信标请求/响应后Zed都不发送重新加入请求？ 它需要几次信标请求(~3次)，然后发送重新加入请求。
2.为什么成功的重新加入请求后，Zed不记得新的PANID？ 如果我重置Zed，我会看到旧的PANID出现在CUI中，然后Zed陷入发现/孤立状态，从不重新加入，也不会发送重新加入请求。
3.为什么ZC发送"离开"消息而Zed忽略这些消息？
如果可能，请提供您的嗅探器日志。 我假设在这种情况下，ZC已恢复出厂设置并启动了新网络？ 或者它是否保留了网络信息而只更改了PAN ID？ 根据您的描述，Zed似乎识别了ZC的EPID并尝试使用新的PAN ID重新加入网络，但是如果Nwk密钥已更改，则安全重新加入将失败。 在 BDB_MAX_SECREUST_REUST_TRUSING_TRINESINESING_TRUSINESINESDS之后，Zed将尝试进行不安全的重新加入(TC重新加入)，但是如果ZC无法识别设备， 并且zgAllowRejoinsWithWellKnownKey为false，则TC将不会发送Nwk密钥。 ZC发送的是加密的离开消息，Zed很可能会忽略这些消息，因为它不了解新的Nwk密钥加密。 如果无法修改ZC以允许TC重新加入，则Zed的应用程序需要识别重新加入过程失败并重置出厂设置，以便它可以执行新加入。 当然，只有在ZC上启用了允许加入时，此操作才会成功。
