简介一套完整的STM32物联网智能家居安防系统毕业设计资源包面向物联网、嵌入式方向的毕业生和开发者覆盖从硬件驱动、无线与OneNET云平台通信到微信小程序控制、语音识别、触摸屏交互的全链路方案。资源共一百八十个文件核心代码以C源文件和头文件为主并附带Keil工程配置文件、可烧录的hex文件、Word说明文档、位图界面图片及原理图相关文件压缩包仅1.81MB目录清晰适合按模块逐项研读。已有七百二十五人学习下载。内容不仅包含温湿度、气体与人体红外等传感器数据采集还实现了短信警报、语音播报、掉电保存等安防细节触摸屏二级页面涵盖闹钟、音乐、阈值设置、环境监测等七大功能可直接作为毕设源码参考、功能扩展基础或论文配套材料。1. 一主一从一云一端这套安防系统到底在解决什么问题STM32 做实时采集和本地判断ESP8266 负责联网OneNET 云平台做数据中转微信小程序当远程遥控面板。这个组合几乎是物联网安防类项目里最稳妥的一套骨架本地逻辑不会被网络抖动拖累云端和客户端都不需要维护长连接哪怕家里 WiFi 断了报警逻辑依旧在单片机上独立跑。很多人一上来就想着用单芯片接 WiFi 接传感器结果传感器数据采集和网络协议栈抢资源报警响应被挤到几秒之后安防系统就失去意义了。本文按「硬件分工 → 本地逻辑 → 接入 OneNET → 小程序与告警联动 → 触摸屏与调试验证」这条主线展开用过 STM32 和 ESP8266 但没跑通全链路的人能在这里拿到可直接改的通信协议、关键代码和排查顺序。2. 系统架构与选型主控为什么是 STM32ESP8266 为什么只搭桥2.1 先拆数据流一次入侵报警从传感器到手机要经过哪几跳安防系统的核心指标是「从事件发生到云端收到数据」的时延。一次完整的报警链路是传感器电平变化触发 STM32 外部中断CPU 在中断服务函数里做软件去抖和状态判断然后通过 USART 把经过封装的帧发给 ESP8266ESP8266 跑着 AT 固件收到数据后立刻拼 HTTP POST 请求推到 OneNET小程序轮询或订阅到新数据后再弹通知。从这个链路能看出分工原则STM32 是唯一的逻辑决策者ESP8266 只做串口透传加协议转换不参与任何安防判断。模块职责边界接口方式STM32F103C8T6传感器采集、布防状态机、报警输出GPIO/ADC/USARTESP8266-01SWiFi 连接、HTTP 上报、命令下发透传USART AT 指令OneNET 云平台数据存储、API 鉴权、命令下发通道HTTP/MQTT微信小程序远程查看状态、语音提醒、触摸开关wx.request 轮询选 STM32F103C8T6 而非 ESP32 做单芯片方案原因是安防逻辑对中断响应和 IO 稳定性有要求。ESP32 的 FreeRTOS 和 WiFi 协议栈本身就占了不少中断资源跑 Arduino 框架时很容易出现 WiFi 重连瞬间 GPIO 采样丢一拍。STM32 用标准库或 HAL 库裸机跑外部中断响应是微秒级的DHT11 这种单总线协议用定时器模拟时序也更好控。ESP8266 选 -01S 而不是 NodeMCU 开发板是为了把天线位置独立布置避开 STM32 的晶振和电源走线干扰实际测试中 PCB 板载天线的 NodeMCU 在金属外壳里信号衰减非常明显。2.2 OneNET 作为中转站的核心价值设备接入与 apiKey 鉴权机制OneNET 在整个方案里不是简单存数据它承担了三件本地服务器很难做的事一是设备身份管理二是在线状态心跳三是把设备的 HTTP 上报自动落成数据流。接入 OneNET 之前必须先理解它的两级结构产品Product下面挂设备DeviceAPIKey 分为产品级和设备级。产品级 APIKey 可以管理该产品下所有设备设备级 APIKey 只能操作对应设备实际项目建议用设备级 Key避免一个 Key 泄露后整个产品被打穿。创建产品和设备时关键参数是「设备接入协议」和「鉴权信息」。如果是 ESP8266 走 HTTP 上报选「HTTP 接入」鉴权信息填自己定义的字符串后面上报时要在 URL 里带device_id在 Header 里带api-key。OneNET 有个和很多云平台不一样的细节新建设备后并不会立即出现在设备列表里需要等设备第一次上报数据成功后才会激活这个机制经常让人误以为建失败了实际上只要上报返回 200 就说明鉴权通过。2.3 小程序端为什么不需要自建服务器很多人担心微信小程序必须配后端服务器才能拿到设备数据。OneNET 提供了北向 HTTP API小程序可以直接用wx.request带 apiKey 拉取数据流把 OneNET 当成后端。这个方案省掉了 ECS 和域名备案代价是 apiKey 会暴露在小程序代码包里所以必须用设备级 Key 且只开放只读接口对应的权限。敏感操作比如撤防用 OneNET 的命令下发接口小程序只负责调 API具体能不能执行由 STM32 侧确认。这种「终端直连云平台、云端 API 做授权」的模型在物联网原型里是最常见的低成本跑通路径。3. STM32 端采集与安防状态机所有判断都在本地完成3.1 外设选型与引脚分配先避开冲突再谈功能传感器选型和引脚分配是 STM32 项目里最容易被低估的一步。安防场景下四类传感器是标配DHT11 或 DS18B20 测温湿度、HC-SR501 人体红外检测入侵、MQ-2 烟雾浓度检测火情、火焰传感器监测明火。DHT11 用单总线占用一个普通 GPIOMQ-2 输出模拟量要走 ADCHC-SR501 是数字电平输出这三类接口完全不同。触摸屏如果是淘晶驰这类串口屏又占一路 USART。整机引脚分配建议按下表做避免中断优先级和复用冲突外设接口类型推荐引脚注意点DHT11单总线 GPIOPA0需 4.7kΩ 上拉时序要求严格MQ-2ADCPA1上电预热 30s前 3s 采集值会虚高HC-SR501GPIO 输入PA2默认延时 3s需要硬件调电位器改短蜂鸣器GPIO 输出PA3用三极管驱动不能直接接 IOESP8266USART2PA2/PA3USART2 复用避开调试串口串口屏USART3PB10/PB11用支持中断接收的串口PA2/PA3 和 USART2 的默认引脚冲突这是新手最容易翻车的点。HC-SR501 输出如果直接默认占 PA2就导致 USART2 没法用。我一般把 HC-SR501 移到 PA4蜂鸣器移到 PA5跳线一次能省掉半天排错时间。另外注意 ESP8266 的 RX 不能直接接 STM32 的 TX两者电平都是 3.3V 但 ESP8266 的 RX 对噪声更敏感中间最好串一个 1kΩ 电阻这个电阻能兜住 STM32 上电瞬间的 IO 毛刺否则很容易出现 ESP8266 烧进去但一上电就崩固件的情况。3.2 温湿度与烟雾采集代码骨架单总线时序和 ADC 稳定策略DHT11 的读取代码看起来是读数据其实是「精确延时」的功夫。STM32 主频 72MHz 下用delay_us函数模拟读时序起始信号要拉低至少 18ms然后释放并等待传感器应答。读每一位时高电平持续 26~28μs 为 070μs 为 1。代码骨架如下uint8_t DHT11_ReadByte(void) { uint8_t i, byte 0; for (i 0; i 8; i) { while (DHT11_PIN_READ() 0); // 等待低电平结束 delay_us(40); if (DHT11_PIN_READ() 1) { byte | (1 (7 - i)); // 高电平超 40us 判定为 1 while (DHT11_PIN_READ() 1); // 等待高电平结束 } } return byte; }这段代码的关键在delay_us(40)这个阈值。40μs 位于 0 和 1 两种脉宽的中间值能容忍一定程度的时钟误差。实际项目里不要直接调这个 40而是用逻辑分析仪看波形确认传感器实际输出的高电平宽度再微调。MQ-2 的浓度读取用的是 ADC 连续采样三次取中值避开第一次采样的偏大值因为 MQ-2 内部加热丝在加电瞬间会干扰电导率测量。3.3 布防/撤防状态机防误报的关键是去抖窗口和报警确认安防系统最怕的不是不报警而是误报。HC-SR501 对热源移动敏感猫、窗帘飘动都可能触发。所以状态机里要有两个核心机制触发确认窗口和撤防睡眠延时。人体红外检测到高电平后不立即报警而是置一个pending_trigger标志连续 500ms 内再次确认高电平才进入报警状态。500ms 是经过现场实测折中的值——太短挡不住瞬时干扰太长会让真实入侵漏报。蜂鸣器报警同时通过 USART2 向 ESP8266 发送EVT类型帧内容包含事件编号和时间戳。typedef enum { DISARM, ARM, ALERT, ALERT_RELEASE } SecurityState; void Security_Update(void) { if (PIR_Read() HIGH) { if (state ARM pending_ticks 0) { pending_ticks 500 / 10; // 10ms 调度周期500ms 窗口 } else if (state ARM pending_ticks 0) { if (--pending_ticks 0) { state ALERT; Buzzer_On(); SendFrame(EVT, 0x01, NULL); // 向 ESP8266 发送入侵事件 } } } else { pending_ticks 0; } }状态机在安防系统里不是花架子它决定了报警后如何复位。实际中可以设定报警持续 30s 后自动回到 ARM 状态或者触摸屏上手动消警后回到 ARM。如果不做状态迁移限制报警后传感器恢复低电平立刻再次触发蜂鸣器就会变成持续蜂鸣既消耗电流又无法区分多次入侵事件。3.4 串口帧协议STM32 与 ESP8266 之间的数据边界STM32 和 ESP8266 之间最重要的是一个稳定的串口帧协议。最常踩的坑是两个模块发送速度不匹配ESP8266 还在上一次 AT 指令的响应阶段STM32 已经把下一帧发过来了。帧格式建议定义成帧头0xAA 0x55、类型字节、数据长度字节、数据区、CRC 校验。ESP8266 收到完整帧后自己解析再决定拼 HTTP 请求体还是执行本地命令。CRC 用简单的累加和就可以安防场景的数据量不大没必要上 CRC16。4. ESP8266 接入 OneNET从 AT 配置到数据上下行全通4.1 先让 ESP8266 本身工作正常波特率、工作模式和透传ESP8266 刷 AT 固件后上电默认波特率是 115200第一次用串口助手连时如果显示乱码先检查是不是 USB-TTL 的供电不稳定。用杜邦线接开发板时ESP8266 峰值电流能到 300mA普通的 CH340 模块拉不动表现为模块偶尔能响应 AT 但一连接 WiFi 就重启。解决方法是给 ESP8266 单独供电GND 和 STM32 共地。基础配置命令序列如下ATRESTORE ATCWMODE1 # 1: Station 模式连接路由器 ATCWJAPSSID,PASSWORD # 接入家庭 WiFi ATUART_DEF9600,8,1,0,0 # 重设波特率为 9600与 STM32 匹配 ATSAVETRANSLINK1,119.161.52.90,80,TCP # 可选开机自动 TCP 连接注意ATRESTORE会清空所有配置包括波特率。如果先设置了波特率再ATRESTORE模块会回到自适应波特率模式反而容易乱码。正确的顺序是上电后先ATRESTORE恢复出厂再设置工作模式和 WiFi最后改波特率。ATSAVETRANSLINK是透传模式的开机自动连接选项实际项目里我建议不用这个功能因为在固定 TCP 连接下如果服务器端重启ESP8266 不会自动重连。更稳妥的做法是 STM32 侧做心跳检测发现 ESP8266 掉线后主动重启它。4.2 OneNET 设备创建与 APIKey 生成三条必须记牢的参数在 OneNET 控制台创建产品时产品行业选「智能家居」联网方式选「WiFi」设备接入协议这一步要选对。如果走 HTTP 上报选「HTTP」如果后面想用 MQTT 做命令下发也可以直接在创建时选「MQTT」协议不同APIKey 的获取位置和上报格式也不同。创建完设备后会得到三样东西device_id、api-key、鉴权信息。HTTP 方式鉴权信息填在 Header 里MQTT 方式鉴权信息就是用户名和密码的一部分。生成 APIKey 后有个容易混淆的点OneNET 控制台里产品详情页的「APIKey」和每个设备详情页里的「APIKey」内容不一样。设备级 Key 以具体设备为粒度产品级 Key 以产品为粒度。小程序端拉数据走的是「获取设备数据流」这个 API必须得设备级 Key 才能看到数据点。测试时可以先用串口助手模拟 STM32 给 ESP8266 发 AT 指令看 OneNET 返回的 HTTP 状态码200 表示数据点写入成功401 表示 Key 错误404 表示设备 ID 或数据流名称不存在。4.3 HTTP 上报ESP8266 拼 JSON 数据的完整命令序列HTTP 接入 OneNET 上报数据点的核心是 POST 请求到/devices/{device_id}/datapoints请求体是 JSON 数组。ESP8266 没有原生 JSON 库需要在 STM32 侧拼好完整字符串再透传。上报温湿度和烟雾浓度的命令序列如下ATCIPSTARTTCP,api.heclouds.com,80 # 等待 CONNECT 返回 OK 后执行下面三条 ATCIPSEND196 POST /devices/527663123/datapoints?type3 HTTP/1.1 Host: api.heclouds.com api-key: 设备级Key Content-Length: 78 {datastreams:[{id:temp,datapoints:[{value:26.3}]},{id:humi,datapoints:[{value:58}]}]}ATCIPSEND的参数 196 是往后所有要发送字符的精确总数包括 HTTP 行、Header 的空行、请求体的长度。数错一个字符就导致服务器端解析失败返回 400。实际项目中这个长度是动态变化的所以 STM32 侧最好先sprintf拼一个缓冲区再用strlen算长度动态拼接。上报成功后的返回包是一个标准的 HTTP 响应OneNET 会返回HTTP/1.1 200 OK响应体是一段 JSON里面errno:0代表成功。ESP8266 会把这串响应原样通过串口发给 STM32STM32 判断要做的不是解析 JSON而是找字符串errno:0是否存在存在就清除发送缓冲区继续下一轮否则重新发送。这里的逻辑很重要很多开发者把 STM32 当 PC 用尝试在单片机上完整解析 JSON 响应纯属浪费资源。安防系统里 STM32 只认关键字符串完整的调试交给上位机。4.4 命令下发小程序远程撤防的路径与鉴权OneNET 的命令下发走的是创建命令 API即向设备发送一个字符串命令。HTTP 接入模式下设备需要主动拉取ESP8266 定时 GET 一次/devices/{device_id}/cmds?device_idxxx获取待执行的命令。小程序端远程撤防的完整路径是小程序调用 OneNET 的命令创建 API将字符串DISARM_CMD写入命令队列STM32 通过 ESP8266 每 5 秒拉取一次拉到后本地解析执行撤防动作。5 秒的轮询间隔是权衡功耗和响应速度的结果如果对撤防实时性要求高改 MQTT 订阅模式可以降到秒级。命令下发的安全要注意OneNET 的命令默认是明文传输没有加密。家庭场景内网穿透的暴露风险不大但如果做远程公网演示建议命令里不要带固定密码而是用「随机挑战码 本地比对」的方式每次撤防命令附一个自增计数STM32 校验计数比上次大才执行。这种方案防不了高级攻击但能挡住最普遍的 HTTP 抓包重放。5. 微信小程序、语音播报与短信告警的联动5.1 小程序从 OneNET 拉数据的两种方式轮询与 WebSocket小程序端最常见的做法是wx.request定时拉取 OneNET 的数据流 API。这个 API 返回的是 JSON里面嵌套了datastreams数组每一项的datapoints里包含最新值。小程序的渲染层直接绑定这个值即可。function fetchDeviceData() { wx.request({ url: https://api.heclouds.com/devices/ deviceId /datapoints?datastream_idtemp,humi,smokelimit1, header: { api-key: deviceApiKey }, success(res) { const streams res.data.data.datastreams; streams.forEach(stream { if (stream.id smoke) { setSmokeLevel(stream.datapoints[0].value); } }); } }); }注意limit1是取最新的一个数据点不传这个参数时 OneNET 默认返回全量数据会拖慢响应。小程序的wx.request有并发限制同时只能有 10 个请求在飞所以轮询间隔不能低于 2 秒否则前面的请求还没回来新的又发出去报错率直线上升。这里建议把温湿度合并成一个数据流烟雾独立一个数据流同时只发两个请求避免触发并发限制。另一个细节是请求头里api-key是自定义 Header小程序必须在小程序管理后台配置服务器域名白名单否则真机上请求直接被拦截。5.2 语音播报的接入方式门槛最低的是小程序端合成标题里的「语音」在安防系统里至少有两种实现路径。第一种是本地语音识别模块比如 LD3320 接在 STM32 上做离线命令词识别这种方式适合「语音控制布防撤防」不依赖网络但词条定制和抗噪都比较费劲。第二种更轻量在小程序端用语音合成播报告警信息安防事件进入告警页面时通过wx.createInnerAudioContext播放一段提示音再配合文本转语音接口把「烟雾浓度过高」这类信息读出来。实际线上使用中一整条链路里既要有视觉告警页面弹窗也要有听觉告警播放蜂鸣音两者缺一都会导致漏报。小程序里实现语音告警有个容易忽略的坑iOS 对未经过用户手势触发的音频播放有限制小程序冷启动后首次播放可能没声音。解决办法是在页面加载时先让用户点一次「开启声音提醒」按钮在点击事件里预创建一个 AudioContext 并播放一段 1 秒静音打通音频通道之后告警音才能正常响。这个方法在微信小程序的 webview 内核和原生内核里都有效代码只有三行值得加到任何语音播报功能里。5.3 短信告警的实现路径OneNET 没有短信能力要做转发OneNET 本身不提供短信下发实现短信告警的常见做法是「OneNET 触发 → 定时查询 → 第三方短信 API」。具体来说有两种第一种最简单微信小程序定时轮询设备数据比对到烟雾报警值超过阈值后小程序端直接调用短信服务商的 HTTP API 发送短信。缺点是小程序必须在前台或后台存活才能触发用户关掉微信就失效了。第二种更可靠用一台常驻服务器或云函数定时拉取 OneNET 数据检测到告警标志后调用短信 API。这个方案用 Python 写一个cron脚本就能实现。很多实际毕设里直接把短信模块比如 SIM800C接在 STM32 上走串口 AT 指令发短信断网时反而是一条独立的逃生通道。无论走哪条路都建议加一个告警去重逻辑同一设备同一事件在 5 分钟内最多只发一条短信。不然烟雾报警持续期间短信通道会被每分钟一条的消息塞爆既费钱又容易让用户免疫。6. 触摸屏本地交互与整机验证从串口分级到链路打通的 5 个技巧6.1 串口屏的接法与交互模型不是「屏幕」是「另一个串口设备」触摸屏如果是淘晶驰、迪文这类串口屏它在系统里的角色其实是「有显示能力的串口外设」。STM32 在main循环里周期性向 USART3 发送控制指令触摸事件则由串口屏主动上报。一个容易混淆的设计是不要试图让触摸屏直接和 ESP8266 通信所有数据都要经过 STM32 中转否则两个模块的时序尤其是触摸事件的突发上报和 WiFi 的数据拥堵会互相干扰。触摸屏上的布防/撤防按钮绑定的按键 ID串口屏会把按下事件以固定帧格式报给 STM32STM32 在自己的状态机里去响应而不是在屏幕端直接改显示。6.2 验证链路的分级技巧先本地再串口最后云端整机调试时最忌讳直接连齐所有模块然后上电出问题都不知道看哪里。我的习惯是三级分段验证第一级本地把传感器数据通过 STM32 的调试串口USART1用串口助手打印。能稳定看到 DHT11 的温度和 MQ-2 的 ADC 值才说明传感器接口没有问题。注意 MQ-2 上电前 30 秒内数值从满量程往下掉是正常的不要误判成故障。第二级串口到 WiFi把 ESP8266 单独接 USB-TTL用串口助手手动敲 AT 指令敲一遍完整的 POST 请求确认 OneNET 返回errno:0。这一步验证的是 4.3 节里的命令序列是否正确能在这个环节排查掉九成的「748 错误」——这个错误通常是Content-Length和实际发送长度不一致。第三级STM32 到云端确认前两级都通后再连 STM32 和 ESP8266。这时候出问题的一定是两边的通信时序比如波特率不匹配、帧协议里的校验错误而不是传感器或云平台的问题。把帧格式打印到调试串口实际比对 STM32 发的帧和 ESP8266 收到的内容是否一致。6.3 晶振不起振与调试器连接不上的排查顺序如果 ST-Link 烧录时报Error: No STM32 target found先别急着换芯片。用示波器量 OSC_IN 引脚没有波形说明晶振没起振检查晶振电容和负载电容匹配。F103C8T6 用 8MHz 晶振两个 20pF 负载电容是常见配置但如果用的 PCB 寄生电容偏大就换 15pF。另一个高频问题来源是电脑 USB 口供电不足ST-Link 和板子同时从 USB 口取电时板子上的 ESP8266 如果也上电电流峰值接近 500mA直接把电压拉到 3.1V 以下MCU 复位导致连接失败。排查方法是先把 ESP8266 去掉确认能烧录后再接回来。在驱动层面STM32 Virtual COM Port出现黄色叹号时装的是旧版驱动卸载设备后重新扫描安装新版即可这个和芯片本身没有任何关系。6.4 数据流折线图不显示时的检查顺序OneNET 平台自带的数据流折线图是判断数据链路是否正常的直观工具。如果小程序能看到最新数值但折线图空白先看数据流的类型。OneNET 的折线图只对数值型数据流生效如果创建数据流时类型被定义成了字符串数据点写进去了但无法绘制。另一个细节是最小时间粒度上传频率低于每 5 分钟一个点时会自动聚合对于 2 秒上报一次的安防数据可以直接在 API 请求参数里加interval控制统计粒度。折线图空白不代表数据丢失用「数据流详情」页里的「最新数据点」看有没有值有值就说明链路通只是展示层维度的问题。本文还有配套的精品资源点击获取