一个关于小程序与单片机的通讯实例(TCP/IP)

　　前言

　　这是一个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。

　　启动流程

　　一、启动项目，tcp监听成功

　　二、运行com.myself.nettychat.tcptest.TCPTestClient(记得先改ip或端口，若是你有修改的话)

　　三、运行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: 【发送成功】

　　}

　　效果图

　　

　　

​