没有上报就要重发，这个跟NCP重不重启没关系的。重发机制自行设计，比如下发后 1s 没收到上报，重发一次，接着 10s 重发，再 10s 重发，只要收到数据就取消重发。

不影响，这是上报的，你前面的问题是入网。

ROVER 2024年 Nov 15日 17:44

我们有使用涂鸦网关，通过场景一次性去控制大量的设备，测试下来并没有出现有设备没被控制的情况，想请问下这是为什么，是sdk有优化了这个问题，还是我们使用的涂鸦网关的模组的性能优于我们自己开发的网关吗。

我们的涂鸦网关的型号是TYGWZ-02N

SDK和涂鸦网关使用的相同组件和分支，理论上表现是一致的。你这个是本地控制的吧？本地控制没有重传机制，通过涂鸦 App 控制有重传，你们可以加入重发规避。NCP 重启问题，还是要你们自己测试，下发加延时。

一般控制不会出现这种情况的，除非你是控制批量设备，批量控制建议走 Zigbee 群组或者场景，不建议单控。批量设备单控，需要加延时，需要测试验证取一个合适值。

txt 的 log 日志没有 sdk 相关的哦，需要提供下对应的 sdk 日志。

看日志是扫描到了，也触发了回调。

ROVER 2024年 Nov 13日 09:24

ROVER 2024年 Nov 6日 11:50

您好，我们的开发与芯科的技术支持那边分析说，可能是涂鸦模组收到多包时，重启了造成网关sdk uart退出重新初始化，能从这个方向帮忙分析一下吗

您好，这个能再帮忙分析一下吗

这个前面说过了，芯科Host的串口数据CRC校验失败，对模组进行重启。这是正常的，问题在于太多空中包，模组性能有限，太多空中包会导致模组处理不过来。

ROVER 2024年 Nov 6日 13:35

是用的逻辑分析仪，但是一直是一条直线，没有波形

没有波形是正常的，表示发送处于就绪状态，只有串口数据拥塞了触发流控了才会变。

要用逻辑分析仪抓