[参考译文] LAUNCHXL-CC1352P：Z-stack 1.2.2a 终端器件可以发送数据、但在某些情况下无法接收数据。

更改路由路径需要一些时间。 您是否要等待一段时间才能查看路由路径是否将被重构？

我正在等待大约15分钟、什么都没有发生。 我监听数据包并看到路由请求发送到路由器地址，但似乎没有响应。

网络上有44台设备、您希望完成重建的时间有多长？

您能否提供监听器并详细说明您的问题？

我将使用较少的器件构建网络、并尝试在问题发生时进行监听。

我如何将您发送到私人地址？ 有些敏感数据我 不想在这里公开。

我不是 TI 员工，因此如果您有任何问题，请不要私下发送任何敏感数据。

我已向您发送所有日志

我需要您的网络密钥来解密监听器日志、您能否在监听器日志中详细说明您的问题？

密钥为：01：03：05：07：09：0B：0D：0F：00：02：04：06：08：0A：0C：0D

0x5722是 CC2652 ZR 的地址、

从数据包1900拔下 ZC、ZED 连接到 ZR。

以0xbb2e (CC2630)为重点、在数据包2424上、它通过 ZR 重新加入网络。

当 ZC 重新打开并启动网络时，数据包11252会在我按下设备上的“开/关”按钮时发送返回状态。(可以正常发送数据，但无法接收)

数据包50445、ZC 可以向直接连接到 ZC 的器件0x6827 (CC2630)发送开/关命令、而不是通过 ZR。

在数据包19018上，ZC 发送路由请求，因为它无法向 0xbb2e (通过 ZR 0x5722连接)发送开/关命令，但没有应答。

我正在等待并继续尝试使用数据包222630

根据数据包2424上的终端节点声明，终端设备0xbb2e 的 IEEE 地址与 数据包19018上的路由请求命令不同，您声称“ZC 发送路由请求，因为它无法将开/关命令发送到0xbb2e (通过 ZR 0x5722连接)，但没有回复。”

是的、正确、IEEE 地址是 ZR 0x5722的地址、协调器向路由器发送路由请求、因为设备0xbb2e 已连接到路由器。 我的想法是对的？

或者、您是说 ZC 必须像发送数据包那样发送路由请求、目的地址为0xbb2e？

您可以在数据包50445中看到它发送到自己、但器件0x6826直接连接 到 ZC。

那么、这是 Z-stack 错误、是什么导致了它？

我在此处应用修补程序以修复损坏的路由： e2e.ti.com/.../883629

SDK 的版本为3.40。

对于1.2.2a 器件、如何为特定 ZigBee/z-stack 版本设置终端器件超时？ ZNP/ZR 固件或应用程序提供的？

此处的补丁： 。 我都尝试通过在 zglobals.c 中设置 zgChildAgingEnable 来启用和禁用儿童老化

对于 Z-Stack 1.2.2a、您必须启用 zgChildAgingEnable 为 true、以便 在 ZDApp_AnnounceNewAddress 期间发送 NLME_SendEndDevTimeoutReq。

为 Z-Stack 3.0器件禁用子级老化很可能会解释为什么没有父级通告消息来解决子级冲突。

此致、
Ryan

我将在下午向您发送 zgChildAgingEnable = True 的日志

我没有根据监听器日志提供更多信息。

此致、
Ryan

那么、我之前关于1.2.2a 版的终端设备超时的问题如何呢？

我在 zglobals.c 中读取：

//=========== 子老化父路由器(ZR/ZC)配置===
//您可以在
//操作的两种模式中的一种中设置路由器以支持子表老化。 第一种模式是 NWK_PARENT_INFO_END_DEVICE_TIMEOUT_MSG、它
//期望终端设备定期使用终端设备超时消息作为
向父设备发送保持活动//通知的方式。 另一种模式是 NWK_PARENT_INFO_MAC_DATA_POLL
//、它使用终端设备的 MAC POLL 请求作为保持活动通知。
//对于将为 RxOnIdle = false 的新器
件，首选第一种方法，因为//它不需要不断发送数据请求帧，而不需要从父级轮询数据。
//第二种方法与较旧的终端设备兼容，而无需
//特定的儿童老化支持。
//
//路由器(或协调器)支持的方法是在构建时确定
//方法是将 zgNWKParentInformation 设置为 NWK_parent_INFO_END_DEVICE_TIMEOUT_MSG
//或 NWK_parent_INFO_MAC_DATA_POLL。
//
//使用子表老化构建的终端设备支持这两种方法，该方法由
父设备确定并在运行时进行通信。 

关于 z-stack 1.2.2a、您可能会错。 我读取了代码：ZDUP.C. 它确实会在 ZDApp_AnnounceNewAddress 中发送我设置的儿童老化时间(在本例中为10秒)。 监听器是启用了儿童老化功能的固件。 我知道此版本不更新、但 cc2630/c2650仍是有效产品

void ZDApp_AnnounceNewAddress( void ){

#if defined ( ZIGBEPRO )
//关闭数据请求保持
APSM_HoldDataRequests(0)；
#endif

ZDP_DeviceAnnce ( NLME_GetShortAddr()，NLME_GetExtAddr ()，
ZDO_Config_Node_Descriptor.CapabilityFlags，0)；

#if defined ( ZIGBEPRO )
//设置超时
APSMT_HoldDataRequests ( ZDAPP_HOLD_DATA_Requests_TIMEOUT )；
#endif

if ( ZSTACK_END_DEVICE_Build )
{
if (zgChildAgingEnable == true)
｛
uint8 coordExtAddr[Z_EXTADDR_LEN]；

//将消息发送到父级
NLME_GetCoordExtAddr ( coordExtAddr )；
NLME_SendEndDevTimeoutReq (NLME_GetCoordShortAddr ()、coordExtAddr、
zgEndDeviceTimeoutValue、
zgEndDeviceConfiguration )；
}
}

ZC 已超时 ZED、ZED 已在 ZC 关闭时重新加入 ZR。  因此、ZC 不知道 ZED 是否处于活动状态、但通常会在尝试间接发送 ZCL 命令时发送路由请求、我希望 ZR 使用更新的路由进行回复。

Ryan

否、在我的测试中、首先让所有 ZED 连接到 ZC、最后一个 Zr 配对、然后关闭 ZC。

ZED 将发送孤立并重新加入 到 ZR (这些错误为 ZED、并非全部)、现在我将 ZC (ZNP)重新供电、然后启动网络。

我已经看到路由请求 ZC 发送0xfc 或 ZR (目标地址为 ZR)、并且某个时间目标地址是无法控制的 ZED、但在该问题之后仍然存在。

所有 ZED 直接连接到 ZC 都没有问题。 我只能在3个器件上重现此问题：1 ZC CC1352、1 ZR CC2652和1 ZED CC2630、这是第一次可能不会发生、但会重复一些并发生。

这是断电、重启/更新服务器等后的实际问题、但经过多次尝试后、我仍然无法修复、您可以在这里的一些文章中提及这一点。

这种错误很少发生、因为单向 ZED 传感器不会发生、只发送数据、而不接收命令、因为我的器件是光开关、它是双向器件。

[引用 user="DzungPV"]我确实看到路由请求 ZC 发送 ZR (目标地址为 ZR)，并且某个时间目标地址无法控制 ZED，但在该问题之后仍然存在。

您能否提供小型/部分监听器日志捕获来证明这一点？

[引用 user="dzungpv"]第一次可能不会发生，但会重复一些，并且会发生。

是否有任何网络行为可控制问题是否发生？

绑定到 ZC 的器件数量是多少、您是否 相应地增加了 NWK_MAX_BINARTing_entries？  ZED 和 ZR 的 NWK_INDIRECT 和 MSG_TIMEOUT 的 POLL_RATE 是什么？  自从 Koen Kanters 开发了您正在评估的 zigbee2mqtt 固件后、您是否就这一问题征求过他的建议？

此致、
Ryan  

您能否在有问题的情况下提供路由请求的屏幕截图示例？  通常，0xFFFC 网络目的地表示向所有路由设备广播消息。

此致、
Ryan

这是路由请求发送当 zigbee2mqtt 无法控制 ZED 时，它确实发送给它短地址，但没有来自 ZR 的应答，您对此有什么想法？

是的、您可以在屏幕短接中看到。

对于非 MTO 路由请求、如果 ZR 处于无线电范围内、则如果它包含作为子设备的目标设备地址(在我的测试中已确认)、则应发送路由应答、或重新广播网络中其他路由设备的路由请求以进行处理。

MTO 路由请求在整个网络中广播、您可以在 Z-Stack 用户指南 ：http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html?highlight=many%20one#many-to-one-routing-protocol 中了解有关此协议的更多信息 

此致、
Ryan

在无线电范围内、ZC 可以接收状态报告。 但不会通过路由请求从路由器回复。

是否使用 Zed HA1.2.2a 或3.x 进行测试？

3.x ZED，但正如我们所讨论的，这似乎是3.x ZC/ZR 路由设备的一个问题。  如果 ZC 收到来自 ZR 的路由应答，则它将更新其路由表并发送预期的命令数据包，这一切都应在 Z-Stack 源内部自动发生，但首先 ZR 应根据路由请求采取行动。  请告诉我您在 ZR 调查中发现的内容。

此致、
Ryan

我使用的 ZED 运行 HA 1.2.2a 可能会导致问题、我很快会尝试使用3.x ZED 进行测试、但似乎 Z-stack 会导致问题、我看到论坛中有人断电、路由器也有问题、但我现在找不到链接。

ZC 发送多个路由器请求，但没有收到连接到 ZR 的 ZED 设备的回复，您可以在我的数据包监听器中看到该请求，该请求在下午之前发送给您。

您可以在下面的屏幕截图中看到、ZED 通过 ZR 向 ZC 发送数据、这意味着它包含 ZED 记录、但该器件 ZC 无法向其发送 ON/OFF 命令。

ZR 为0x4246、运行3.4 ZR Light cc2652、0x3afc 连接到 ZR 并通过它向 ZC 发送开/关报告、但 ZC 无法向其发送开/关命令、这就是问题所在。 Koen Kanters 尝试多种方式发送 AF 命令以获取路由/控制设备、但它不会回复、ZED 也不会接收该命令。

我希望3.x ZED 的运行方式相同、但最好验证这一点、因为我已经提到在我的设置上进行测试时 ZR 运行正常。  我 确实检查了监听器日志、但没有看到 ZC 发出的任何未响应的非 MTO 路由请求。  遗憾的是、来自 ZED 的数据报告不会更新 ZC 的路由表。

此致、
Ryan

>  我 确实检查了监听器日志、但没有看到 ZC 发出的任何未响应的非 MTO 路由请求。

您能否解释一下区别是什么以及在哪些用例中使用什么？

当前选项：0被提供、AFAIK 映射到这个、对吧？

选项0：MTO 路由请求

选项1：非 MTO 路由请求

嗨、Koen、

路由请求： http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#route-discovery-and-selection 
MTO： http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/z-stack-overview.html#many-to-one-routing-protocol 
MTO 路由请求发现周期为 concentrator_discovery_time： http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_40_00_02/docs/zigbee/html/zigbee/network_configuration.html 

此致、
Ryan

感谢你的帮助。 我找到了问题的根本原因：它是儿童老龄化