【物联网】使用ESP8266与云平台通信

|----------------|----------------------------|
| 基础指令 | |
| AT | 测试 AT 启动 |
| ATE | 开启或关闭 AT 回显功能 |
| AT+RST | 重启模块 |
| AT+RESTORE | 恢复出厂设置 |
| AT+GMR | 查看版本信息 |
| AT+CMD? | 查询当前固件支持的所有命令及命令类型 |
| | |
| WIFI指令 | |
| AT+CWMODE | 设置 Wi-Fi 模式（1为连接路由器模式） |
| AT+CWJAP | 连接 AP（即连接路由器站点） |
| | |
| MQTT指令 | |
| AT+MQTTCLEAN | 断开 MQTT 连接 |
| AT+MQTTUSERCFG | 设置 MQTT 用户属性 |
| AT+MQTTCONN | 连接 MQTT Broker（MQTT 代理服务器） |
| AT+MQTTSUB | 订阅 MQTT Topic |
| AT+MQTTPUB | 发布 MQTT 消息（消息长度略短，以字符串发送） |
| AT+MQTTPUBRAW | 发布 MQTT 消息（消息长度略短，以二进制发送） |

测试流程

将ESP8266设为连接WIFI模式
复制代码
```
AT+CWMODE=1
```
连接WIFI
复制代码
```
AT+CWJAP="YANG","12345678"
```

设置 MQTT 用户属性

复制代码

/************************************* 指令与参数说明 *************************************/
AT+MQTTUSERCFG=<LinkID>,<scheme>,<"client_id">,<"username">,<"password">,<cert_key_ID>,<CA_ID>,<"path">

<LinkID>：当前仅支持 link ID 0。
<scheme>：由于 ESP8266 内存限制，不支持 MQTT over TLS，即 <scheme> 只能取 1 或 6。
    1: MQTT over TCP；
    2: MQTT over TLS（不校验证书）；
    3: MQTT over TLS（校验 server 证书）；
    4: MQTT over TLS（提供 client 证书）；
    5: MQTT over TLS（校验 server 证书并且提供 client 证书）；
    6: MQTT over WebSocket（基于 TCP）；
    7: MQTT over WebSocket Secure（基于 TLS，不校验证书）；
    8: MQTT over WebSocket Secure（基于 TLS，校验 server 证书）；
    9: MQTT over WebSocket Secure（基于 TLS，提供 client 证书）；
    10: MQTT over WebSocket Secure（基于 TLS，校验 server 证书并且提供 client 证书）。
<client_id>：MQTT 客户端 ID，最大长度：256 字节。
<username>：用户名，用于登陆 MQTT broker，最大长度：64 字节。
<password>：密码，用于登陆 MQTT broker，最大长度：64 字节。
<cert_key_ID>：证书 ID，目前 ESP-AT 仅支持一套 cert 证书，参数为 0。
<CA_ID>：CA ID，目前 ESP-AT 仅支持一套 CA 证书，参数为 0。
<path>：资源路径，最大长度：32 字节。

/************************************* 使用示例 *************************************/
AT+MQTTUSERCFG=0,1,"设备ID","产品ID","之前生成的Token",0,0,""

连接 MQTT Broker（MQTT 代理服务器）

复制代码

/************************************* 指令与参数说明 *************************************/
AT+MQTTCONN=<LinkID>,<"host">,<port>,<reconnect>

<LinkID>：当前仅支持 link ID 0。
<host>：MQTT broker 域名，最大长度：128 字节。
<port>：MQTT broker 端口，最大端口：65535。
<reconnect>：
    0: MQTT 不自动重连；
    1: MQTT 自动重连，会消耗较多的内存资源。

/************************************* 使用示例 *************************************/
AT+MQTTCONN=0,"mqtts.heclouds.com",1883,1

订阅需要的主题

复制代码

/************************************* 指令与参数说明 *************************************/
AT+MQTTSUB=<LinkID>,<"topic">,<qos>

<LinkID>：当前仅支持 link ID 0。
<topic>：订阅的 topic。
<qos>：订阅的 QoS。

/************************************* 使用示例 *************************************/
AT+MQTTSUB=0,"$sys/{pid}/{device-name}/thing/property/post/reply",0  //订阅：云平台接收数据响应主题
AT+MQTTSUB=0,"$sys/{pid}/{device-name}/thing/property/set",0         //订阅：云平台下发数据主题

发布主题（以MQTTPUBRAW指令为例）与发布内容

复制代码

/************************************* 指令与参数说明 *************************************/
AT+MQTTPUBRAW=<LinkID>,<"topic">,<length>,<qos>,<retain>

<LinkID>：当前仅支持 link ID 0。
<topic>：MQTT topic，最大长度：128 字节。
<length>：MQTT 消息长度，不同 ESP 设备的最大长度不同：
    对于 ESP32 设备：最大长度受到可利用内存的限制；
    对于 ESP8266 设备，最大长度受到可利用内存和 MQTT_BUFFER_SIZE_BYTE 宏的限制。该宏的默认值为 512，可在 build.py menuconfig 中设置它的值，以此更改对最大长度的限制。该宏的值 = 消息的最大长度 + MQTT 报头长度（取决于 topic 名称的长度）。
<qos>：发布消息的 QoS，参数可选 0、1、或 2，默认值：0。
<retain>：发布 retain。

/************************************* 使用示例 *************************************/
AT+MQTTPUBRAW=0,"$sys/{pid}/{device-name}/thing/property/post",xx(要发送的字符串长度+2，因为有回车符和换行符),0,0      //发布：数据上报主题

AT+MQTTPUBRAW=0,"$sys/{pid}/{device-name}/thing/property/set_reply",xx(要发送的字符串长度+2，因为有回车符和换行符),0,0 //发布：数据下发响应主题

先使用发布主题指令后ESP8266将进入透传模式，此时再进行数据传输
每一次数据上报前都需要使用发布主题指令使ESP8266进入透传模式

/* 上报数据 */
{"id":"123","params":{"co_sensor_value":{"value":888},"error_state":{"value":1}}}

/* 响应：id要与云平台下发时的id保持一致 */
{"id":"7","code":200,"msg":"xxxx"}

三、遇到的问题

1.订阅了数据响应主题，数据上报后却没有收到云平台的响应

原因：没有正确订阅主题

解决方法：确保订阅的主题正确

2.统计发送长度需要+2

使用字符串统计工具获得需要发送的json格式的字符串长度之后需要+2，因为每条信息后都要有回车符和换行符

3.长时间不通信后的断连问题（⭐️）

问题描述：

当我一段时间没有发送任何指令时串口助手上出现"+MQTTDISCONNECTED:0"信息，此时上报数据出现"ERROR"，尝试重新连接云平台和MQTT服务地址也会出现"ERROR"信息，只有将esp8266复位后才能重新连接云平台和MQTT服务地址。
原因：

MQTT "保活"机制与平台断连

为了防止资源浪费，MQTT服务器会要求客户端在空闲时发送"心跳包"来维持连接。如果长时间没有通信，服务器就会判定设备离线并主动切断链路。收到的 +MQTTDISCONNECTED:0 信息，正是ESP8266模块检测到连接已被切断后给出的通知。

连接断开后的状态

虽然MQTT连接断了，但ESP8266模块内部维护这个连接的数据结构（会话信息），以及底层用于网络通信的TCP连接可能还在，并没有被系统及时回收。此时，模块处于一个"半残留"状态，它认为之前的连接还存在，所以当你尝试建立新连接时，就会发生冲突。

AT指令重连失败的原因

绝大多数AT指令集在设计上，都不支持在原有连接未彻底关闭时直接建立新连接。因此，当你再次输入 AT+MQTTCONN 指令，模块内部的协议栈检测到状态冲突，就会拒绝执行并返回 ERROR。

解决方法：

方案一：手动清除连接状态（推荐）

这是官方文档推荐的，也是最可靠的方法。在你打算重连之前，先发送 AT+MQTTCLEAN=0 指令，它会强制模块清理内部残留的MQTT会话信息。清理干净后，再重新执行 AT+MQTTCONN 等一系列指令来完成连接。

方案二：利用自动重连功能

在建立MQTT连接时，设置自动重连。将 AT+MQTTCONN 指令的最后一个参数设为1：

如果最后一个参数为 1：AT+MQTTCONN=...,1，通常会开启模块的"自动重连"功能。当连接因网络问题意外断开时，设备会尝试在后台自动恢复连接，无需干预。

如果最后一个参数为 0 或未指定：AT+MQTTCONN=...,0，则关闭自动重连。一旦断开，必须使用AT+MQTTCLEAN手动清理并重连，或者复位模块。

方案三：调整保活时间

如果你的应用场景允许设备频繁地与服务器通信，可以尝试缩短心跳间隔。在腾讯云，保活时间通常在30到1200秒之间。你可以登录腾讯云物联网控制台，检查一下设备的具体保活配置。如果设备意外断开，适当缩短这个时间能让平台更快检测到，但这并不能解决你遇到的重连报错问题。

补充问题：

都是执行一条AT指令，执行AT+MQTTCLEAN后也需要重新执行MQTT的初始化指令，为什么不选择执行AT+RST指令？

特性 AT+RST (软件复位) AT+MQTTCLEAN=0 (清理MQTT会话)

影响范围 全局复位 重启整个芯片，所有状态丢失（Wi-Fi连接、TCP连接、MQTT会话、GPIO状态等）。 局部清理 仅清理MQTT协议层的会话信息，不影响Wi-Fi连接和底层网络。

恢复过程 重且慢 1. 模块重启（约几百毫秒） 2. 重新连接Wi-Fi（数秒） 3. 重新配置MQTT参数 4. 重新连接MQTT服务器 轻且快 1. 发送 AT+MQTTCLEAN=0 (瞬间完成) 2. 重新配置MQTT参数（可选，若之前已配好可省略） 3. 重新连接MQTT服务器

对Wi-Fi的影响 会断开Wi-Fi 需要重新执行 AT+CWJAP 连接热点。 不会断开Wi-Fi （前提是Wi-Fi本身正常）节省了重新扫描、认证、获取IP的时间。

适用场景 - 模块出现严重异常（如无响应、看门狗复位） - Wi-Fi本身也断开了 - 你希望彻底重置所有状态。 - 仅MQTT连接断开 ，但Wi-Fi仍正常（常见于心跳超时） - 追求快速重连，减少设备离线时间 - 希望保留其他网络连接（如TCP socket）。

优先尝试MQTT自动重连（AT+MQTTCONN 最后一个参数设为1） ，如果不行则使用 AT+MQTTCLEAN 后手动重连 ，最后才考虑 AT+RST

特性	`AT+RST` (软件复位)	`AT+MQTTCLEAN=0` (清理MQTT会话)
影响范围	全局复位重启整个芯片，所有状态丢失（Wi-Fi连接、TCP连接、MQTT会话、GPIO状态等）。	局部清理仅清理MQTT协议层的会话信息，不影响Wi-Fi连接和底层网络。
恢复过程	重且慢 1. 模块重启（约几百毫秒） 2. 重新连接Wi-Fi（数秒） 3. 重新配置MQTT参数 4. 重新连接MQTT服务器	轻且快 1. 发送 `AT+MQTTCLEAN=0` (瞬间完成) 2. 重新配置MQTT参数（可选，若之前已配好可省略） 3. 重新连接MQTT服务器
对Wi-Fi的影响	会断开Wi-Fi 需要重新执行 `AT+CWJAP` 连接热点。	不会断开Wi-Fi （前提是Wi-Fi本身正常）节省了重新扫描、认证、获取IP的时间。
适用场景	- 模块出现严重异常（如无响应、看门狗复位） - Wi-Fi本身也断开了 - 你希望彻底重置所有状态。	- 仅MQTT连接断开，但Wi-Fi仍正常（常见于心跳超时） - 追求快速重连，减少设备离线时间 - 希望保留其他网络连接（如TCP socket）。