【】設備端上報{"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這樣重連。