ROVER 2026年 Feb 4日 15:02

不是，我们是用sdk开发的

我是主要负责zigbee通讯部分的，网关与云端的时间同步交互我不是很熟悉，我帮你问了一下相关的同事，按我上一条回复描述的，就是只要网关正常联网，云端有过一次任意atop交互，云端返回的数据里有时间戳，网关就会完成自身的时间同步，不需要特意调用某个接口。

建议你们先检查下网关的联网是否正常，即是否可以与云端进行正常的通讯，如果交互是有的，再观察下网关日志里云端返回的时间戳具体内容是多少。
你也可以贴一份网关启动后的日志给我看看。

ROVER 2026年 Feb 4日 14:53

是的，看log就是[01-01 18:45:57:789 TUYA D]这样的，有什么接口我可以去设置时区吗

那这个现象就是吻合的

一般情况下网关的时间同步是在启动后，有atop交互时自动与云端下发的时间戳保持一致的，你可能得看看你们云端当前的时间是否正常？

另外，你们用的不是涂鸦成品网关吗？

ROVER 2026年 Feb 4日 14:39

我们上的是自己的云，好像没有网关id，抓包的时间是今天早上10点左右

那我不是很好判断当前网关的状态，你可以拿到网关日志吗
我比较怀疑是当前网关的时间就是1970年1月1号的，就是说当前网关本身也没有与云端完成时间同步

您好，麻烦提供下网关的id，还有您这个抓包的具体北京时间

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

ROVER 2025年 Aug 26日 18:37

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

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

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

（抓包的报文实在是太多了，过滤panid都卡了好久好久 /(ㄒoㄒ)/~_{，下次抓包可以抓小一点吗，日志可以多保留一些）}

根据您前面描述的复现的两种情况：
（1）网关收不到窗帘的回复，截图时间点为15：45：31，但是日志txt中没有包含该时段的日志，抓包过滤panid = 0x32CE，也没看到有控制报文下发，您可以提供更为明确的网关下发控制报文的时间点或者行数吗
（2）调用控制接口，但是网关不下发报文，时间点16:29:21， 日志里看到确实该时段所有报文均发送失败（tx 66）， 需要确认下ncp的发送功能是否已经完全卡死，单控是不是需要ncp重启才能恢复了？