⼀个关于⼩程序与单⽚机的通信实例（TCPIP）
前⾔
这是⼀个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、运⾏ptest.TCPTestClient （记得先改ip或端⼝，如果你有修改的话）
3、运⾏PostMan，请求下⽅的API 进⾏通信测试
API列表
:8080/susu/back/get_channel_size GETtcpip协议最高层是哪一个
请求Iot中⼼，获取当前连接存活状态下的链接实例
{
"code": 200,
"msg": "成功",
"data": 1
}
:8080/susu/back/get_channel_id_list GET
请求Iot中⼼，当前存活状态下的链接Id列表
{
"code": 200,
"msg": "成功",
"data": [
"F5690137563CC8"
]
}
:8080/susu/back/send_to_channel POST
参数
channelId //第⼆个API获取到的链接Id
lock //将要打开的第⼏把锁 1-24（看单⽚机接⼊的锁的数量）
{
"code": 200,
"msg": "成功",
"data": "【发送成功】"
}
效果图

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。