前言
这是一个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列表
请求Iot中心,获取当前连接存活状态下的链接实例
{
"code": 200,
"msg": "成功",
"data": 1
}
请求Iot中心,当前存活状态下的链接Id列表
{
"code": 200,
"msg": "成功",
"data": [
"F5690137563CC8"
]
}
参数
- channelId //第二个API获取到的链接Id
- lock //将要打开的第几把锁 1-24(看单片机接入的锁的数量)
{
"code": 200,
"msg": "成功",
"data": "【发送成功】"
}