STM32消防预警系统实战：WiFi联网与MQTT远程报警全解析

简介这是一套基于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烟雾传感器AOADC1通道0 // PA1 - 火焰传感器AOADC1通道1 // PB5 - DS18B20数据线接4.7k上拉到3.3V // PA2 - ESP8266 TXPA3 - ESP8266 RXUSART2这里有个容易忽略的点大多数火焰传感器模块的供电范围是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只需要操作串口逻辑清晰容易调试。你需要发送ATCWMODE、ATCWJAP、ATCIPSTART这样的命令把模块当成一个“无线串口”来用。如果你追求更低的延迟和更好的代码可维护性也可以让ESP8266直接跑MQTT固件STM32只需要通过串口把数据交给它。但这要求你会刷固件、会处理MQTT协议栈的打包解包对毕设来说属于“进阶加分项”不是必需项。HTTP POST则更简单STM32组装好URL和JSON串通过ATCIPSEND发给ESP8266由ESP8266连接服务器并发送请求。它的优点是服务器端只要你有一个公网URL就能收数据缺点是每次上报都要重新建立TCP连接比较慢而且平台端不支持下行控制。我的建议是如果你的题目叫做“智能消防预警”那么MQTT协议是更合适的因为物联网平台通常用MQTT做消息推送后续做手机App报警、微信推送都方便。但源码包里如果用的是ATHTTP也不要急着否定因为核心的采集和阈值判断逻辑是一样的通信协议只影响最后一个环节。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的气体浓度读数会跳得让你怀疑传感器坏了。// 读取烟雾传感器电压值PA0ADC1通道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固件在收到ATCIPSTART这种命令时中间会穿插许多不可见字符和空行。参数timeout建议设1500到3000毫秒太短会误判失败太长会拖慢主循环。如果你发现模块偶尔连不上WiFi可以先只用ATCWJAP命令测试手动把返回的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_SSIDMyHome你的2.4G热点名称不能有中文WIFI_PASSWORD12345678热点密码至少8位MQTT_HOSTbemfa.comMQTT服务器地址MQTT_PORT9501巴法云默认MQTT端口MQTT_CLIENT_IDfire_alarm_01设备唯一标识注意不能重复TOPIC_DATAfire/sensor/data上行数据TopicTOPIC_CTRLfire/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慢闪火焰报警打火机距火焰传感器10cm2秒内蜂鸣器响平台收到报警1.5秒报警手机端收到推送温度报警用电吹风靠近DS18B20温度超50℃时进入报警温度52℃时触发报警断网恢复关闭路由器再打开2分钟内自动重连WiFi1分40秒重连成功远程复位在App下发复位指令系统停止报警回到正常态状态机复位蜂鸣器停我自己的习惯是每测一次就在表格里记录一次并截图串口日志和手机通知。这样不仅能发现“偶发失灵”的规律答辩时也能直接把材料贴在论文附录里。最后再提醒一个玄学问题如果所有代码都正确但报警总是不触发请检查MQ-2传感器是不是被放置在了通风良好、没有气流的地方气体传感器需要空气流动才能把烟雾带进去如果放在密闭盒子里你喷再多烟它也反应迟钝。希望这篇笔记里的方案和踩坑经历能帮到你让你的毕业设计少走几趟弯路。本文还有配套的精品资源点击获取