【】设备端上报{"Content":"Publish message to topic:/a1yYDYMf6Fw/GZDD-MQTT-T1-002/user/get,QoS=0","Reason":"No authorization"}，这种问题就是topic权限对应权限不对，发布和订阅注意一些，如果是自定义topic，设备端订阅过了，那么设备上行到这个topic，云端会下发一条，这里平台的机制就是基于mqtt机制做的。
【】设备端上报struct类型，一般很多客户不知道数据格式或者在调试里面应该如何使用，这里有一个技巧，这个struct类型，数据格式上报一个就知道，在虚拟调试里面，{"ss":{"t1":1,"t2":2}}
【】设备离线状态怎么获取，如何能检测到并传到客户自己开发的后端，，两种方式，一种是通过服务端订阅，订阅实时的设备行为变化，以里面的lastTime字段去维护设备最终状态。
另外一种是调云端api，GetDeviceStatus获取设备状态，不过这个是建立再心跳机制上的。
【】常见设备离线场景：
1.TCP长连接断开，解决：检查设备端网络，本身设备端做好重连机制：MqttConnectOptionsc.setAutomaticReconnect(true)
2.心跳超时，解决：MQTT连接心跳时间为30秒至1,200秒。心跳时间不在此区间内，服务器将会拒绝连接。建议取值300秒以上。如果设备端网络较差，值相对可以设置的大一些。
3.设备互踢，两种情况
1.设备和物联网平台的连接是基于mqtt协议的，假设设置的心跳时间是300s，那么只有超过心跳时间后，平台还没有收到设备端发送的心跳包，才认为设备离线。
如果在300s内，网络恢复，您的设备重新上线（也就是说设备本来离线，平台这边还是认为在线的，因为没有到300s），那平台就认为被同一台设备挤下线了，所以显示kicked by the same device
2.同一组三元组信息两个或以上设备同一时间连接，这个连接被踢掉了。
在使用sdk，设备出现这种情况，会立即自动重连 1s 2s 4s这样重连。