中移M5311型号NBIoT模组MQTT开发记

背景

• 因需要NBIoT模组，采用MQTT协议连接自有服务器，之前使用安信可的N92模块，因为开发到最后发现有负载字节长度限制，不满足实际负载上行数据的长度，所以重新选了这个M5311模组来开发。
  因为模组支持MQTT协议，所以直接采用AT指令进行数据命令交互通信，这种方式也是最简单，开发最快的。
  如下截图，乃是其AT指令手册的MQTT有关的AT指令篇。
  

• 在此前开发使用了多款不同的通信模块之后，也知道其无非分为这几个步骤：

  • 1.等待模块初始化；
  • 2.注册激活网络
  • 3.MQTT连接参数配置
  • 4.MQTT登陆连接请求
  • 5.MQTT主题订阅
  • 6.MQTT消息推送发布（主任务）
  • 7.MQTT网络状态监测（闲任务）

• 如下面一些注册登录指令操作步骤

/*上电等待模块初始化完成，会打印如下信息*/
*ATREADY: 1
+CFUN: 1
+CPIN: READY

/*MQTT参数配置*/
/*注：字符串参数在此不需要用引号*/
AT+MQTTCFG=iot.123.com,1883,214,300,username,passwords,0,0
--> OK
/*登陆连接服务器（此指令也兼具了网络注册激活），所以此省略上述（2）步骤*/
/*+MQTTOPEN: OK 才代表登陆连接成功，其不会立马响应，应该与网络状况有关，
所以刚发送的即回的OK是不能作为成功标志,如果是+MQTTOPEN: FAIL,则需要尝试重发再连接*/
AT+MQTTOPEN=1,1,0
--> OK
-->+MQTTOPEN: OK
/*订阅主题*/
/*最后一个参数，是代表订阅主题的格式，0代表是填入的是文本格式*/
AT+MQTTSUB="theme/device/air/a",0,0
--> OK
/*推送数据*/
/*注：文档有言：下面第四个0的位置代表的是负载数据的长度（即{"123456"}的长度），
若缺省或者直接填0，代表的是发送的格式是text文本格式，有填具体长度值，
则代表负载数据是hex类型*/
/*发送文本{"123456"}*/
AT+MQTTPUB="theme/device/air/all",0,0,0,0,{"123456"}
--> OK
/*发送hex数据0x12,0xe5,0xf4*/
AT+MQTTPUB="theme/device/air/all",0,0,0,3,12E5F4
--> OK
/*再注:上面发送的是text文本数据，所以Json格式的数据在这个不能直接负载发送
AT负载发送不能识别而报错，所以需要将数据转为HEX数据发送,
如发送Json数据：{"status":"modify","object":"myip"}
则需要转为:7b22737461747573223a226d6f64696679222c226f626a656374223a226d796970227d
AT+MQTTPUB="theme/device/air/all",0,0,0,35,7b22737461747573223a226d6f64696679222c226f626a656374223a226d796970227d

/*断开服务器*/
AT+MQTTDISC
--> OK
-->+MQTTDISC:OK;/*成功断开服务器*/

另外在实际测试中发现，若拔掉天线后，而导致与服务端失联，此时使用AT+MQTTSTAT?查询网络状态，回应的AT状态值依旧是MQTTSTAT：+5，但是实际已经失联，推送几次数据之后，虽然AT回应OK,但事实上并没有成功发送到服务器，而且推送几次之后，然后再推送AT已经报错。
通常为避免设备与服务器实际处于连接状态，再重新连接服务器，而发生报错，所以一般先回发送一下断开服务器指令，但这个就不行。
然后我再次重新接上天线，想观察是否会自动连上，但依旧没有，此时只有重新发送 AT+MQTTOPEN=1,1,0 指令，则可以恢复正常，可正常推送数据，所以这算不算是这个模块的一个Bug呢？

另外，在拔掉天线使用AT+CSQ查询信号指令时，其实信号值已经为0。

所以若想做一个设备因信号短暂恶化而导致与服务器失联，此时启动自动重连的机制时，这里会有一个坑点，就是没有一个网络掉线的良好参考点。

若使用AT+CSQ的值来参考，则不清楚csq恶化到何值才会表明设备已经与服务器断开。

因还在继续，先写至此。