Tuya Developer Forum

还有想请问下，看抓包，每次网关收不到窗帘的回复，都有看到窗帘在不断的重发（这个可能是因为网关没回复窗帘），然后看抓包有看到窗帘在给网关发Network Status, Network Status Code:0x0C(Many-to-One Route Failure)有关系吗

ROVER 2025年 Aug 26日 18:37

还有想请问下，看抓包，每次网关收不到窗帘的回复，都有看到窗帘在不断的重发（这个可能是因为网关没回复窗帘），然后看抓包有看到窗帘在给网关发Network Status, Network Status Code:0x0C(Many-to-One Route Failure)有关系吗

此时窗帘与网关是直连的？还是通过某个中继节点连入网关的？
是否存在协调器或路由节点的路由表已满、路径不可达，同时观察下当前网络环境是否存在干扰或者硬件（例如天线）

另外，我想了解下，一次性控制多个开关的这个需求为什么不通过广播形式通知呀？

你好，从抓包看，窗帘和网关是直连的。
请问要怎么看协调器或路由节点的路由表已满、路径不可达这种情况
之所以没有使用广播形式，是考虑到不同设备的协议可能不同

还有前面有提到ncp的发送功能卡死的问题，这个我要如何确认呢

我把您上面提到的问题统一整理在这里哦

1. 关于要怎么看协调器或路由节点的路由表已满、路径不可达
   （1）sdk应该有提供路由表打印的接口，您可以通过打印网关内路由表、邻居表等信息查看当前的情况；
   （2）路径不可达可以观察抓包是否有route req之类的路由请求报文；
   2.ncp的发送功能卡死
   可以看下附近时间点，是否日志中有 tx 0 的打印，如果有就正常的，可以暂时不考虑这个因素

另外，我们最近在处理其他需求的时候，发现当ncp模组处于非常繁忙的时刻，环境中收包和发包都很多，确实会有概率出现下发失败的情况，分析是处于性能上限，我们目前通过重发机制优化这一问题，但是这可能就会导致下发操作的执行存在一定的延时。

您好，我们最近的压测中，有发现一个延迟发送的问题，就是我们调用了发送接口之后，发现包实际要经过10几秒以上才会发出去，我这边截取了两次出现该问题的log，麻烦帮忙分析一下。

从抓包上来看，我们有发现，在出现该问题时，一般伴随有网络中有设备在广播Link Status，然后网关似乎要处理完Link Status之后，才能继续收发包。或者是网关有收到NetWork Status，看抓包好像也要等处理完，网关才会继续收发包。

麻烦您帮忙分析下log。
log_219.txt中，我们看log是10-23 21:10:29.502控制发，但实际10-23 21:10:50.225才发出
log_316.txt中，我们看log是10-23 21:28:34.302控制发，但实际10-23 21:28:53.148才发出

好的，我们已经收到了您的反馈，等我们分析后再给您答复，请耐心等待

您好，

根据您提供的代码分析来看，send阶段各接口调用均正常，应用层也没有错误打印，延迟主要是产生在调用zigbee模组底层的send接口后，我们自己在压测阶段，也会出现类似的现象，推测为ncp模组数据量过大，缓冲处理不及时，目前暂时没有很好的解决方案，应用层的处理无法优化这个异常，此时已经达到了处理上限。如果后续有优化方案，我会及时告诉您的，或者您也可以保持关注sdk的升级。

备注： 日志里可以通过“ [af-main-common.c:931] Nodeid:0x8fb4, clusterId:0x0006, SUCCESS: tx 0. ” 这类打印日志判断发送实际结果为成功（mac层ack已回复）