scanway_lin 2026年 Jan 21日 18:30

还有存在丢数据的问题，云端已经下发了，设备端没有收到。虚拟ID:6cbca909df269e3940jhto 设备日志如附件

丢数据大概的原因也是一样的，下发的间隔太快，看后台大概好像是 300ms 左右，这个对于 seg 分段消息可能是不够的，而且这个也受限于网关的性能的，你这个网关是 wifi 蓝牙 二合一的，性能相对是较弱的

移除网关后通过手机蓝牙控制，如果只有一个节点的话会走直连控制，GATT 直连控制速率以及成功率都是很高的。
但是通过网关是通过 adv 广播通信，对于 seg 分包数据，下发与上报延时都会相对比较大，所以如果在快速控制时，延时与丢包是肯定存在的。（看后台日志你们在控制 涂抹调色(dpId : 51 ; dpCode : paint_colour_data) 这个数据时，下发的间隔太小了）

scanway_lin 2026年 Jan 21日 16:44

目前替换了aes-ccm.c，还是会重发数据，虚拟ID:6c0d47ac06cd1743a9b5dq 如下：

这里的重传也有可能是网关业务层的重传，在下发数据后如果未收到设备回复，会重新下发。这种重传在设备的日志中是能够看到的。
因为下发与上报都是长包，可能时间一长会触发网关的超时重传策略，所以这里如果使用前面说的高级能力中的带 TID 下发的话则会对此场景有优化

scanway_lin 2026年 Jan 21日 16:44

目前替换了aes-ccm.c，还是会重发数据，虚拟ID:6c0d47ac06cd1743a9b5dq 如下：

这里只看到了上报数据，下发数据看不到，能不能把手机断一下 wifi，可能连了局域网，看不到下发日志。通过外网控制后，对比下发的日志对比看下

请替换压缩包内的 aes-ccm.c 文件到 3.9.0 sdk 中，主要问题为原厂 3.13 sdk 前期版本中 seg ack 消息解密问题导致的分段消息多次重传（同时目前你使用的这个网关是瑞昱原厂协议栈，对 seg 重传的重放过滤策略不完整所以导致了多次上报，我试了其他网关是会将多余的消息过滤掉，当然如果 6222 源头解决这个问题，对你现在使用的网关也影响不会很大，可能偶尔会多一次上报）
另外这期间也修复过其他问题，一并更新下压缩包内其他文件。

替换一下这个 lib

再试一下看是否还有这个问题

或者日志能多抓一点吗，我看前面的控制都是一发一回比较正常的，到了
2026-01-21 10:45:34:748 埋点指令下发 收藏(dpId : 101 ; dpCode : favorite) 54565251504f4e
这次之后才出现了日志里多次上报的问题