简介：基于STM32C8T6与ESP8266的实时环境监测系统设计完整工程包，面向嵌入式初学者、STM32开发者和物联网爱好者，也适用于毕业设计、课程实验、学科竞赛等场景，解决环境参数采集、本地显示与云平台远程监控的核心问题。压缩包共278个文件，总大小约7.87MB，核心内容包含C源码、H头文件、Keil工程（.uvprojx）、编译生成的AXF/HEX烧录文件，以及工程备份、说明文档等，可直接打开工程编译烧录，并支持后续二次开发。系统集成DHT11温湿度、MQ-2可燃气体、GY302光照传感器，经0.96英寸OLED屏实时显示，支持串口与蓝牙透传交互，并通过ESP8266以MQTT协议接入OneNET平台，实现数据上云与远程查看。资料内的代码均经过功能验证，还提供面包板加杜邦线的简易硬件搭建方案，便于初学者快速复现；完整工程结构也可作为项目开发、实验报告、竞赛答辩的重要参考。已有105人浏览学习。
1. 实时环境监测系统：为什么这条“STM32采集+ESP8266上云+OneNET展示”链路最省事
做实验室温湿度记录、小型温室监控或者车间烟雾报警时，基于STM32与ESP8266接入OneNET平台的实时环境监测系统设计是目前最典型的一条链路：STM32把传感器数据采回来，ESP8266把数据送上网，OneNET把数据存起来再画成可视化曲线。整套方案不需要自建服务器，也不用维护数据库，手机和浏览器打开就能看实时值，硬件成本几十块钱。它特别适合做毕业设计、课程设计，或者给产品做功能原型验证。我按这个方向完整搭过一遍，下面把硬件选型、驱动代码和平台接入参数一次讲透，你不用再来回翻十几篇帖子。
2. 硬件架构与选型：从传感器到云端的器件清单和引脚规划
2.1 数据流向：DHT11/MQ-2 采集在 STM32，传输在 ESP8266
这套系统的数据流其实很短：传感器输出物理量，STM32通过GPIO或ADC把物理量读成数字，拼成一段JSON文本，然后通过串口把JSON交给ESP8266，ESP8266以MQTT协议发布到OneNET云平台，平台侧再按字段名拆成温湿度、烟雾浓度数据流，供可视化图表调用。
这里有个常见的理解误区：很多人以为ESP8266自己也能读传感器，为什么非要让STM32先采一遍？原因是ESP8266的GPIO少、ADC精度差，而且它的WiFi协议栈和用户代码跑在同一颗芯片上，读取DHT11这种对时序敏感的设备时很容易被网络中断干扰，导致读到的数据偶发跳变。STM32做主控，ESP8266只做数据透传，两边职责分开，系统稳定性会好很多。工程文件里最常见的组织方式也是这么划分的：STM32工程负责传感器驱动、数据组包和串口收发，ESP8266只跑AT固件。
2.2 器件清单与选型理由：为什么是 STM32F103 + ESP8266 而不是 51 或 W5500
具体器件我按最常见、最容易买到的来列。绝大多数毕设和原型验证用的是一块STM32F103C8T6核心板，也就是常说的BluePill。这颗芯片主频72MHz、Flash 64KB、RAM 20KB，跑两个串口加一个ADC、一个GPIO时序采集完全够用，价格也便宜。赶上活动十几块钱就能拿到，而且HAL库代码可以直接移植到F103系列其它型号。
WiFi模块我推荐ESP8266-01S或ESP12F。前者引脚少、体积小，适合毕设这种固定场景；后者天线性能更好，适合经常挪动的设备。如果对成本不敏感、又想省掉AT指令的调试麻烦，也可以直接给ESP8266刷NodeMCU固件让它在内部跑MQTT，但那就不是今天这套“STM32+AT指令”的框架了。顺带提一句，如果现场有网线，用W5500硬件协议栈接入OneNET也是成熟方案，但W5500是纯TCP协议栈，MQTT报文还需要自己在单片机上拼，比ESP8266走AT指令要抽象得多，不建议新手入门直接上。
传感器部分我选了DHT11和MQ-2，覆盖温湿度和可燃气体浓度三个环境指标，足够撑起一个“实时环境监测”的演示。DHT11精度一般但便宜、资料多，适合入门；MQ-2是模拟量输出，接STM32的ADC引脚就能读。如果还想测光照，加一个BH1750走I2C，代码模式类似，不改变整体架构。
2.3 接线表与 3.3V 供电规划：ESP8266 峰值电流不容忽视
下面这张接线表是我自己习惯用的引脚分配，和大多数源码工程的默认工程文件一致，你可以直接照抄。注意串口一定要交叉连接：STM32的TX接ESP8266的RX，STM32的RX接ESP8266的TX。
| 模块 | 引脚 | 接到 STM32F103C8T6 |
|---|---|---|
| ESP8266-01S | VCC | 3.3V（独立供电，不直挂板载LDO） |
| ESP8266-01S | GND | GND（与STM32共地） |
| ESP8266-01S | RX | PA2（USART2_TX） |
| ESP8266-01S | TX | PA3（USART2_RX） |
| ESP8266-01S | CH_PD/EN | 3.3V（使能引脚必须拉高） |
| DHT11 | DATA | PB12 |
| MQ-2 | AOUT | PA0（ADC1_IN0） |
| MQ-2 | DOUT（可选） | PA1，用于阈值报警 |
供电是整个系统翻车率最高的地方。ESP8266在WiFi发射瞬间峰值电流可以冲到300mA以上，如果直接把它的VCC接到核心板上那颗小小的LDO后面，电压一旦掉到3.3V以下，模块就会重启、串口打印乱码、AT指令无响应。我一般用一个AMS1117-3.3单独给ESP8266供电，或者用手机充电头加DC-DC模块，但无论怎么供，都必须和STM32的GND共地，否则串口电平完全没有参考点，通信必定失败。
3. STM32 端传感器采集：DHT11 驱动、ADC 采样与 JSON 拼接
3.1 DHT11 温湿度读取：时序、信号宽度与校验代码
DHT11的驱动难点不在通信协议本身，而在时序。它是单总线设备，主机先把总线拉低至少18ms，然后释放，DHT11会回一个80us左右的低电平响应，接着连续发送40位数据，每一位都以50us低电平开始，后面高电平的持续时间决定它是0还是1。高电平26~28us是0，70us是1。主控必须在这几十微秒内完成采样判断，所以用HAL_Delay肯定不行，需要微秒级延时。
我这里的工程文件里用DWT内核定时器做微秒延时，比for循环空转精确，也不受编译器优化影响。下面这段是完整的读取函数：
/* dht11.c - 基于 STM32F103 HAL 库 */ #include "dht11.h" #define DHT11_PORT GPIOB #define DHT11_PIN GPIO_PIN_12 /* 初始化 DWT 延时，在 main 里调用一次 */ void DWT_Delay_Init(void) { CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk; } static void delay_us(uint32_t us) { uint32_t start = DWT->CYCCNT; uint32_t ticks = us * (SystemCoreClock / 1000000UL); while ((DWT->CYCCNT - start) < ticks); } /* 读取 DHT11，成功返回 1，失败返回 0 */ uint8_t DHT11_Read(float *temperature, float *humidity) { uint8_t data[5] = {0}; uint8_t bits[40] = {0}; GPIO_InitTypeDef gpio = {0}; /* 配置为开漏输出，外部上拉，拉低至少 18ms 触发 DHT11 */ gpio.Pin = DHT11_PIN; gpio.Mode = GPIO_MODE_OUTPUT_OD; gpio.Pull = GPIO_PULLUP; HAL_GPIO_Init(DHT11_PORT, &gpio); HAL_GPIO_WritePin(DHT11_PORT, DHT11_PIN, GPIO_PIN_RESET); HAL_Delay(20); HAL_GPIO_WritePin(DHT11_PORT, DHT11_PIN, GPIO_PIN_SET); /* 切换为输入模式，等待 DHT11 响应 */ gpio.Mode = GPIO_MODE_INPUT; gpio.Pull = GPIO_PULLUP; HAL_GPIO_Init(DHT11_PORT, &gpio); delay_us(30); if (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET) { return 0; /* 没有低电平响应 */ } while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_RESET); while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET); /* 读取 40 位数据：低电平 50us 后，高电平宽度决定 0/1 */ for (int i = 0; i < 40; i++) { while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_RESET); delay_us(28); bits[i] = (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET) ? 1 : 0; while (HAL_GPIO_ReadPin(DHT11_PORT, DHT11_PIN) == GPIO_PIN_SET); } for (int i = 0; i < 5; i++) { for (int j = 0; j < 8; j++) { data[i] = (data[i] << 1) | bits[i * 8 + j]; } } /* 校验：前四个字节累加和等于第五字节 */ if ((uint8_t)(data[0] + data[1] + data[2] + data[3]) != data[4]) { return 0; } *humidity = (float)data[0]; *temperature = (float)data[2]; return 1; }代码里最关键的是读取每一位时的delay_us(28)。这个28us是判断0和1的分水岭：采样点放在高电平开始后的第28us，如果读到高电平说明高电平持续超过28us，这一位是1；如果是低电平，说明高电平已经结束，这一位是0。你把采样点放到40us也能工作，但越往后越容易被干扰，这是我调过不少板子之后的血泪经验。
另外注意GPIO要配成开漏输出。DHT11数据线空闲时靠上拉电阻维持高电平，开漏模式可以避免推挽输出时两片芯片互相打架。如果你的板子外部没有上拉电阻，就在PB12和3.3V之间焊一个4.7kΩ电阻，这点别省。
3.2 烟雾传感器 ADC 采集：通道切换与滑动平均滤波
MQ-2传感器上电后，内部加热丝需要几十秒才能稳定，刚上电读到的电压会持续漂移。它的模拟输出接在PA0上，对应ADC1的通道0。STM32F103的ADC是12位，参考电压取3.3V，所以读到的原始值乘以3.3再除以4095就是电压。浓度越高，输出电压越高，但我不建议大家拿这个电压直接当线性浓度，MQ-2的灵敏度曲线本身就不是线性的，实际工程里要用标定数据做查表或拟合。毕设演示时，直接把电压值报上去即可，说明里讲清楚单位是电压就能过。
ADC读取时有个很容易踩的坑：多通道切换。如果你只是静态读PA0，每次转换前调用一次HAL_ADC_ConfigChannel就行，但如果你后面加了PA1读取另一个通道，必须注意——先HAL_ADC_Stop停掉上一次转换，重新配置通道后再HAL_ADC_Start。我见过不少人在STM32 ADC切换通道上翻车，表现是切换通道后读到的值一直不变，其实就是上一次转换没有停止，ADC还在按旧通道转换。
/* 读取 MQ-2 电压，连续采 10 次滑动平均，返回单位：V */ float MQ2_ReadVoltage(void) { ADC_ChannelConfTypeDef sConfig = {0}; uint32_t sum = 0; sConfig.Channel = ADC_CHANNEL_0; sConfig.Rank = ADC_REGULAR_RANK_1; sConfig.SamplingTime = ADC_SAMPLETIME_239CYCLES_5; HAL_ADC_ConfigChannel(&hadc1, &sConfig); for (int i = 0; i < 10; i++) { HAL_ADC_Start(&hadc1); if (HAL_ADC_PollForConversion(&hadc1, 10) == HAL_OK) { sum += HAL_ADC_GetValue(&hadc1); } HAL_ADC_Stop(&hadc1); HAL_Delay(2); } return (sum / 10.0f) * 3.3f / 4095.0f; }这里的HAL_ADC_Stop在每次采样后都调用，就是为了避免上面说到的通道“粘连”问题。采样时间我选239CYCLES_5，对高内阻的传感器输出更稳一点。如果你用的是PA1做数字量报警输出，那不需要ADC，直接配一个GPIO输入，读高低电平就完事。
3.3 把温湿度、烟雾值拼成 JSON：缓冲区设计与发送接口
数据采回来之后，要拼成OneNET能识别的JSON字符串。这里建议用一个全局字符数组做缓冲区，不要每次在栈上开大数组，因为STM32的栈空间本来就紧张。我一般开128字节，格式如下：{"temp":26.3,"hum":60.2,"smoke":0.45}。浮点格式化成一位小数，省空间也够看。
/* data_report.c */ extern UART_HandleTypeDef huart2; extern void ESP8266_Publish(const char *topic, const char *payload); char mqtt_payload[128]; void Report_EnvData(float temp, float hum, float smoke) { int len = snprintf(mqtt_payload, sizeof(mqtt_payload), "{\"temp\":%.1f,\"hum\":%.1f,\"smoke\":%.2f}", temp, hum, smoke); if (len > 0 && len < (int)sizeof(mqtt_payload)) { ESP8266_Publish("$dp", mqtt_payload); } }注意snprintf的返回值需要做边界判断，如果返回负数或超过缓冲区大小，说明数据格式出错，这时候直接丢弃这一帧，不要让半截JSON发到云端。OneNET解析JSON是按字段名匹配数据流的，哪怕你少了一个右括号，整个数据点都会解析失败，平台侧就会显示设备在线但没有数据。这会在后面的避坑章节里再细说。
4. 接入 OneNET 云平台：创建产品设备、MQTT 连接与数据上报
4.1 在 OneNET 控制台创建产品与设备：三个关键参数到手
在OneNET云平台上，接入流程是先在控制台创建一个产品，再在产品下添加设备。以老版OneNET开放平台的多协议接入为例，进入控制台后找到“多协议接入”，选择MQTT协议，创建一个新的产品。创建成功后你会拿到一个产品ID，也就是product_id。然后在产品下添加设备，设备类型选择“MQTT协议”，注册方式可以选手动。设备添加成功后，控制台会显示设备ID（device_id）和APIKey（api_key）。
这三个参数就是后面MQTT连接的三个身份凭证。有的教程里还会让你配置一个token，新版OneNET Studio的鉴权方式和老版不太一样，但连接公式是同一个套路：服务器地址、端口、设备ID、用户名、密码。区别只在密码字段怎么算，老版直接填api_key，新版可能要求填token签名。你以自己控制台“设备详情”页显示的信息为准，代码框架不用变。
一个建议：在控制台把产品里的“数据流”提前规划好。比如你上报的JSON里有temp、hum、smoke三个字段，就在数据流模板里分别建这三个名字，字段名必须和JSON的key完全一致，大小写都不能差。这个不强制，但先建好数据流，后面可视化面板拉图表时会省很多事。
4.2 给 ESP8266 准备带 MQTT 功能的 AT 固件并初始化网络
ESP8266买回来默认的AT固件不一定会带MQTT指令。乐鑫的AT固件是从ESP8266 NONOS开发环境编译出来的，版本不同，支持的指令集也不同。老版本AT固件只有AT+CIPSTART、AT+CIPSEND这些TCP/IP指令，要发MQTT报文得自己拼协议包，非常痛苦。我建议你刷一个带MQTT指令的AT固件，例如基于NONOS SDK 2.2.0编译的AT 2.2.0以上版本，用AT+GMR查看版本号，确认返回信息正常后再继续。
初始化网络时的指令很简单，但要注意几个参数细节：
// 设置为 Station 模式，连接路由器 AT+CWMODE=1 // 连接 WiFi，注意 SSID 和密码都要 ASCII 字符 AT+CWJAP="TP-LINK_TEST","12345678" // 查询本机 IP，确认已拿到地址 AT+CIFSRAT+CWMODE有三个值：1是Station（连接外部路由器），2是SoftAP（自己开热点），3是双模式。我们这边必须用1。AT+CWJAP连接成功后，模块会主动上报WIFI CONNECTED和WIFI GOT IP，然后再返回OK。如果你的路由器开了5GHz频段，或者开启了AP隔离、MAC过滤，都会导致连接失败，这点放到避坑章节里讲。
4.3 跑通 MQTT 连接与数据上报：AT 命令序列和 STM32 发送函数
WiFi通了之后，接着就是MQTT连接。OneNET的MQTT接入地址是老平台常用的183.230.40.40，端口1883。连接指令格式如下：
AT+MQTTCONN=0,"183.230.40.40",1883,"device_id","product_id","api_key",60这个命令里，第一个0是链路ID，固定用一个就行；device_id是控制台里的设备ID；product_id是产品ID；api_key是设备APIKey；最后一个60是MQTT心跳周期，单位秒。OneNET要求客户端定期发送心跳保活，60秒是常见配置。连接成功后返回OK，这时OneNET控制台里设备状态会变成“在线”。
连接成功后，上报数据用发布命令，主题填$dp，这是老版OneNET接收数据点的特殊主题：
AT+MQTTPUB=0,"$dp","{\"temp\":26.3,\"hum\":60.2,\"smoke\":0.45}",0,0注意$dp主题里JSON的引号在AT指令中要么用反斜杠转义，要么按下面代码里我的做法，把payload转成十六进制字符串发送，避免引号和逗号被AT指令解析器截断。这个坑很多人踩过，表现为串口调试助手能看到命令发出去，但OneNET平台收不到数据点。
STM32侧我封了一个通用发送函数：
/* esp8266.c - STM32 通过 USART2 与 ESP8266 通信 */ #include <stdio.h> #include <string.h> #include "usart.h" extern UART_HandleTypeDef huart2; /* 发送一条 AT 命令，等待 "OK" 返回，超时退出 */ uint8_t ESP8266_SendCmd(const char *cmd, uint16_t timeout_ms) { uint8_t rx_buf[128]; uint16_t rx_len = 0; uint32_t start = HAL_GetTick(); HAL_UART_Transmit(&huart2, (uint8_t *)cmd, strlen(cmd), 200); while (HAL_GetTick() - start < timeout_ms) { if (HAL_UART_Receive(&huart2, &rx_buf[rx_len], 1, 20) == HAL_OK) { rx_len++; if (rx_len >= 127) break; rx_buf[rx_len] = '\0'; if (strstr((char *)rx_buf, "OK") != NULL) return 1; if (strstr((char *)rx_buf, "ERROR") != NULL) return 0; } } return 0; } /* 将字符串转成十六进制字符串，用于 MQTTPUB 数据段 */ static void StrToHex(const char *src, char *dst) { const char hex[] = "0123456789ABCDEF"; while (*src) { *dst++ = hex[(*src >> 4) & 0x0F]; *dst++ = hex[*src & 0x0F]; src++; } *dst = '\0'; } void ESP8266_Publish(const char *topic, const char *payload) { char cmd[256]; char hex_buf[128]; StrToHex(payload, hex_buf); snprintf(cmd, sizeof(cmd), "AT+MQTTPUB=0,\"%s\",%d,0,0,%s\r\n", topic, (int)strlen(payload), hex_buf); ESP8266_SendCmd(cmd, 3000); }代码里的StrToHex就是避开引号转义的关键操作。AT+MQTTPUB的长格式是<linkID>,<topic>,<data_len>,<qos>,<retain>,<data>，data_len用原始payload字节数，data用十六进制串。这个格式在带MQTT指令的AT固件上都是支持的，比直接拼JSON进去稳得多。
4.4 云端命令下发：订阅主题与数据解析思路
OneNET云平台下发命令是环境监测系统里容易被人忽略的一块。比如温度超标时，你想让平台远程控制一个继电器或风扇，就需要ESP8266订阅某个主题来接收下行消息。在老版OneNET上，平台下发的数据会通过MQTT主题推给设备，设备侧要先订阅这个主题，然后解析收到的消息。
乐鑫AT固件里订阅命令格式如下：
AT+MQTTSUB=0,"topic_name",0STM32收到数据后，在串口中断回调里判断+MQTTSUB开头的异步消息，再把内容拆出来。这里我建议的做法是：收到数据先放一个环形缓冲区，主循环里再解析，不要在中断里做耗时操作。命令下发的实际主题名在OneNET控制台产品“Topic”页里可以看到，不同版本平台差异比较大，但订阅和收包的流程是通用的。毕设阶段，能把上行数据流跑通、可视化面板看到曲线，再做一个下行命令控制LED亮灭，这套系统的完整度就很高了。
5. 调试避坑与排查：五类翻车现场的现象、原因与解决方案
5.1 供电不足导致 ESP8266 反复重启、串口乱码
现象：按下电源键后，系统开始几秒工作正常，然后ESP8266指示灯突然熄灭，串口打印乱码，或者AT指令时好时坏。拿万用表量ESP8266的VCC，发现电压一直在3.0V到3.3V之间跳。
原因：ESP8266发射WiFi信号时电流峰值接近300mA，核心板板载LDO的压降和散热能力不够，电流一上来电压就崩。
解决：给ESP8266独立供电，用AMS1117-3.3从5V输入转出3.3V，或者在ESP8266的VCC和GND之间跨接一个470uF电解电容，再并一个100nF瓷片电容，只有共地线接STM32的GND。注意独立供电芯片的输入端别跟STM32的3.3V串在一起，否则等于没隔离。
5.2 AT+MQTTCONN 返回 ERROR：先分清是固件还是参数问题
现象：STM32串口指令窗口里发AT+MQTTCONN=0,"183.230.40.40",1883,"device_id","product_id","api_key",60，模块立刻回ERROR，不是OK。反复检查设备ID和APIKey都没问题。
原因：常见的不是参数错，而是ESP8266的AT固件压根不支持MQTT指令，或者服务器地址和端口填写与平台实际要求不匹配。老版本AT固件不识别AT+MQTTCONN，会直接当成非法指令返回ERROR。
解决：先用PC串口助手单独连接ESP8266，输入AT+GMR查看固件版本，如果输出里没有MQTT相关字段，先刷带MQTT功能的NONOS SD版本固件。然后手工输入AT+MQTTCONN验证刚才的地址端口和参数，一条一条排除。不要一上来就怀疑STM32代码，很多时候串口助手先能调通，问题就出在固件。
5.3 WiFi 连接不稳定：2.4G 信道、天线位置与重连机制
现象：AT+CWJAP经常连不上，或者连接成功后几十秒自动断开，ESP8266的IP地址消失。
原因：ESP8266只支持2.4GHz频段，如果你手机开了5GHz热点，或者路由器启用了“Smart Connect”把2.4G和5G合并成一个SSID，ESP8266可能反复在信道之间跳动。另外ESP8266-01S用的是PCB天线，靠金属外壳、电机或者液晶屏太近都会掉线。
解决：路由器单独开一个2.4G SSID，信道固定到1、6或11，关闭AP隔离和“WiFi增强”类功能。天线尽量悬空。STM32程序里要做掉线重连，不要启动时连一次就完事，主循环里定期用AT+CIICR或者轻量AT+CIPSTATUS检查链路状态，断线后重新走一遍CWMODE→CWJAP→MQTTCONN。
5.4 DHT11 数据跳变或恒为 255：时序细节和上拉电阻的玄学
现象：温度读数一直在正常值和65、255之间跳，或者DHT11刚上电读一次正常，后续全都失败。用示波器看数据线，波形上升沿明显变缓。
原因：数据线过长、没有上拉电阻、或者主控在读取过程中被中断打断。STM32的HAL库定时器中断、串口中断如果和DHT11的40位数据读取重叠，某一位的采样点就会错判。至于恒为255，这通常是校验失败后我在代码里返回了初始值，你看到255要意识到是读取失败而不是传感器坏了。
解决：数据线控制在10cm以内，4.7kΩ上拉电阻必须加，读DHT11时临时关闭可屏蔽的中断。更稳妥的做法是连续读三次，取三次都成功的中间值，或者至少两次一致的读数再使用。我在工程文件里就写了“三次读取投票”的逻辑，你如果嫌麻烦，至少也要做一次失败重试。
5.5 OneNET 设备在线但看不到数据点：$dp 主题与 JSON 映射
现象：OneNET控制台显示设备已经在线，但数据流页面一个点都没有，可视化曲线是空的，请求数据API也返回空列表。
原因：这几乎是老版OneNET最容易踩的坑。很多人在AT指令里直接把数据发到了自定义topic，但OneNET的数据点接收必须走$dp这个特殊主题，而且payload必须是规范JSON，字段名要和控制台数据流名称一致。缺少右括号、字段名写成大写、用了单引号，都会静默失败，平台不会给你报错。
解决：先把AT指令里topic确认成$dp，然后在本地串口助手手动发一次完整JSON，形如{"temp":26.3,"hum":60.2,"smoke":0.45}，立刻去控制台看数据流有没有新增数据点。如果有，问题在程序里JSON拼装；如果没有，把payload改成纯ASCII数字再试，逐步缩小范围。还有一个隐蔽问题：如果你的AT指令用了十六进制格式，十六进制串里不能有多余空格，我见过有人生成的hex串每个字节之间加了空格，OneNET收到后整条解析失败，这个只靠眼睛很难看出来，建议打印原始串排查。
6. 验证链路与进阶玩法：先手工打一遍 AT 命令，再上整机联调
整个系统联调我建议按“三段式”验证，不要一上来就把STM32、ESP8266、OneNET三方同时跑起来，出了问题根本不知道在哪一段。
第一段，PC上用USB转TTL接ESP8266，串口助手波特率115200，手工输入AT+CWJAP和AT+MQTTCONN，确认WiFi和MQTT都能通。第二段，用同一个串口助手下发AT+MQTTPUB，发一条手工拼好的JSON，去OneNET控制台看数据流是否新增数据点。第三段，再把STM32的USART2接上，让STM32串口打印出它发出去的AT指令和收到的响应，对比前两段的手工指令，看哪一步不一致。
这个三段式看起来多花了半小时，但能帮你把“硬件问题、固件问题、代码问题”切成三类来定位。我现在的习惯是每次做这种联网项目，先在串口助手里把链路敲通，再写STM32代码，最后才讨论软件逻辑。特别是MQTT这类带状态的协议，一旦AT固件版本或平台参数换了一个，前面的经验全部清零，手工验证几乎是唯一可靠的排错手段。
进阶方向有几个值得玩：一是用OneNET的触发器功能，温度超过阈值时平台主动发邮件或推送，这个在控制台界面就能配，不写一行代码。二是用平台的数据可视化面板把温度、湿度、烟雾浓度三条曲线关联合并成一张实时大屏，这也是OneNET可视化最常用的卖点。三是如果你后面做产品化部署，把ESP8266换成ESP32模块，代码里只需要改串口速率的AT指令和WiFi配置，传感器驱动和JSON拼装逻辑完全不用动，因为ESP32也兼容乐鑫AT指令集。
最后提醒一点：MQTT心跳参数别设太短，有些固件把心跳设成10秒反而会被平台判定为频繁连接而踢下线。我一般设60秒，既保活又不打扰服务端。这套系统做下来，你会对“采集、传输、平台解析”整条数据链路有非常清晰的感觉，以后再接LoRa、NB-IoT或者别的云平台，其实就是把中间这一段换掉而已。希望这篇笔记帮到你少走几步弯路。
本文还有配套的精品资源，点击获取
