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/740432/cc2538-zcl-functional-command-results-in-surplus-discovery
每次我们通过 ZNP 执行 ZCL 函数命令时、我们都会看到一个额外的发现请求直接在之后发生。
请有人告诉我为什么会发生这种情况(是因为开发更改？) 以及是否可以禁用它。
示例的屏幕截图：
屏幕截图中显示了相关的数据包。 但这里是问题的 PCAP。
屏幕截图中的数据包40未通过 ZNP 接口(串行/UART)发送。 Z-Stack 出于某种未知原因发送了它。 我发送的唯一数据包是152。
在 OTA 过程中发送发现请求会持续影响 ED 的更新过程速度(至少将更新时间加倍)。
e2e.ti.com/.../new.zip
我们使用 Z-Stack 3.0.1 (包含所有建议的修复)并作为 Zigbee 网络处理器(ZNP)运行。
特定集群(在本例中为 OTA) 不相关。 我们看到其他群集的行为相同(例如 IAS)
我不是说问 TC Link 密钥。 我是指网络密钥。
新的捕获和网络密钥： 9F：55：95：F1：02：57：C8：A4：69：CB：F4：2B：C9：3F：EE：31
数据包 ID 13是我通过 ZNP 串行端口(MT 命令)发送的数据包。 我发送的下一条命令是35。 我在发送的软件 Z-Stack 中没有发送51 (也不需要)。
e2e.ti.com/.../discover_2D00_attributes.zip
您能告诉我们您注册端点0x0B 和0x01的方式吗？ 路由器正在向端点0x0B 发送映像块请求、发现属性来自端点0x01。
您是否正在使用适用于 ZNP 的主机处理器、或者您是否已设法修改 ZNP 应用并包含此端点？
感谢 Ryan 和 Jose。
昨天、我们在深入探讨调试器和许多断点后找到了原因。
事实证明、我们使用的用于与 ZNP 连接的库(Zigbee -牧羊人)是负责的、此通信在日志中不易重定位。 因此、我们的第一个假设是我们未传达发现请求、这是不正确的。 Z-Stack 100%无故障。
对于可能发现此问题的任何其他人、我们的补丁程序位于： github.com/.../eaa7860069461c8ab93de47c92b01465512a2ad3
