【求助】【网关】一次性控制大量设备，会概率出现有设备未被控制到

[ROVER]

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

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

[Kyson]

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

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

[Kyson]

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

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

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

[ROVER]

那这种情况要怎么规避呢，我们目前调用tuya_zigbee_send_data()这个接口去发送zigbee包，但是有概率在模组重启的过程中，这个包没有发出去，我们也没有收到接口返回的发送失败

[Kyson]

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

[ROVER]

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

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

[ROVER]

您好，能再麻烦帮忙看一下吗

[Kyson]

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

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

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

[ROVER]

如何知道什么时候应该重发呢，出现了NCP重启的情况下，我们并不知道是否有发送成功

[Kyson]

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