前言
這是一個18年初的創業項目的核心功能要求，我們當時打算做一個共享類的項目，項目的主題是共享圖書，線下的形式租借圖書，我們當時是考慮做一個借書櫃的形式，然后線下生產投放借書櫃，這些借書櫃本身能存放24本書，大約24個櫃子，且均有單片機控制。
用戶通過掃碼借書櫃上的二維碼，可以直接看到共享小程序里面的，針對這個借書櫃的當前存在的圖書，如果有用戶喜歡的圖書，那么用戶可以直接點擊小程序選擇借書，那么這是小程序需要向后台發起API請求，由后台針對對應的借書櫃的單片機進行通信，下發指令要求單片機打開對應該書的櫃子。
大致步驟
后台構建
我選擇用netty，當時使用的SSM的后台系統，不過最近一次整理我采用了SpringBoot+Netty來配合，我需要讓單片機與netty能夠正常的通信且是在業務功能正常執行的情況下。
團隊的嵌入式工程師選用了簡易的TCP/IP協議來通訊，且自己構建了電路板來控制對應的24把鎖。
通訊協議
幀頭+ID+數據類型+24把鎖狀態+crc校驗+幀尾
這里介紹一下，幀頭與幀尾是后台與單片機之間通訊的協議，我們使用普通的字符串來通訊，而通訊的過程中字符長度是固定的，幀頭與幀尾都是自擬定的2個字符。
對於ID可能要介紹一下，這里是每一個單片機的身份證，因為對於每一個鏈接，netty都會生成一個自己的全局隨機ID，這是不易於管理的。所以我們在生產的時候，后台就會對每個借書櫃的單片機的通訊Id進行控制，固定的字段與唯一的標識，這有助於后台的管理，也能立馬保證該借書櫃的狀態。
數據類型是針對業務而言的，我們的業務是需要控制類型、經緯度傳輸、設備電量、開關異常、報警等等，后台在獲取到對應的數據類型的時候，就會進行對應的操作。
假如是控制類型的話，那么后面的24個字符就是對應的24把鎖的狀態，o表示開啟、f表示關閉。
crc校驗是方便雙方做更深一層的校驗與安全防護，我們采用了CRC16的方式，校驗值都是4位。
心跳的保持是netty自身自帶的。
netty操作
在netty鏈接實例的過程中，我會對鏈接進來的實例的第一次通訊進行以下操作，其實應該說每次都會進行的，通訊協議檢測，正如上文說到的，幀頭、幀尾、CRC校驗。
在這一流程校驗正常后，我將獲取到他們的ID，我會立馬將netty原先為它生成的隨機ID進行替換，轉換成我們定義的ID，並將其存儲到系統內部的連接池中，以鍵值對的形式。
小程序API
在Controller層，我只需要去操作我們定義好的連接池，比如獲取連接數、鏈接ID列表，甚至向鏈接發送開鎖信息。
GitHub
項目介紹：針對小程序與單片機硬件執行Iot物聯網通訊（TCP/IP）的一套完整Demo。
啟動流程
1、啟動項目，tcp監聽成功
2、運行com.myself.nettychat.tcptest.TCPTestClient （記得先改ip或端口，如果你有修改的話）
3、運行PostMan，請求下方的API 進行通信測試
API列表
http://localhost:8080/susu/back/get_channel_size GET
請求Iot中心，獲取當前連接存活狀態下的鏈接實例
{
"code": 200,
"msg": "成功",
"data": 1
}http://localhost:8080/susu/back/get_channel_id_list GET
請求Iot中心，當前存活狀態下的鏈接Id列表
{
"code": 200,
"msg": "成功",
"data": [
"F5690137563CC8"
]
}http://localhost:8080/susu/back/send_to_channel POST
參數
- channelId //第二個API獲取到的鏈接Id
- lock //將要打開的第幾把鎖 1-24（看單片機接入的鎖的數量）
{
"code": 200,
"msg": "成功",
"data": "【發送成功】"
}效果圖
