前言
这是一个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
项目：InChat-tcp-wechat
项目介绍：针对小程序与单片机硬件执行Iot物联网通讯(TCP/IP)的一套完整Demo。
启动流程
1、启动项目，tcp监听成功
2、运行com.myself.nettychat.tcptest.TCPTestClient(记得先改ip或端口，如果你有修改的话)
3、运行PostMan，请求下方的API 进行通信测试
API列表
http://localhost:8080/susu/back/get_channel_sizeGET
请求Iot中心，获取当前连接存活状态下的链接实例
{
code: 200,
msg: 成功,
data: 1
}
http://localhost:8080/susu/back/get_channel_id_listGET
请求Iot中心，当前存活状态下的链接Id列表
{
code: 200,
msg: 成功,
data: [
F5690137563CC8
]
}
http://localhost:8080/susu/back/send_to_channelPOST
参数
channelId //第二个API获取到的链接Id
lock //将要打开的第几把锁 1-24(看单片机接入的锁的数量)
{
code: 200,
msg: 成功,
data: 【发送成功】
}
效果图