一个关于小程序与单片机的通信实例(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。

  启动流程

  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: 【发送成功】

  }

  效果图

  


  


转载于:https://juejin.im/post/5be554afe51d45244470c316

你可能感兴趣的:(一个关于小程序与单片机的通信实例(TCP/IP))