client_id为什么会变

您知道client_id为什么会变吗

好像每次新连接都会生成一个新的ID，不过我没用过Gateway，你可以@一下作者或者在群里面问问。

方便把群号发我吗

我的设备是一直处于上电状态，从打印日志来看，设备和Gateway的连接一直处于断开，重连，断开再重连的状态，请问这是因为我设备的通信不稳定导致的，还是gateway本身的机制导致的，又或者说是socket机制原因

平均多久断开重连一次？

一个小时左右

可能是没加心跳导致的连接断开，建议50秒一个心跳维持连接。心跳间隔不能超过一分钟

心跳是有的，所以正常情况下设备连接上gateway，其clientid基本就保持不变了是吗

clientid就是连接id，连接一直不断开就不变，断开就新生成一个clientid

我这边的设备每30分钟左右就会发送一次登录指令，现在的现象是第三次发送的登录指令连的clientid变了，然后因为设备的clientid变了，经过心跳时间后之前的clientid触发onclose

clientid变了只能说明客户端发起了新的连接，没有“因为clientid变了触发了onclose”这种因果关系。
至于为什么设备重新发起连接需要你们自己定位下，例如断电、断网、逻辑bug都有可能。
另外外网环境尤其是弱网环境，连接经常断开是很正常的事情，设备做好重连即可。

我这边的监控日志显示是clientid先变化的，从id1变成id2，然后经过两个心跳时长之后，大约两分钟，onclose里面打印到了之前的clientid信息id1

这种情况很常见，比如设备断电，服务端不会立刻感知到设备连接断开，需要心跳检测后才能判断设备的连接已经无效，导致延迟触发onclose。
再比如心跳间隔设置过长例如大于等于1分钟，连接可能会被路由节点或防火墙清除，导致服务端无法立刻感知连接已经清理，也是需要心跳检测，导致延迟触发onclose。
再比如设备没有关闭之前的连接，直接发起了新连接。服务端发现旧连接一直没有心跳，则判断连接断开，延迟执行onclose。
还有比如路由故障也会有类似效果。连接不是想象中的一方断开，另外一方肯定知道，很多情况下不知道需要心跳检测。

这个是tcp基础

好的，谢谢解答