简介这份资源是面向物联网、嵌入式方向毕业设计学生的完整参考方案围绕STM32主控、ESP8266 Wi-Fi模组、MQTT协议、OneNet云平台与UniApp微信小程序展开解决从传感器采集、云端通信到移动端可视化控制的整链路实现问题适合具备一定C语言与单片机基础、需要落地智能家居赛题或课程设计的读者。压缩包共297个文件约9.16MB以48个c源文件与48个h头文件构成STM32外设驱动与业务逻辑主体另有46个crf、46个o等编译中间文件、20张png界面截图、6个json与6个js等小程序工程文件以及uvprojx、uvoptx等Keil工程配置目录结构完整、便于直接编译与二次修改。目前已有998人学习下载。读者可据此掌握DHT11温湿度、光照、HC-SR501人体红外与LED、无源蜂鸣器的接入方式理解MQTT发布订阅与OneNet数据流转并参考UniApp小程序实现远程监控与控制对物联网全栈实践具有较高参考价值。1. 从零搭一套能跑的智能家居毕设STM32 采集、ESP8266 上云、UniApp 收数据如果你正在做物联网方向的毕业设计大概率绕不开这条经典链路STM32 负责采集温湿度、控制继电器ESP8266 负责联网MQTT 负责把数据推到云平台最后用 UniApp 写一个手机端界面把数据展示出来。这套方案之所以年年有人做不是因为它简单而是因为它把「端—管—云—用」四个环节全串了一遍答辩时每一层都有东西可讲。但真正动手你会发现坑不在写代码而在模块之间的协议对接、AT 指令的时序、MQTT 报文格式、云平台物模型的数据解析规则。这份资源包把 STM32 固件、ESP8266 联网配置、OneNet 平台接入参数、UniApp 前端页面打包在一起适合电子、物联网、计算机相关专业做毕设或课程设计的同学也适合想快速验证一套端到端方案的嵌入式新手。下面我按实际复现顺序拆一遍重点讲清楚每个环节的参数怎么设、哪里容易翻车。2. 硬件链路与通信选型为什么是 STM32 ESP8266 而不是直接上 ESP322.1 主控与联网模块的分工逻辑STM32 和 ESP8266 的组合看起来「多此一举」——ESP32 一颗芯片就能同时做采集和联网。但在毕设场景里这个组合反而有它的合理性。STM32 的 GPIO、ADC、定时器资源丰富跑裸机或 FreeRTOS 都稳适合接 DHT11、继电器、OLED 这些外设ESP8266 只负责一件事把串口收到的数据通过 MQTT 发出去再把云端下发的指令透传回串口。两者通过 UART 通信职责边界清晰调试时也能分段定位问题——数据不对先看 STM32 串口输出发不出去再看 ESP8266 的 AT 指令返回。常见做法是 STM32 用 USART2 接 ESP8266波特率 115200TX/RX 交叉连接ESP8266 的 CH_PD 拉高使能VCC 单独供 3.3V。注意 ESP8266 峰值电流能到 300mA 以上如果和 STM32 共用板载 LDO联网瞬间容易掉电复位现象是串口突然打印一堆乱码然后重启。我一般会单独给它一路 3.3V 稳压或者至少并一个 470μF 电解电容在模块电源脚附近。2.2 MQTT 协议在 OneNet 上的接入参数OneNet 支持 MQTT 接入但它的鉴权方式和标准 MQTT 略有差异。你需要先在平台创建产品、添加设备拿到三个关键参数产品 ID、设备 ID、鉴权信息通常是 API Key 或设备密钥。然后拼 MQTT 连接报文时ClientID 格式、Username 格式、Password 格式都有固定规则填错一个字段就是「连不上」但没有任何详细报错。以常见的 OneNet MQTT 旧版接入为例连接参数大致如下参数取值规则说明服务器地址mqtt.heclouds.com端口 1883 或 6002ClientID设备ID直接填设备 IDUsername产品ID填产品 IDPassword鉴权信息平台生成的 API Key发布主题$dp数据上报固定主题订阅主题$dp下行指令也走这个主题数据上报的 payload 是 JSON 格式字段名要和平台物模型里定义的标识符一致。比如你定义了一个「temperature」属性上报时就得是{temperature:25.6}写成{temp:25.6}平台收不到但 MQTT 层不会报错数据直接丢弃。这是最隐蔽的坑之一。2.3 UniApp 端的数据订阅方式UniApp 本身不能直接连 MQTT通常有两种做法一是通过 WebSocket 连 MQTT over WebSocket二是走 HTTP 轮询 OneNet 的 API 接口。资源包里如果用的是 WebSocket 方案前端需要引入 mqtt.js 或自己封装 WebSocket 心跳如果用 HTTP就定时请求 OneNet 的数据查询接口拿 JSON 解析后渲染。我一般建议毕设用 HTTP 轮询因为实现简单、调试直观虽然实时性差一点但答辩演示足够。轮询间隔设 35 秒太短容易触发平台限流太长页面数据看着像卡死。请求头里带 api-keyURL 里拼设备 ID 和数据流名称返回的 JSON 里data.current_value就是最新值。3. STM32 端固件拆解串口收发、JSON 拼包与继电器控制3.1 串口中断接收与环形缓冲区STM32 和 ESP8266 之间的串口通信是整个链路的第一段也是最容易丢数据的地方。ESP8266 返回的 AT 指令响应、MQTT 连接确认、下行指令都是不定长字符串如果用阻塞式HAL_UART_Receive读固定长度要么读不全要么把下一条数据截断。常见做法是用中断接收 环形缓冲区每收到一个字节就存进 buffer主循环里再解析。// 环形缓冲区定义 #define RX_BUFFER_SIZE 512 typedef struct { uint8_t buffer[RX_BUFFER_SIZE]; volatile uint16_t head; volatile uint16_t tail; } RingBuffer; RingBuffer esp_rx_buf; // 串口中断回调每收到一字节触发 void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART2) { uint16_t next (esp_rx_buf.head 1) % RX_BUFFER_SIZE; if (next ! esp_rx_buf.tail) { // 缓冲区未满 esp_rx_buf.buffer[esp_rx_buf.head] rx_byte; esp_rx_buf.head next; } HAL_UART_Receive_IT(huart2, rx_byte, 1); // 重新开启接收 } }这段代码的关键点是head和tail都用volatile修饰因为它们在中断和主循环里都会被修改。缓冲区大小 512 字节足够容纳一条完整的 MQTT 下行报文如果设成 64 或 128长报文会被截断现象是 JSON 解析到一半失败。另外每次中断回调里必须重新调用HAL_UART_Receive_IT否则只接收一次就停了。3.2 JSON 拼包与 AT 指令发送时序STM32 要把传感器数据发给 ESP8266通常有两种模式一种是 STM32 直接发 MQTT 报文需要自己实现 MQTT 协议栈另一种是 ESP8266 烧了 AT 固件STM32 用 AT 指令控制它发 MQTT。资源包大概率是后者因为实现门槛低。流程是先发ATCIPSTART建立 TCP 连接再发ATCIPSEND进入透传模式然后把 MQTT 连接报文和数据报文按字节发出去。// 拼装 OneNet 数据上报 JSON void send_sensor_data(float temp, float humi) { char json_buf[128]; // 字段名必须和平台物模型标识符一致 snprintf(json_buf, sizeof(json_buf), {\temperature\:%.1f,\humidity\:%.1f}, temp, humi); // 发送 AT 指令进入透传 uart_send_string(ATCIPSEND\r\n); HAL_Delay(100); // 等待模块返回 // 发送 MQTT PUBLISH 报文简化示意实际需拼完整报文头 uart_send_string(json_buf); HAL_Delay(50); }这里HAL_Delay的等待时间不是随便写的。ESP8266 从收到ATCIPSEND到返回提示符通常需要 20100ms如果延时太短直接发数据模块还没进入透传状态数据就丢了。但延时也不能太长否则主循环卡死传感器采集节奏被打乱。我一般会改成等待字符出现再发而不是固定延时这样更稳。3.3 继电器控制与下行指令解析下行指令从 OneNet 推到 ESP8266再通过串口传给 STM32。STM32 需要从环形缓冲区里提取出 JSON解析出控制字段然后操作 GPIO。常见做法是收到数据后先找{和}定位 JSON 边界再用简单的字符串匹配提取值。// 解析下行 JSON 中的继电器控制字段 void parse_downlink(uint8_t *data, uint16_t len) { char *p strstr((char *)data, \relay\); if (p ! NULL) { // 找到 relay: 后面的数字 p strchr(p, :); if (p ! NULL) { int state atoi(p 1); HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, state ? GPIO_PIN_SET : GPIO_PIN_RESET); } } }这段代码没有用完整的 JSON 解析库因为 STM32 资源有限引入 cJSON 会占几 KB Flash。对于只有一两个控制字段的场景字符串匹配足够用。但要注意strstr是区分大小写的平台下发的字段名如果大小写和代码里不一致匹配就会失败。建议在物模型定义时就统一用小写。4. ESP8266 固件与 OneNet 对接AT 指令、MQTT 报文与心跳4.1 AT 固件版本选择与联网配置ESP8266 的 AT 固件版本直接影响 MQTT 指令的支持程度。老版本只支持 TCP 透传MQTT 报文得自己拼新版本AT 1.2 以上内置了 MQTT 指令可以直接用ATMQTTUSERCFG、ATMQTTCONN这些命令。资源包如果带的是新固件配置流程会简单很多。联网配置的基本步骤发ATRST复位模块等待ready发ATCWMODE1设为 Station 模式发ATCWJAPSSID,PASSWORD连接热点等待WIFI GOT IP发ATMQTTUSERCFG0,1,设备ID,产品ID,鉴权信息,0,0,配置 MQTT 参数发ATMQTTCONN0,mqtt.heclouds.com,1883,1连接服务器每一步都要等模块返回OK才能发下一条如果上一条还没处理完就发下一条模块会直接返回ERROR或者不响应。我一般会在每条指令后加一个等待OK的超时判断超时就重试重试三次还失败就复位模块重新来。4.2 MQTT 连接报文字段详解如果用透传模式自己拼 MQTT 报文连接报文里几个字段必须和 OneNet 要求完全一致。ClientID 填设备 IDUsername 填产品 IDPassword 填鉴权信息。Keep Alive 建议设 60 秒太短会增加心跳流量太长平台可能判定设备离线。// MQTT CONNECT 报文简化拼装示意 // 固定头0x10 剩余长度 // 可变头协议名 MQTT 协议级别 0x04 连接标志 KeepAlive // 载荷ClientID Username Password uint8_t mqtt_connect_packet[] { 0x10, 0x2A, // 固定头剩余长度 42 字节示意值 0x00, 0x04, M, Q, T, T, // 协议名 0x04, // 协议级别 4 0xC2, // 连接标志用户名密码清理会话 0x00, 0x3C, // KeepAlive 60 秒 // 后面跟 ClientID、Username、Password 的长度和内容 };剩余长度字段是变长编码不是固定一字节。如果 payload 超过 127 字节剩余长度要用两字节表示很多人在这里翻车——报文发出去平台没反应抓包才发现长度字段算错了。建议直接用现成的 MQTT 库或者用 AT 指令内置的 MQTT 功能别手拼。4.3 心跳与断线重连机制MQTT 连接建立后如果长时间没有数据交互平台会断开连接。ESP8266 需要定期发 PINGREQ 心跳包或者定期上报一次数据。OneNet 的默认超时时间通常是 KeepAlive 的 1.5 倍设 60 秒的话90 秒内没有任何报文就会被踢。断线重连的逻辑要放在主循环里定期检查 ESP8266 是否还返回OK或者检测 MQTT 连接状态标志。如果发现断线先发ATMQTTCLEAN0清理旧连接再重新走一遍连接流程。注意不要频繁重连间隔至少 5 秒否则模块可能进入异常状态表现为 AT 指令全部返回ERROR只能硬件复位。5. UniApp 前端与云平台联调数据渲染、指令下发与常见对接问题5.1 页面结构与数据绑定UniApp 端的核心是一个实时数据展示页和一个控制页。数据展示用v-for渲染传感器列表控制页用switch组件绑定继电器状态。数据来源如果是 HTTP 轮询就在onLoad里启动setInterval每 3 秒请求一次 OneNet 的 API。// UniApp 中轮询 OneNet 数据接口 async fetchSensorData() { const res await uni.request({ url: https://api.heclouds.com/devices/${deviceId}/datapoints, method: GET, header: { api-key: apiKey // 平台生成的 API Key }, data: { datastream_id: temperature,humidity, // 数据流名称 limit: 1 // 只取最新一条 } }); if (res.data.errno 0) { const points res.data.data.datastreams; points.forEach(stream { if (stream.id temperature) { this.temperature stream.datapoints[0].value; } }); } }api-key放在 header 里不是 URL 参数放错了会返回 401。datastream_id多个用逗号分隔limit1只取最新值减少数据传输量。返回的errno为 0 才表示成功非 0 要看error字段排查。5.2 控制指令的下发路径UniApp 下发控制指令有两条路一是直接调 OneNet 的 HTTP API 发命令二是通过 MQTT 发到$dp主题。HTTP 方式简单但需要处理命令的 JSON 格式MQTT 方式实时性好但前端要维护 MQTT 连接。// 通过 HTTP API 下发继电器控制命令 async sendControlCommand(state) { const res await uni.request({ url: https://api.heclouds.com/cmds?device_id${deviceId}, method: POST, header: { api-key: apiKey, Content-Type: application/json }, data: { relay: state // 字段名要和 STM32 解析的一致 } }); if (res.data.errno ! 0) { uni.showToast({ title: 下发失败, icon: none }); } }命令下发后STM32 不是立刻就能收到。OneNet 先把命令缓存等设备下次上报数据或心跳时才把命令推下去。所以如果设备上报间隔是 10 秒你点开关后可能要等 10 秒才生效。想快就把上报间隔缩短或者用 MQTT 下行主题实时推。5.3 跨域与 HTTPS 证书问题UniApp 在 H5 端调试时请求 OneNet 的 HTTPS 接口可能遇到跨域。浏览器控制台报CORS policy请求被拦截。解决办法是在manifest.json里配置代理或者用 UniApp 的条件编译H5 端走本地代理App 端直接请求。// manifest.json 中配置 H5 代理 h5: { devServer: { proxy: { /api: { target: https://api.heclouds.com, changeOrigin: true, pathRewrite: { ^/api: } } } } }配置后请求地址改成/api/devices/...开发服务器会转发到 OneNet。注意这个代理只在开发环境生效打包上线后要么用 Nginx 反代要么直接请求App 端没有跨域限制。6. 避坑与排查从「连不上」到「数据不动」的六条血泪经验6.1 现象ESP8266 返回 ready 但 AT 指令全部 ERROR原因通常是波特率不匹配。ESP8266 出厂固件默认波特率可能是 74880 或 9600而 STM32 串口设的是 115200。模块能返回启动信息但后续指令解析不了。解决先发ATUART115200,8,1,0,0把模块波特率改成和 STM32 一致改完复位。如果当前波特率未知用 USB-TTL 逐个尝试 9600、74880、115200 去连连上后再改。6.2 现象MQTT 连接返回 CONNACK 但很快断开原因可能是 ClientID 重复。OneNet 同一设备 ID 同时只能有一个 MQTT 连接如果你在调试时开了两个串口工具同时连后连的会把先连的踢掉先连的又重连形成反复掉线。解决确保同一时间只有一个客户端在用这个设备 ID 连接。调试时关掉其他工具或者用不同的设备 ID 分别测试。6.3 现象数据上报成功但平台看不到原因大概率是 JSON 字段名和物模型标识符不一致。MQTT 层不校验 payload 内容平台收到后按物模型解析字段对不上就静默丢弃。解决在 OneNet 控制台打开设备的数据流列表看有没有新数据流生成。如果没有检查 JSON 里的 key 是否和物模型里定义的标识符完全一致包括大小写。6.4 现象继电器控制指令下发后设备无反应原因可能是命令下发路径不对。OneNet 的 HTTP 命令接口和 MQTT 下行主题是两条独立通道如果你用 HTTP 发命令但设备只订阅了 MQTT 主题命令就到不了设备。解决确认设备端订阅了$dp主题并且平台命令是通过 MQTT 下发的。如果用 HTTP 命令接口设备需要主动调用「获取命令」的 API 来拉取不是自动推送。6.5 现象UniApp 页面数据不更新原因可能是setInterval被页面生命周期打断。UniApp 的页面在onHide后定时器还在跑但onUnload后没清理导致内存泄漏或者请求堆积。解决在onUnload里clearInterval在onShow里重新启动定时器。另外检查请求是否被浏览器缓存加个时间戳参数t${Date.now()}绕过缓存。6.6 现象STM32 串口收到数据但解析乱码原因可能是环形缓冲区的读写指针没有正确处理溢出。当head追上tail时新数据会覆盖旧数据如果解析程序读得慢就会读到半截报文。解决在中断里判断缓冲区满时丢弃新数据还是覆盖旧数据根据场景选。解析程序要按报文边界读不要按固定长度读。可以在缓冲区里找\r\n或{}来定位完整报文。7. 进阶技巧用物模型对齐和本地缓存把联调效率提上去这套方案跑通之后真正花时间的不是写代码而是联调时反复改字段、重启设备、等平台刷新。我后来养成一个习惯先在 OneNet 控制台把物模型定义好导出成一张对照表STM32 的 JSON 拼包、UniApp 的字段绑定、平台的数据流名称全部按这张表来谁都不许自己改名。这张表长这样功能物模型标识符数据类型STM32 变量UniApp 字段温度temperaturefloattemp_valuetemperature湿度humidityfloathumi_valuehumidity继电器relayboolrelay_staterelay有了这张表联调时任何一端数据不对直接对着表查五分钟定位。另一个技巧是在 STM32 端加一个本地缓存传感器数据先存到数组里ESP8266 联网成功后再批量补发最近几条。这样即使网络短暂断开平台上的数据曲线也不会断档。补发时注意加时间戳OneNet 支持在 JSON 里带timestamp字段不带的话平台按收到时间算补发的数据时间会乱。还有一点调试阶段别急着把设备装进外壳。我见过太多人焊好、装壳、上墙之后才发现某个传感器读数偏高拆下来重调的成本远大于裸板多放两天。裸板跑至少 24 小时观察数据有没有跳变、掉线后能不能自动重连、继电器频繁开关会不会导致复位。这些稳定性问题在答辩现场翻车一次后面讲得再好也救不回来。从那以后我每次做类似项目都会强制让设备裸板连续跑两天再收尾希望这个习惯也能帮到你。本文还有配套的精品资源点击获取