[参考译文] CC2652R：Z-Stack 3.0 ZC的温度传感器报告问题。

1.我们通常使用绑定将报告目标短地址和端点分配给设备。

2.是否可以附加嗅探器日志以检查此情况？

您好，YiKai，

两个附加文件：一个是 2022.0428万_ti_cc2652_temperation_sensor.pcapng.txt，2652，另一个是 2022.0428万_em357_temperation_sensor.pcapng.txt。

只需删除txt扩展名，使其成为*.pcapng文件，Wireshark v 2.0 7工具即可理解这些文件。 (注意：我无法使用*。pcapng上传)

从 2022.0428万_ti_cc2652_temperation_sensor.pcapng开始2652开始，我在加入后检查数据包，但找不到任何相关数据包，ZC无法将ZC端点编号告诉Zed。 (实际上没有绑定数据包，但设备通告，节点描述符请求/响应，活动端点请求/响应，简单描述符请求/响应， etc)您的意思是我需要在命令前设置额外的绑定命令：GW_CMD_ID_T__DEV_GET_TEMP_REQ for "test Zed"？

从 2022.0428万_em357_temperature_sensor.pcapng开始，即使我尝试从“Test Zed”读取温度，也没有任何数据包。 您可以在80之后检查行#。 我打开调试日志并看到"npI_sendframe: Subsys:36, cmdId:2"日志。 我猜它在ZNP中被阻止，不会发送到Zed。 但我不知道为什么。 (请注意，在 2022.0428万_ti_cc2652_temperature_sensor.pcapng的2652的第176行和第178行中，我可以从"golden Zed"读取温度。)

此致，

彼得。

e2e.ti.com/.../2022.0428万_5F00_ti_5F00_cc2652_5F00_temperature_5F00_sensor.pcapng.txte2e.ti.com/.../20220428_5F00_em357_5F00_temperature_5F00_sensor.pcapng.txt</s>2652 2022.0428万

我只看到字符不稳定。 请压缩您的pcapng并重新附加。

e2e.ti.com/.../2022.0428万.rar

下面列出了我与"goldenZED"和"test Zed"案例对应的所选调试日志记录，供您参考：

//对于Golden Zed外壳，TI CC2652... (可以读取温度)

#PETER# zcl_SendRead - dstAddr：9109 EP：8，srcEP：1，clusterID：402，readCmd：-1.40506288亿
[11:05:43.AF][gateway/LSTN] UNMSKBL：#PETER# Sending 13.0549万 Data request - dstAddr：2395，srcEp：1，dstEp：8，CID：402，bufLen：5
[11:05:43.Cb] 13.065万 [Z_stack/LSTN] UNMSKBL：#Peter# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x22 #
[11:05:43.RCVD][Z_STACT/LSTN] UNMSKBL：#PETER# zstackpb 13.0683万 数据请求：addrMode：2，dstAddr：2395，dep：8，Sep：1
[11:05:43.UNMSKBL][Z_STACT/LSTN] 13.0696万 ：#PETER#调用AF_DataRequest
[11:05:43.AF][Z_STACT/LSTN] UNMSKBL：#PETER#发送13.0704万 数据请求- dstAddr：2395，srcEp：1，dstEp：8，CID：402，len：5...
[11:05:43.UNMSKBL][Z_STACT/LSTN] 13.0714万 ：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：4，cmdID：2，len：：25
[11:05:43.UNMSKBL][NPISRVR/MAIN ] 13.078万 ：#PETER#接收消息...
[11:05:43.UNMSKBL][NPISRVR/MAIN ] 13.0813万 ：#PETER# NPI_UART_SendSynchData: cmdId:2#
[11:05:43.UNMSKBL][NPISRVR/MAIN ] 13.0844万 ：#PETER# NPI_sendframe：：36，cmdId：2确定。 #
[11:05:43.CASTLE][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] 13.5367万 ：0x64，ID：0x02，长度：1.
[11:05:45.CMSL][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] 3.42万 ，Subsys：0x44，ID：0x80，长度：3
[11:05:45.MSG][Z_STACT/HNDL] UNMSKBL：#PETER# ZNP_MISC 3.4408万 ：Subsys:4, cmdID:0x80#
[11:05:45.CMSL][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCframe，4.6771万 ：0x44，Cmd ID：0x81，长度：29
[11:05:45.MSG][Z_STACT/HNDL] UNMSKBL：#PETER# ZNP_MISC 4.6991万 ：Subsys:4, cmdID:0x81#
[11:05:45.IDS] 4.7168万 [gateway/HNDL] UNMSKBL：#PETER# handleMSSMsgs：ZStack_CMD_IDS__AF_Incoming_MSG_IND #

//用于测试Zed案例。 EM357... (读取温度失败)

#PETER# zcl_SendRead - dstAddr：5.6934万 EP：1，srcEP：1，clusterID：402，readCmd：-1.40506288亿
[11:06:18.AF][GATEE/LSTN] UNMSKBL：#PETER# Sending 13.6854万 Data request - dstAddr：de66，srcEp：1，dstEp：1，CID：402，bufLen：5
[11:06:18.Cb] 13.7027万 [Z_stack/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x22 #
[11:06:18.UNMSKBL][NPISRVR/MAIN ] 13.7149万 ：#PETER#接收消息...
[11:06:18.RCVD][Z_STACT/LSTN] UNMSKBL：#PETER# zstackpb 13.7063万 数据请求：addrMode：2，dstAddr：de66，dep：1，Sep：1
[11:06:18.UNMSKBL][Z_STACT/LSTN] 13.7075万 ：#PETER#调用AF_DataRequest
[11:06:18.AF][Z_STACT/LSTN] UNMSKBL：#PETER#发送13.7084万 数据请求- dstAddr：de66，srcEp：1，dstEp：1，CID：402，len：5...
[11:06:18.NPI] 13.7093万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：4，cmdID：2，len：：25
[11:06:18.UNMSKBL][NPISRVR/MAIN ] 13.7185万 ：#PETER# NPI_UART_SendSynchData: cmdId:2#
[11:06:18.UNMSKBL][NPISRVR/MAIN ] 13.7216万 ：#PETER# NPI_sendframe：：36，cmdId：2确定。 #
[11:06:18.CMSL][NPISRVR/U_RX] 14.1744万 ：#PETER#[UART] NPI_PROCE帧，：0x64，Cmd ID：0x02，长度：1.
[11:06:24.RSS][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCframe，63.0765万 ：0x44，Cmd ID：0x80，长度：3
[11:06:24.MSG][Z_STACT/HNDL] UNMSKBL：#PETER# ZNP_MISC 63.0964万 ：Subsys:4, cmdID:0x80#
[11:06:27.Cb] 8.9855万 [Z_stack/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x15 #
[11:06:27.NPI] 8.9898万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：5，cmdID：45，len：：4
[11:06:27.UNMSKBL][NPISRVR/MAIN ] 8.9965万 ：#PETER#接收消息...
[11:06:27.UNMSKBL][NPISRVR/MAON] 8.9998万 ：#PETER# NPI_UART_SendSynchData: cmdId:69#
[11:06:27.UNMSKBL][NPISRVR/MAIN ] 9.0028万 ：#PETER# NPI_sendframe：：37，cmdId：69确定。 #
[11:06:27.CMSKBL][NPISRVR/U_RX] 9.2468万 ：#PETER#[UART] NPI_PROCframe，子系统：0x65，ID：0x45，长度：1.

在em357嗅探器日志中，我没有看到协调器向您的em357温度传感器发送ZCL读取属性命令。

是的。 这让我感到困惑。

因此，我打印了一些cmd_id的调试日志(如上)： GW_CMD_ID_T__DEVE_GET_TEMP_REQ， 您可以看到两个ZED都具有“NPI_sendframe: Subsys:36, cmdId:2 OK”。 在通过UART发送到ZNP FW之前，NPI_sendframe应是最底线。 我不知道要为"test Zed"案例挖掘更多内容。

您的串行日志显示em357 dstAddr:de66，但在嗅探器日志中却不一样。 请再次执行测试并提供匹配的嗅探器和串行日志。

请参阅附件please.e2e.ti.com/.../20.2204万281638.rar</s>28.1638万

您可能需要转储“Peter#[UART] npI_procframe，Subsys: 0x64，Cmd ID: 0x02，length：1”的length:1有效负载内容，以了解AF_data_request_EXT SRSP状态代码以进行进一步调试。

在添加以下列出的更多调试信息后进行调试日志记录：

//下面是cc2652 Zed日志记录，可以使用请求命令被动地报告温度。

=========== 开始记录===========

#PETER# zcl_SendRead - dstAddr：3.8234万 EP：8，srcEP：1，clusterID：402，readCmd：-1.40506512亿
[08:53:05.AF][gateway/LSTN] UNMSKBL：#PETER#发送36.6106万 数据请求- dstAddr:955a，srcEp：1，dstEp：8，CID:402，bufLen：5
[08:53:05.Cb] 36.6302万 [Z_stack/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x22 #
[08:53:05.ADD][Z_STACK/LSTN] UNMSKBL：#PETER# zstackpb 36.6335万 数据请求：addrMode：2，dstAddr：955a，dep：8，Sep：1
[08:53:05.UNMSKBL][Z_STACT/LSTN] 36.6424万 ：#PETER# CALL AF_DataRequest
[08:53:05.AF][Z_STACK/LSTN] UNMSKBL：#PETER#发送36.6501万 数据请求- dstAddr：955a，srcEp：1，dstEp：8，CID：402，len：5...
[08:53:05.NPT] 36.6572万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：4，cmdID：2，len：：25
[08:53:05.UNMSKBL][NPISRVR/MAIN ] 36.668万 ：#PETER#接收消息...
[08:53:05.UNMSKBL][NPISRVR/MAON] 36.6717万 ：#PETER# NPI_UART_SendSynchData: cmdId:2#
[08:53:05.UNMSKBL][NPISRVR/MAIN ] 36.675万 ：#PETER# NPI_sendframe：：36，cmdId：2确定。 #
[08:53:05.NPISR/U_Rx] 37.1281万 UNMSKBL：#PETER#[UART] NPI_parseframe:找到帧，转至NPI_procframe
[08:53:05.CMSL][NPISRVR/U_RX] 37.1312万 ：#PETER#[UART] NPI_PROCframe，：0x64，Cmd ID：0x02，长度：1.
[08：53：05。37.1327万 ][NPISRVR/U_RX] UNMSKBL：#PETER#[SRSP] 01：64：02：
[08：53：05.UNMSKBL][NPISRVR/U_RX] 37.1362万 ：#PETER#[同步响应] 01：0：64：02：
[08:53:05.NPISR/U_Rx] 37.1379万 UNMSKBL：#PETER#[UART]收到NPI_PROCLFTER信号同步响应(通过读取回路调用)
[08:53:05.NPISR/U_Rx] 65.6165万 UNMSKBL：#PETER#[UART] NPI_parseframe:找到帧，转至NPI_procframe
[08：53：05。NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，65.6205万 ：0x44，Cmd ID：0x80，长度：3
[08:53:05.UNMSKBL][NPISRVR/U_RX] 65.6221万 ：#PETER#[UART] NPI_PROCframe signal areq回调线程(通过读取回路调用)
[08:53:05.MSG][Z_STACT/HNDL] UNMSKBL：#PETER# ZNP_MISC 65.6389万 ：Subsys：4，cmdID：0x80 #
[08:53:05.NPISR/U_Rx] 67.363万 UNMSKBL：#PETER#[UART] NPI_parseframe:找到帧，转至NPI_procframe
[08:53:05.MSG][Z_STACT/HNDL] UNMSKBL：#PETER# ZNP_MISC 67.3833万 ：Subsys：4，cmdID：0x81 #
[08:53:05.IDS] 67.4009万 [gateway/HNDL] UNMSKBL：#PETER# handleMSSMsgs：ZStack_CMD_IDS__AF_Incoming_MSG_IND #
[08：53：05。NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，67.3668万 ：0x44，Cmd ID：0x81，长度：29
[08:53:05.UNMSKBL][NPISRVR/U_RX] 67.3685万 ：#PETER#[UART] NPI_PROCframe signal areq回调线程(通过读取回路调用)

//下面是em357 Zed 日志记录，它无法使用请求命令被动地报告温度

#PETER# zcl_SendRead - dstAddr：5.1233万 EP：1，srcEP：1，clusterID：402，readCmd：-1.40506512亿
[08:53:41.AF][gateway/LSTN] UNMSKBL：#PETER# Sending 0.2522万 Data request - dstAddr：c821，srcEp：1，dstEp：1，CID：402，bufLen：5
[08:53:41.Cb] 0.2626万 [Z_stack/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x22 #
[08:53:41.RCVD][Z_STACT/LSTN] UNMSKBL：#PETER# zstackpb 0.266万 数据请求：addrMode：2，dstAddr：c821，dep：1，Sep：1
[08:53:41.UNMSKBL][Z_STACT/LSTN] 0.2672万 ：#PETER#调用AF_DataRequest
[08:53:41.AF][Z_STACT/LSTN] UNMSKBL：#PETER#发送0.2681万 数据请求- dstAddr：c821，srcEp：1，dstEp：1，CID：402，len：5...
[08:53:41.NPT] 0.269万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：4，cmdID：2，len：：25
[08:53:41.UNMSKBL][NPISRVR/MAIN ] 0.2732万 ：#PETER#接收消息...
[08:53:41.UNMSKBL][NPISRVR/MAON] 0.2767万 ：#PETER# NPI_UART_SendSynchData: cmdId:2#
[08:53:41.UNMSKBL][NPISRVR/MAIN ] 0.2799万 ：#PETER# NPI_sendframe：：36，cmdId：2确定。 #
[08:53:41.NPISRVR/U_Rx] 0.7293万 UNMSKBL：#PETER#[UART] NPI_parseframe：找到帧，转至NPI_procframe
[08:53:41.CMST][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCframe，0.7329万 ：0x64，Cmd ID：0x02，长度：1.
[08：53：41.SP] 0.7345万 [NPISRVR/U_RX] UNMSKBL：#PETER#[SRSP] 01：64：02：
[08：53：41.UNMSKBL][NPISRVR/U_RX] 0.7384万 ：#PETER#[同步响应] 01：0：64：02：
[08:53:41.UMSKBL] 0.7393万 [NPISRVR/U_RX] UNMSKBL：#PETER#[UART]收到NPI_PROCframe信号同步响应(通过读取回路调用)
[08:53:47.NPISR/U_Rx] 16.4546万 UNMSKBL：#PETER#[UART] NPI_parseframe:找到帧，转至NPI_procframe
[08:53:47.CMSL][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCframe，16.4595万 ：0x44，Cmd ID：0x80，长度：3
[08:53:47.NPISR/U_RX] 16.4616万 UNMSKBL：#PETER#[UART] NPI_procframe signal areq回调线程(通过读取回路调用)
[08:53:47.MSG][Z_STACT/HNDL] UNMSKBL：#PETER# ZNP_MISC 16.4806万 ：Subsys：4，cmdID：0x80 #
[08:53:49.Cb] 91.2362万 [Z_stack/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x15 #
[08:53:49.NPI] 91.2406万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：5，cmdID：45，len：：4
[08:53:49.UNMSKBL][NPISRVR/MAIN ] 91.2464万 ：#PETER#接收消息...
[08：53：49.UNMSKBL][NPISRVR/MAON] 91.2497万 ：#PETER# NPI_UART_SendSynchData: cmdId：69 #
[08：53：49.UNMSKBL][NPISRVR/MAIN ] 91.2529万 ：#PETER# NPI_sendframe：：37，cmdId：69确定。 #
[08:53:49.NPISR/U_RX] 91.5004万 UNMSKBL：#PETER#[UART] NPI_parseframe：找到帧，转至NPI_procframe
[08：53：49.CMST][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCE帧，91.5056万 ：0x65，Cmd ID：0x45，长度：1.
[08：53：49。91.5072万 ][NPISRVR/U_RX] UNMSKBL：#PETER#[SRSP] 01：65：45：
[08：53：49.UNMSKBL][NPISRVR/U_RX] 91.5108万 ：#PETER#[同步响应] 01：0：65：45：
[08:53:49.UMSKBL] 91.5118万 [NPISRVR/U_RX] UNMSKBL：#PETER#[UART]收到NPI_procframe信号同步响应(通过读取回路调用)

=========== 日志结束===========

蓝色文本打印出一个字节的有效负载数据，两个数据的值都为0 (第二个)。

奇怪的是红色文本。 正常的时间间隔(cc2652)很短。 但故障1 (em357)的时间间隔超过5秒。 ZNP固件似乎没有响应，主机超时。

我认为该问题是由于您的em357设备不频繁轮询导致的，因此无法从协调器获取您的ZCl读取属性命令。

TI专家，您好！

所提供的答案尚未解决我的问题，因为我无法修改"test Zed"代码以进行验证。

但是，在使用“test Zed”进行测试时，我没有看到任何无线数据请求数据包。 相反，我看到"金色Zed"测试案例的数据请求数据包频率较高。 这与上述答案不同，我同意。 从我的理解来看，这种症状似乎是合理的。

也许我需要使用我构建的ZNP固件进行调试或检查源代码以了解更多内容。

不管怎样，我更新了我之前的结论并继续关注。 谢谢。

此致，

彼得。

Zed上主要配置了数据请求数据包，因此您必须检查此Zed在加入过程中不希望轮询足够快的原因。 在ZNP上没有什么可做的。

我知道数据请求来自Zed站点。 我要调试ZNP的原因是要确保：ZNP未发出 GW_CMD_ID_T__DEV_GET_TEMP_REQ是因为Zed没有数据请求。 或者是否有任何规范正在解决此问题？

BTW，"TEST Zed"在加入阶段发送了一些数据请求，并且不会发送其他阶段的任何数据请求，以延长电池寿命。

实际上，很难知道Zed是在投票还是会及时投票。 所以，你不能在ZNP上做太多的事情。 Zed的消息将保留在其父节点的间接消息缓冲区中，但如果Zed不及时轮询，则将被丢弃。

您的意思是"读取属性"数据包是仍需要将Zed的数据请求发送到Zed的消息类型之一？  

如果"是"和"测试Zed"将按现在的方式工作，这意味着由于"测试Zed"缺少数据请求功能，我无法支持此被动读取温度。

是的，休眠Zed需要进行轮询才能接收数据。 如果不进行轮询，Sleeping Zed将无法接收任何内容。