[参考译文] CC2530-CC2591EM-RD：无法控制终端设备

您使用哪个 Z-Stack 版本？ 是否使用 Z-Stack Home 1.2.2a？ 我还建议您使用监听器来检查无线传输中发生的确切情况。

我使用的是 Z-Stack Home 1.2.2a

您是否修改了 Z-Stack 源代码中的任何内容？ 您能否提供监听器日志？

否、我们没有修改任何内容、因为我们使用了来自 Koenk Kanters Github 的 Z-stack 1.2固件、这是一个十六进制文件。 我们正在准备嗅探器日志、将很快发送。

e2e.ti.com/.../8400.sample-data.psd

这是监听器日志

您好、Karthick、

监听器日志不提供更多信息。  加入 Koen Kanters 、看看他是否观察过这种行为。   ZNP 器件是否仍然响应主机发出的 MT 命令、但绝不通过无线方式发送它们、是否广播链路状态消息或响应其他器件发出的命令？  如果您在出厂时重置节点并重新连接指示灯、则行为是否恢复正常？  如果器件完全重新编程、会发生什么情况？  我正在尝试确定非易失性或程序闪存存储器是否可能损坏。

此致、
Ryan

由于您使用的是 ZNP、我同意 Ryan 的意见、即您应该检查 ZNP 器件是否仍然首先响应主机发出的 MT 命令。

为了正确了解问题、我只将一个模块与 USB 记忆棒配对并进行测试、发现了相同的问题。 它适用于循环供电后的第一个命令、稍后停止响应、但 ztool 在器件通电时显示通知消息。

您是否意味着在使用 CC2531EMK-USB 与 Ztool 配合使用并连接到单个 Zigbee 器件时、您可能会重现类似的问题？ 如果是、您能否详细说明在该 CC2531EMK-USB 上运行 ZNP 时使用的 Z-Stack 版本以及在电源回收后使用的第一条命令、并参阅在该命令之后停止响应？

我使用了来自链接 https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_Home_1.2/bin/default 的 Z-stack 1.2固件、 我刚刚配对了一个照明模块、并在 AF_DATA_REQUEST 中为 ON/OFF 帧了一个命令、对于第一个命令、它会打开或关闭、并且我可以通过 AF_INVING_MSG 成功接收反馈、 对于下一个立即命令、它没有响应、并显示如下所示的消息、

09：56：41.81 COM4 AF_DATA_REQUEST (0x2401)
  DstAddr：0xFA8A
  DestEndpoint：0x01
  SrcEndpoint：0x07
  clusterid：0x0006
  TransID：0x01
  选项：0x02
  半径：0x07
  Len：0x03
  数据：... (0x01、0x01、0x01)

09：56：41.83 COM4 AF_DATA_Request_SRSP (0x6401)
  状态：afStatus_Success (0x0)

09：56：42.27 COM4 AF_DATA_CONFIRM (0x4480)
  状态：afStatus_Success (0x0)
  端点：0x07
  TransID：0x01

但器件中没有响应、有时、如果我们重新启动终端器件的电源、它会再次开始响应第一条命令。 我们已经使用此工具几天了、但这是我们第一次遇到这样的问题。

您是否意味着您遇到的问题是终端设备不响应命令、也不是 ZNP 无响应？ 如果是、您使用什么终端设备进行测试？

不、我认为终端设备还可以、因为我们使用其他终端设备(来自另一个品牌和型号)尝试了相同的方案、并观察到了相同的症状。 这是执行命令时 ZNP 的问题。

测试时、是否使用监听器检查终端设备是否进行轮询以接收命令？

不、我不知道这种监听器解码、  

我无法理解您的回答："我不知道这段嗅探器解码"。 如果您使用监听器、您能否提供与此最新问题相关的监听器日志？

我的意思是、我可以跟踪监听器、但无法解码来自 tracee2e.ti.com/.../data-not-working.psd 的信息

这是另一条线迹、其中器件控制第一条命令并进一步停止

请对您的协调器和设备进行出厂重置、以便在监听器始终打开的情况下加入并再次进行测试、以便我可以获取您的网络密钥来解密您的日志。

请稍等

e2e.ti.com/.../complete-data.psd

在这里

您从协调器向器件发送了什么命令？

我通过协调器的 AF_DATA_REQUEST 构建了一个开-关命令。

  DstAddr：0xFA8A
  DestEndpoint：0x01
  SrcEndpoint：0x07
  clusterid：0x0006
  TransID：0x01
  选项：0x02
  半径：0x07
  Len：0x03
  数据：... (0x01、0x01、0x01)

和上述参数。

您的完整数据.psd 中没有短地址为0xFA8A 的器件

实际上、完整的 data.psd 是我们捕获的实际文件、上面的帧数据是我发送的一个示例帧、供您了解。

请告诉我您的测试设备的短地址是什么？

0x42E6

您的完整 data.psd 中没有0x42E6。

但是昨天、我们将协调器与终端设备配对、并发送了命令、最初是针对它正在工作的第一个命令、而第二个命令则不工作、从这种情况下、我们得到了跟踪。

监听器日志结果与您描述的结果不匹配。 无论如何、您可以尝试执行测试并再次提供新的监听器日志。

e2e.ti.com/.../trace-data.psd 现已推出

根据 跟踪数据.psd ，我看到协调器发送开/关命令，而您的设备响应 MAC ACK，这意味着设备接收命令。 我看到您正在使用 Silicon Labs 器件、您应该检查该 Silicon Labs 器件上的问题。

但我们尝试了另一个终端器件(不同的制造商、但芯片实验室)出现了相同的问题、现在让我尝试一下基于 TI 的器件。

您好、YK 这里是基于 TI 的终端设备的另一个跟踪数据、该设备也会配对、但当我尝试使用 AF_DATA_REQUEST 进行控制时、它不会发生、e2e.ti.com/.../TI-trace-data.psd

在新的监听器日志中、终端设备的 IEEE 地址是3C-6A-2C-FF-FE-D0-96-F8、看起来不属于 TI SoC。 我没有用于解密某些数据包的网络密钥、但我可以看到当协调器向其发送消息时、3C-6A-2C-FF-FE-D0-96-F8会响应 MAC ACK。

该特定器件基于 CC2530、我们之前对它进行了控制、但现在它正在配对、但无法正常工作

我知道、3C-6A-2C-FF-FE-D0-96-F8不是 CC2530的 IEEE 地址格式。 无论如何、我是否可以知道您在此 CC2530上运行的 Z-Stack 版本和示例？

我没有在此运行任何堆栈或示例、这种情况就像我在 CC2530+2591上运行协调器固件一样、终端设备基于此 CC2530、它是第三方照明开关、  

"终端设备基于此 CC2530、它是第三方照明开关"是什么意思？ 如果第三方设备未响应、您应联系制造商。

实际上、我假设问题不在于终端器件、这里有3种不同的终端器件(2种来自 Siliconlabs、1种来自 TI)、所有终端器件的行为如何相似、这些产品我们已经集成并使用得很好。 如果需要、我将通过将所有3个终端设备与 Philips Hue 配对来发送跟踪。

我只是根据嗅探器日志来判断。 另一种可能是发送开/关命令时目标端点出现问题。

是的、可能与此类似、但我使用了它首次工作的同一目标端点。

您可以在发送开/关命令之前请求活动端点及其简单描述符、以确认您的应用程序是否使用了错误的端点。

我应该在 Z-tool 中使用什么命令来请求端点和描述符？

使用 ZDO_ACTIVE_EP_REQ 和 ZDO_SIMPLE_DESC_REQ

谢谢、让我检查一下