简介：这是一套基于STM32单片机与WiFi通信的物联网智能消防预警系统毕业设计源码包，面向电子、嵌入式、物联网方向的学生和开发者，可用于课程设计、毕业设计或消防监控类项目二次开发。压缩包共202个文件，约46.08MB，主要涵盖STM32标准外设库的c/h源文件、Android客户端kt/xml工程文件、Keil工程配置（uvprojx/uvoptx）、Gradle构建脚本，以及APK安装包、操作演示视频等，嵌入式端、移动端与构建配置齐全。已有71人学习下载。资源支持直接运行Keil工程与Android客户端，结合烟雾、温度、火焰传感器数据采集、WiFi上报与远程预警流程，可帮助理解完整的端到端物联网消防系统；源码中cJSON解析、定时器/ADC/I2C等驱动实现具备模块化和可读性，便于后续扩展报警阈值、历史查询与分析功能。
1. 毕业设计里的STM32消防预警，为什么WiFi联网版比本地报警更有含金量
智能消防预警听起来像是一个“期末答辩项目”，但拆开看其实是嵌入式、通信、物联网平台三件事的集合。用STM32单片机采集烟雾、火焰和温度数据，通过WiFi模块上传到物联网平台，再在手机或电脑上收到报警推送——这就是一套能演示、能扩展、能写进简历的物联网消防预警系统。对于正在做毕业设计的人来说，这份源码解决的是“从哪里开始”的问题：最小硬件怎么搭、数据怎么流向平台、预警逻辑怎么写得像产品而不是玩具。它没有停留在“本地响个蜂鸣器”的阶段，而是把真实产品最看重的远程监控链路做了出来。适合有单片机基础、想快速跑通整套物联网链路的同学，也适合想把它改成电动车充电棚、实验室报警装置的在职开发者。
2. 系统拆解：STM32采集、ESP8266转发、物联网平台下发，一条完整的数据链路
2.1 传感器选型与接线：烟雾、火焰、温度三路信号怎么进STM32
先明确一点：消防预警系统至少要有三路物理量输入，分别是烟雾浓度、火焰红外、环境温度。毕业设计里最常见的传感器组合是MQ-2烟雾传感器、火焰传感器模块（红外探头加比较器）、DS18B20数字温度传感器。选这三样不是因为参数多先进，而是因为它们输出信号简单、例程多、成本低，且能覆盖“阴燃”“明火”“温升”三种预警场景。
接线方面，MQ-2有模拟输出和数字输出两个引脚，实际项目里我建议接模拟输出到STM32的ADC引脚，因为数字输出的阈值被板载电位器固定死了，改起来麻烦，而模拟输出可以用代码随时调整判定阈值。火焰传感器同理，也接模拟输出。DS18B20是单总线协议，只需要一个GPIO口，但要注意上拉电阻，一般4.7k欧姆，不加上拉会偶发读温度错误。典型接线是：
// 假设使用STM32F103C8T6 // PA0 -> MQ-2烟雾传感器AO（ADC1通道0） // PA1 -> 火焰传感器AO（ADC1通道1） // PB5 -> DS18B20数据线（接4.7k上拉到3.3V） // PA2 -> ESP8266 TX，PA3 -> ESP8266 RX（USART2）这里有个容易忽略的点：大多数火焰传感器模块的供电范围是3.3V到5V，而STM32的ADC参考电压通常就是3.3V；如果传感器模块用5V供电，它的模拟输出最高会到5V，直接进ADC会超过量程，严重时可能损坏引脚。常见做法是让传感器模块也吃3.3V，或者用电阻分压把输出限制在3.3V以内。我一般直接在模块的VCC和GND上取3.3V，虽然灵敏度略有下降，但安全可靠。
2.2 通信方案对比：串口AT指令、MQTT直连、HTTP POST该选哪个
WiFi模块和STM32之间的通信方式，决定了代码结构和实时性。目前主流选择是ESP8266，因为它便宜、例程多、能跑AT固件，也可以用官方SDK刷成MQTT直连。但毕业设计的源码包通常基于AT指令，原因很简单：STM32只需要操作串口，逻辑清晰，容易调试。你需要发送AT+CWMODE、AT+CWJAP、AT+CIPSTART这样的命令，把模块当成一个“无线串口”来用。
如果你追求更低的延迟和更好的代码可维护性，也可以让ESP8266直接跑MQTT固件，STM32只需要通过串口把数据交给它。但这要求你会刷固件、会处理MQTT协议栈的打包解包，对毕设来说属于“进阶加分项”，不是必需项。HTTP POST则更简单，STM32组装好URL和JSON串，通过AT+CIPSEND发给ESP8266，由ESP8266连接服务器并发送请求。它的优点是服务器端只要你有一个公网URL就能收数据，缺点是每次上报都要重新建立TCP连接，比较慢，而且平台端不支持下行控制。
我的建议是：如果你的题目叫做“智能消防预警”，那么MQTT协议是更合适的，因为物联网平台通常用MQTT做消息推送，后续做手机App报警、微信推送都方便。但源码包里如果用的是AT+HTTP，也不要急着否定，因为核心的采集和阈值判断逻辑是一样的，通信协议只影响最后一个环节。
2.3 平台选择与Topic设计：巴法云、OneNET、自建服务器的取舍
物联网平台是这套系统里最像“黑匣子”的部分。毕业设计最常用的平台是巴法云（Bemfa）和OneNET，也有少数用阿里云物联网平台或自建EMQX服务器。选平台时主要看三件事：是否免费、是否支持MQTT、是否提供现成的App或小程序控制面板。
巴法云的好处是注册后有免费的MQTT Broker可用，Topic随你定义，而且自带一个网页控制台和微信小程序模板，你不需要自己写App。OneNET的老版本已经停止维护，新版本准备复杂一些；如果你手里是旧教程的代码，运行时会发现平台接口变了，这就是很多同学“照着源码跑不通”的核心原因。自建EMQX则适合有多余电脑或云服务器的人，自由度最高，但毕设答辩需要现场演示时，自建服务器一旦关机就没有数据流，风险较大。
Topic建议分两个：一个用于上报传感器数据，比如/fire/sensor/data，上行发送JSON；一个用于接收控制指令，比如/fire/device/control，下行接收报警复位、阈值修改。这样设计的好处是数据流和控制流分开，后期接微信小程序或App时不用改设备端逻辑，只需让小程序订阅和发布对应Topic。
3. 核心代码解读：从传感器采集到WiFi上报的最小可运行框架
3.1 传感器采集任务：如何处理ADC与GPIO抖动
先看第一段关键代码：初始化ADC并读取烟雾和火焰传感器的模拟值。很多人把ADC采样想复杂了，其实STM32的标准库和HAL库都提供了现成的多通道采集函数，核心是你要做一个软件滤波，否则MQ-2的气体浓度读数会跳得让你怀疑传感器坏了。
// 读取烟雾传感器电压值（PA0，ADC1通道0） uint16_t read_smoke_adc(void) { uint32_t sum = 0; uint8_t i; for (i = 0; i < 8; i++) { HAL_ADC_Start(&hadc1); // 启动一次转换 HAL_ADC_PollForConversion(&hadc1, 10); // 等待转换完成 sum += HAL_ADC_GetValue(&hadc1); // 读取12位ADC值 } HAL_ADC_Stop(&hadc1); return (uint16_t)(sum / 8); // 取平均，滤掉随机抖动 }这里做了8次采样取平均，原因是MQ-2传感器即使在同一环境下瞬时电压也有几十毫伏的波动。如果你只采一次，后续阈值判断会出现“一分钟报警三次又自动恢复”的鬼畜现象。采样次数并不是越多越好，8到16次足够了，多了反而占用CPU，在裸机循环里会影响WiFi通信的实时性。
DS18B20温度读取相对特殊，它是单总线设备，需要严格按照时序读写。这里不展开底层驱动，只提一个关键参数：如果你使用HAL库，要确保GPIO的速度配成高速，且开启上拉；如果读取频繁失败，大概率是延时函数不够精确或上拉电阻没接好。
3.2 WiFi模块驱动：ESP8266的AT指令封装与断线重连
ESP8266的AT指令驱动是所有通信逻辑的地基。源码包通常会把AT指令封装成几个函数：ESP8266_SendCommand()、ESP8266_ConnectWiFi()、ESP8266_ConnectMQTT()。封装时要注意一个关键点：AT指令的响应结尾是\r\nOK\r\n或\r\nERROR\r\n，不能只看“收到字符串”就认为命令执行成功，一定要检查结尾是否包含OK。否则在WiFi密码错误、服务器域名解析失败时，代码会继续往下跑，然后卡死在发送数据环节。
// 发送AT指令并检查响应，timeout单位是毫秒 uint8_t ESP8266_SendCommand(char *cmd, char *expect, uint16_t timeout) { char buffer[128] = {0}; uint16_t len = 0; uint16_t elapsed = 0; HAL_UART_Transmit(&huart2, (uint8_t *)cmd, strlen(cmd), 200); while (elapsed < timeout) { if (HAL_UART_Receive(&huart2, (uint8_t *)&buffer[len], 1, 50) == HAL_OK) { if (buffer[len] == '\n') { buffer[len] = '\0'; if (strstr(buffer, expect) != NULL) { return 1; // 找到期望的字符串 } len = 0; // 清空，继续等下一行 } else if (len < sizeof(buffer) - 1) { len++; } } else { elapsed += 50; } } return 0; // 超时未找到 }这段代码的核心逻辑是逐字节接收AT响应，按\n分割成行，再在当前行里搜索预期的关键词。这样做比用strstr直接搜整个缓冲更可靠，因为AT固件在收到AT+CIPSTART这种命令时，中间会穿插许多不可见字符和空行。参数timeout建议设1500到3000毫秒，太短会误判失败，太长会拖慢主循环。如果你发现模块偶尔连不上WiFi，可以先只用AT+CWJAP命令测试，手动把返回的WIFI DISCONNECT和WIFI CONNECTED打印出来，再检查是不是密码格式或者热点频段问题。
3.3 预警状态机：正常、预警、报警三态切换与阈值
预警逻辑最关键的不是“超过阈值就报警”，而是设计一个防抖状态机。比如烟雾浓度，刚开始锅里的油烟飘过来，读数跳到阈值以上，过了两秒钟油烟散了，读数又掉下来。如果你用简单的if (smoke > threshold) 报警，系统就会陷入报警—复位—报警的循环里。状态机能解决这个问题。
| 状态 | 进入条件 | 本状态下动作 | 迁出条件 |
|---|---|---|---|
| 正常 | 上电或复位 | 采集并上报，不发报警 | 任一指标超阈值且持续≥2秒 |
| 预警 | 超阈值且持续2秒 | 上报预警消息，LED慢闪 | 指标回落或进入报警 |
| 报警 | 预警后继续超阈值或第二路传感器触发 | 上报报警，蜂鸣器响，等待手动/远程复位 | 收到复位指令或全部指标正常且持续10秒 |
我用三个状态而不是两个，是为了在演示时能看出来“预警”和“报警”的区别，答辩评委更愿意看到这样一个中间状态，因为它更像真实产品。阈值参数我一般定义为宏，方便后期调试：
#define SMOKE_HIGH_THRESHOLD 1800 // 烟雾ADC值，对应约0.8V #define FLAME_HIGH_THRESHOLD 2000 // 火焰红外AD值，数值越大光越强 #define TEMP_HIGH_THRESHOLD 50 // 单位：摄氏度 #define HOLD_TIME_MS 2000 // 必须持续超过阈值的时间在状态机里，每次循环都要检查一个“持续时间计数器”。如果当前采样值低于阈值，就把计数器清零；只有连续HOLD_TIME_MS都超阈值，才允许状态迁移。不要用HAL_GetTick()的差异值累积吗？可以，但要小心计数器回绕；简单项目里直接用uint32_t延时也不会出错，因为运行几天才会回绕一次。
3.4 主循环与RTOS vs 裸机：毕设代码该用哪种组织方式
源码包如果跑的是裸机主循环，结构一般是这样：初始化所有外设后进入while(1)，依次调用传感器采集、状态机更新、WiFi上报。好处是代码直观、不会死锁、调试容易。坏处是ADC采样、状态机判断、串口发送这几个环节互相阻塞，可能导致WiFi上报被传感器采集拖慢。
如果采用FreeRTOS，源码包会创建几个独立任务：传感器采集任务、状态机任务、WiFi上报任务。任务之间用队列或全局变量做数据交换。我个人的看法是，毕业设计优先用裸机，因为大多数答辩老师更关注“你是不是真的理解了寄存器操作”，而不是你是否会写RTOS。但如果你在简历上写“熟悉FreeRTOS”，那源码包最好带RTOS版本，否则答辩被问到任务栈大小、优先级翻车就不好了。
实际上，裸机也能解决阻塞问题：在主循环里用状态机驱动WiFi上传，把发送拆成“准备数据”“发送AT指令”“等待应答”几个子状态，每次循环只做一小步。这样ADC采样永远有最高机会获得CPU时间，WiFi通信哪怕慢一点，也不至于让传感器卡死。源码包如果没这么做，你也可以自己改，这一步就叫“从能跑到能用的优化”。
4. 把源码包变成自己作品：移植、改参、烧录验证
4.1 源码目录结构与关键文件定位
拿到一份STM32毕业设计源码，第一步不是打开工程就开始编译，而是先看目录结构。通常它会包含一个Keil工程文件夹（如Project）、一个硬件驱动文件夹（如Hardware或BSP）、一个系统文件（System）、一个用户代码文件夹（User或App）。你要快速找到三个关键文件：主函数、传感器驱动、WiFi驱动。
# 一个典型源码包的目录结构（示例） Project/ # Keil工程文件 STM32F103C8Tx.sct fire_alarm.uvprojx Hardware/ mq2.c flame.c ds18b20.c esp8266.c User/ main.c fire_status.c platform_config.h System/ stm32f1xx_hal_conf.h startup_stm32f103xb.s你不需要从头到尾读每一行代码，重点是看platform_config.h或main.h里的宏定义，那里通常集中放着WiFi账号密码、MQTT服务器地址、Topic名称、上报间隔、阈值参数。改这一份头文件，就等于完成了一半移植。
4.2 必改参数与平台密钥配置
无论源码包接的是哪个平台，你都必须改掉以下参数，否则烧录到板子上还是连不上你自己的热点和账号。我把这些参数汇总成一张表，你对照着自己改就行。
| 参数名称 | 示例值 | 说明 |
|---|---|---|
| WIFI_SSID | "MyHome" | 你的2.4G热点名称，不能有中文 |
| WIFI_PASSWORD | "12345678" | 热点密码，至少8位 |
| MQTT_HOST | "bemfa.com" | MQTT服务器地址 |
| MQTT_PORT | 9501 | 巴法云默认MQTT端口 |
| MQTT_CLIENT_ID | "fire_alarm_01" | 设备唯一标识，注意不能重复 |
| TOPIC_DATA | "fire/sensor/data" | 上行数据Topic |
| TOPIC_CTRL | "fire/device/ctrl" | 下行控制Topic |
这里最大的坑是：巴法云的MQTT接入要求CLIENT_ID里附带你的私钥，格式通常是你的私钥加设备名，比如abc12345fire01。很多源码包注释没写清楚，导致你以为填的是设备名，实际填的是密钥，连接一直被拒绝。建议先单独用PC上的MQTT调试工具（比如MQTTX）配置同样的参数，如果PC能连上，再把相同参数填进STM32工程。
4.3 烧录与串口日志验证
烧录前先确认芯片型号和下载器。STM32F103C8T6绝大多是使用ST-Link或J-Link，在Keil里设置好Debug选项后直接下载。如果出现“No target connected”，先检查ST-Link的SWDIO、SWCLK、GND三根线是否接对，然后按住板子复位键再点下载，等开始下载瞬间松手，这是STM32玩久了都会遇到的“解锁技巧”。
烧录成功之后，串口日志是你唯一的眼睛。源码包一般会在printf上做了重定向，你需要用USB转TTL接在STM32的USART1上，波特率常见是115200或9600。打开串口助手，你应该能看到类似下面的输出：
[INFO] WiFi connecting... [INFO] WiFi connected, IP: 192.168.1.108 [INFO] MQTT connect success [INFO] Publish topic: fire/sensor/data, payload: {"smoke":123,"flame":456,"temp":27.5}如果卡在WiFi connecting...，说明AT指令交互出了问题，先检查STM32的TX是否接了ESP8266的RX，交叉是否正确；如果一直MQTT connect fail，则重点检查CLIENT_ID和Topic是否填对，以及热点是否能访问外网。注意，这里说的“外网”指的是你正常上网访问公网服务器，和任何不当工具无关。
5. 从原理图到实物的踩坑记录：五个最常见的翻车点
5.1 ESP8266供电不足导致反复重启
现象：ESP8266一旦开始连接WiFi，模块上的红色LED就闪一下，然后整个系统复位，或者串口打印乱码。原因：ESP8266发送数据时的峰值电流接近300mA，而很多面包板上的3.3V稳压芯片（如AMS1117-3.3）最大输出电流只有800mA，但经过杜邦线和面包板接触电阻后，实际电压会被拉低到3.3V以下，模块欠压重启。
解决：不要从STM32板载的3.3V引脚给ESP8266供电，改用外部独立的5V电源，进一个LM2596或MP1584降压模块输出3.3V，并且电源地要和STM32共地。如果只是毕设演示，用一个充电宝加降压模块也可以，但要注意充电宝自动休眠问题，可以插一块小负载防止断电。
5.2 ADC采集电压不稳，烟雾浓度跳变
现象：串口打印烟雾值，发现每20毫秒跳几百，明明传感器周围没有烟雾，数值却从300跳到1200再跳回去。原因：MQ-2传感器的加热丝需要预热，刚上电前30秒内电阻变化剧烈；同时它的模拟输出阻抗较高，如果STM32的ADC引脚没有做低通滤波，很容易拾取50Hz工频干扰。
解决：传感器模块先上电预热60秒再说；程序里保留软件滤波，硬件上在ADC引脚对地并联一个0.1uF电容，如果还有跳变，可以换成1uF。注意电容不要太大，否则ADC采样响应会变慢，阈值判断也跟着迟钝。
5.3 WiFi连接超时卡死，程序跑飞
现象：系统运行一段时间后，手机端收不到数据，串口也不再打印任何信息，好像整个程序进入死循环。原因：AT指令发送后没有设置超时或超时时间太长，一旦WiFi网络异常，HAL_UART_Receive一直在等响应，CPU被阻塞；又或者ESP8266固件版本不同，返回的提示语不是源码包里搜索的关键词，等不到OK就永远卡住。
解决：给所有AT指令加上超时退出，在等待循环里判断“时间到就强制返回失败”。同时修改状态机，让WiFi上报失败不阻塞主循环，最多记一个错误计数，下一次循环再尝试。这个机制才是系统长时间稳定运行的根本。
5.4 按键与传感器共用GPIO造成的误触发
现象：设计复位按钮时图省事，把按键接在PA0上，结果每次按键按下，烟雾值都猛增，然后报警。原因：PA0同时被用作按键输入和ADC模拟输入，内部结构互相影响，按键按下时把引脚电平拉低，导致ADC采样值异常。
解决：把按键换到另一个普通GPIO，或者直接使用复位引脚NRST做手动复位，不需要外部按键。再强调一遍，不要为了省引脚把模拟输入和数字输入混接，STM32的引脚虽然复用功能多，但不是所有组合都能同时跑。
5.5 平台推送延迟，预警不“实时”
现象：传感器已经报警，手机App过了30秒才收到推送。原因：MQTT上报周期设成了30秒一次，或者上报数据在上电后只发一次；平台免费版的消息转发队列在高峰时也会有几秒延迟。更常见的是，你用的是HTTP POST，每次建立TCP连接需要数次RTT，在移动网络下延迟明显。
解决：把上报周期缩短到5秒以内，预警和报警消息不依赖周期上报，而是在状态机迁移时立即打包推送一次。这样即使周期上报被WiFi卡住，报警事件也能优先发出去。如果你接的是免费MQTT平台，还可以在报警时连续发三条相同消息，提高到达率，代价是平台可能会限流，要控制总频次。
6. 最后一招：用一份自检表验证整个消防预警系统的可靠性
到了这一步，系统已经能跑通，但你想让答辩评委或公司领导信服，还差一个东西：可验证的测试记录。不要拿“我试了能亮灯”当结论，要拿出一份表格，说明你在什么条件下、做了什么操作、系统如何响应。
| 测试场景 | 操作步骤 | 预期结果 | 实测结果 |
|---|---|---|---|
| 烟雾预警 | 靠近MQ-2喷一口电子烟 | 5秒内LED慢闪，平台收到预警 | 2秒后上报预警，LED慢闪 |
| 火焰报警 | 打火机距火焰传感器10cm | 2秒内蜂鸣器响，平台收到报警 | 1.5秒报警，手机端收到推送 |
| 温度报警 | 用电吹风靠近DS18B20 | 温度超50℃时进入报警 | 温度52℃时触发报警 |
| 断网恢复 | 关闭路由器再打开 | 2分钟内自动重连WiFi | 1分40秒重连成功 |
| 远程复位 | 在App下发复位指令 | 系统停止报警，回到正常态 | 状态机复位，蜂鸣器停 |
我自己的习惯是，每测一次就在表格里记录一次，并截图串口日志和手机通知。这样不仅能发现“偶发失灵”的规律，答辩时也能直接把材料贴在论文附录里。最后再提醒一个玄学问题：如果所有代码都正确，但报警总是不触发，请检查MQ-2传感器是不是被放置在了通风良好、没有气流的地方，气体传感器需要空气流动才能把烟雾带进去；如果放在密闭盒子里，你喷再多烟它也反应迟钝。希望这篇笔记里的方案和踩坑经历能帮到你，让你的毕业设计少走几趟弯路。
本文还有配套的精品资源，点击获取
