企业官网建设流程全解析

把实验室消防预警控制系统从想法做到实物，从画原理图到调通仿真，到最后把整套工程开源出去，前后大概花了我三个星期的业余时间。这个项目归根结底要干的事并不复杂：用STM32作为主控，接上烟雾传感器、火焰传感器和温湿度传感器，实时盯着实验室的环境数据，一旦出现异常就驱动蜂鸣器和LED报警，同时自动打开排风扇、切断危险设备电源，避免小火苗悄悄变成大事故。整套开源包里，源码、原理图、仿真工程三样齐全，全部是我自己从零画的、从零写的，不需要你再满网去找零零碎碎的参考资料拼凑。

为什么盯着“实验室”这个场景做？因为我见过太多实验室安全问题：酒精灯用完忘关、烘箱长时间无人值守、锂电池过充鼓包、易燃试剂挥发积聚……传统烟感报警器虽然也能响，但往往只响应已经明显的烟雾，而且它只会“叫”，不会主动切断电源、启动排烟。一套基于STM32的预警联动系统，价值就在“早发现”和“自动处置”这两个点上。传感器实时采集，控制逻辑分级判断，报警与联动并行执行，这套思路放到家庭、仓库、机房其实也完全通用。

再说下这套资源适合谁。如果你正在做嵌入式相关的毕业设计，这个项目可以当做一个完整模板，从硬件到软件到仿真一应俱全；如果你是自学STM32的初学者，建议把它拆开看，先看传感器驱动再看状态机逻辑，比跟着视频敲一百遍点灯有用得多；如果你只是想要一个实验室安全改造的方案参考，原理图和接线表可以直接抄作业。下面我把整个项目的设计思路、关键代码、实操步骤和踩过的坑都摊开讲，尽量让拿到资源的你能自己复现，而不是手里有代码却不知道从哪下手。

1. 项目整体设计与需求拆解

1.1 实验室消防预警到底在防什么

很多人一听到“消防预警”，第一反应就是装一个烟雾报警器。但实验室这个场景比较特殊，风险源不是单一的，至少有三类：

第一类是明火隐患。实验室里酒精灯、电炉、加热板都是常见设备，人走开几分钟就可能出事。明火的特点是初期没有明显烟雾，等烟雾传感器报警时往往火已经起来了，所以必须单独配一路火焰检测。

第二类是电气隐患。烘箱、高温炉、大功率电源、锂电池测试设备，长时间通电容易过热。这类风险在温度上会有提前反映，环境温度异常升高是个很重要的前置信号。

第三类是试剂挥发。易燃有机溶剂泄漏后在密闭空间慢慢积聚，浓度达到一定程度就有闪燃风险。可燃气体的早期浓度变化，可以通过半导体气体传感器捕捉到。

传统烟感只解决“有没有烟”这一个问题，而且它没有处置能力。我这套系统的做法是三层防御：探测层同时采集烟雾浓度、环境温湿度、火焰信号；判断层用分级状态机把系统状态划分为正常、预警、警报三个等级；处置层根据不同等级执行响铃、闪灯、开排风扇、切断负载电源等动作。这样设计的好处是，单个传感器误报不会直接触发断电这种高强度动作，而多传感器同时确认后又能快速进入最高等级响应。

1.2 系统功能清单与技术指标

整个系统的功能模块可以整理成下面这张表，这也是我做方案设计时最初列的清单：

在设计阶段我给这套系统定的核心指标是：传感器数据采集周期不大于200ms；从检测到异常到触发报警响应不超过2秒；温湿度分辨率0.1摄氏度；烟雾报警阈值可以在代码里直接配置。这几个指标并不激进，但做实物验证时足够实用，也不会因为追求速度把代码写复杂。

1.3 开源资源包的文件结构

拿到开源包之后，第一件事是看清楚目录结构。我按“工程文件、源码、硬件、仿真、文档”五个维度做了划分：

Lab-Fire-Alarm/ ├─ MDK-ARM/ # Keil5工程目录 │ ├─ Lab_Fire_Alarm.uvprojx │ └─ ... ├─ Src/ # 源码 │ ├─ main.c # 主函数与状态循环 │ ├─ adc.c / dht11.c / flame.c # 传感器驱动 │ ├─ alarm.c / relay.c / display.c │ └─ stm32f1xx_hal_msp.c # 引脚复用配置 ├─ Inc/ # 头文件 ├─ Hardware/ │ ├─ Lab_Fire_Alarm_SCH.pdf # 原理图PDF，直接看 │ ├─ Lab_Fire_Alarm.json # 立创EDA源文件，可编辑 │ └─ 元件清单.xlsx # 采购清单 ├─ Simulation/ │ ├─ lab_fire_sim.pdsprj # Proteus仿真工程 │ └─ README.md # 仿真使用说明 └─ README.md # 总体说明、引脚定义、接线表

使用顺序建议是：先看README，了解引脚定义和接线表；再看原理图PDF，搞清楚硬件连接关系；然后打开仿真工程跑一遍，直观看到系统行为；最后再动手看代码和焊接实物。代码本身我全程用的是HAL库加标准库混合风格，传感器驱动部分特意做得比较“裸”，方便移植到其他STM32型号。

2. 方案选型：为什么是STM32配上这几颗传感器

2.1 主控选型背后的小算盘

主控用的是STM32F103C8T6，这颗芯片现在几乎成了嵌入式入门的“国民MCU”。Cortex-M3内核，主频72MHz，64KB Flash，20KB SRAM，内置12位ADC、多个定时器、USART、I2C、SPI，管脚只有48个但是功能非常均衡。最关键的是一块最小系统板只要十几块钱，资料多到看不完，遇到问题随手一搜就有答案。

为什么不选51单片机？说句实在话，51的GPIO和ADC资源对这个项目来说太紧张了，MQ-2一路模拟量、DHT11一路单总线、火焰传感器一路数字量，再加蜂鸣器、继电器、OLED，8位机即使勉强塞下，代码耦合度也会很高，后期想扩展WiFi模块基本不可能。为什么不直接上ESP32？ESP32性能确实强，还自带WiFi，但纯裸机做外设教学的体验不如STM32清晰，而且WiFi协议栈会引入额外调试复杂度。如果你想省钱省事，F103C8T6就是这套系统的甜点区间。

选型时还有一个细节容易被忽略：STM32F103的GPIO耐压值是3.3V，而不少传感器模块是5V供电，输出高电平常直接是5V。如果直接把5V信号灌进MCU引脚，长期看是有风险的。所以我在设计里要么选3.3V兼容的模块，要么用电平匹配电路处理，这点后面会详细说。

2.2 传感器与执行器的选型对比

传感器的选择决定了整个系统的感知上限，我分别对比了几种常见方案：

MQ-2内部是一个半导体气敏元件，需要在加热丝上通电加热到工作温度，所以功耗不低，典型工作电流在150mA左右。它在干净空气中的输出电压会有一个比较稳定的基线值，遇到烟雾或可燃气体时电压迅速上升。我选择读它的AO模拟输出，而不是直接接DO数字输出，原因很简单：板上那个可调电位器虽然能调DO的触发阈值，但阈值一旦被硬件固定，程序里就没法灵活配置了。读AO配合ADC，阈值完全由软件决定，想改就改。

DHT11很多人嫌它精度低，但在这个项目里够用：温度分辨率1度，湿度分辨率1%，用来做“环境是否异常”的判断完全没问题。它的通信协议是单总线，对时序很敏感，后面我专门有一节讲怎么稳定读取。

执行器方面，蜂鸣器我选的是有源蜂鸣器，因为内部自带振荡电路，给高电平就响，驱动逻辑简单。继电器选的是SRD-05VDC-SC，5V线圈，10A触点，控制排风扇、电磁阀或者直接切实验室负载电源都够用。

2.3 系统架构与数据流设计

整个系统的数据流是一条很清晰的单向链路：传感器把物理量变成电信号，STM32通过ADC和GPIO读取，软件逻辑判断状态，最后驱动显示、报警和联动执行器。

我特意把逻辑层拆成了三个部分，而不是在main函数里堆一堆if-else：

• 数据采集层：负责读取传感器原始数据，做滤波、校验、单位换算。
• 状态判断层：根据采集结果和阈值，计算当前系统处于正常、预警还是警报。
• 执行输出层：根据状态驱动蜂鸣器、LED、继电器和显示屏。

这样拆的好处是，你想改任何一个环节都不影响其他环节。比如想换一个更高精度的温湿度传感器，只需要替换数据采集层里的DHT11驱动，接口保持一致就行；想调整联动逻辑，只改执行输出层，不必去碰传感器代码。这种分层思想虽然简单，但能让你后续维护省很多事。

3. 原理图设计：把系统画出来

3.1 最小系统与供电设计

原理图我是用嘉立创EDA画的，导出源文件的同时也导出了PDF。之所以选嘉立创EDA而不是AD，一是免费且完全在线，二是它的元件库足够全，导出的文件可以直接下订单打样，对做项目的人来说省去很多麻烦。画图之前先把栅格设置好，我用的是2.54mm标准排针间距，所有元件都对齐栅格，这样布线更规整，后期查错也方便。

供电部分是整个硬件里最基础也最容易翻车的地方。系统工作电压有两路：USB输入的5V，一路直接给蜂鸣器、继电器、MQ-2加热丝和传感器模块供电；另一路经过AMS1117-3.3稳压到3.3V，给STM32和OLED供电。需要注意MQ-2加热丝加上继电器吸合瞬间电流比较大，USB口标称500mA可能会吃不消，我实际测试时用一个5V/2A的电源适配器供电就完全没问题。

每个芯片的电源引脚旁边我都放了0.1uF去耦电容，电源入口还并了一个10uF电解电容和一个0.1uF瓷片电容。这些电容不是摆设，STM32运行时引脚翻转会产生高频噪声，MQ-2加热电流波动也会拉低电源电压，去耦电容能把这些噪声就地吸收掉，避免干扰ADC采样。

复位电路和启动配置也要画对：NRST接一个10k上拉电阻再加一个0.1uF电容到地；BOOT0和BOOT1各接10k下拉电阻，保证芯片从Flash正常启动。晶振用的是8MHz无源晶振，两个22pF负载电容，这个数值不是随便拍的，要对着晶振手册确认。

3.2 传感器接口与继电器驱动电路

传感器接口设计上我全部用了标准的2.54mm排针，每个传感器模块的VCC、GND、信号线都能直接插上去，方便调试时更换。模拟信号走线尽量短，而且远离继电器这类大电流开关线路，避免数字开关噪声耦合进来影响ADC读数。

MQ-2的AO接到PA0，DHT11的DATA接到PA1并加一个4.7k上拉电阻到3.3V，火焰传感器的数字输出DO接到PA2。这里特别说一下，DHT11的上拉电阻不能省，单总线协议的空闲状态就是高电平，传感器靠拉低来发送信号，没有上拉电阻根本无法正常工作。

继电器驱动是老生常谈但也最容易出错的地方。STM32的GPIO灌电流能力有限，直接驱动继电器线圈肯定不行，必须加一级驱动。我的做法是用S8050三极管，基极通过1k电阻接PB13，集电极接继电器线圈的一端，线圈另一端接5V，线圈两端反向并联一个1N4148续流二极管。续流二极管非常重要，继电器断开瞬间线圈会产生反向电动势，几十伏的反向尖峰如果没有二极管泄放，很容易打坏三极管甚至MCU。负载端走的是继电器的COM和NO引脚，和MCU控制电路完全电气隔离，排风扇的正负极接在COM和NO上，控制端只负责给继电器线圈通电和断电。

3.3 绘制检查要点与打样注意事项

原理图画完以后，别急着下订单，先做几件检查：

• 电气规则检查（ERC）。嘉立创EDA会自动检查悬空引脚、短路、同名网络连接错误等问题。
• 电源网络统一命名。3.3V、5V、GND这些网络名称全图一致，避免出现5V和VCC这种混用导致看不出来的问题。
• 核对元器件封装。比如电阻电容是0603还是直插，排针间距是不是2.54mm，继电器封装脚位方向对不对。
• 核对下载电路。我留了4针SWD接口：SWDIO、SWCLK、3.3V、GND。千万别画成JTAG那种20pin，ST-Link用SWD模式只要4根线就够了，省空间又方便。

打样的话直接下单到常规PCB厂，这个板子双面布线，1.6mm板厚，沉金工艺，十来块钱就能打十片。元件清单Excel里有我写的采购参考价，整套元器件加起来不超过五十块钱，对学生党很友好。

4. 核心代码实现：从采数到联动

4.1 ADC采集烟雾浓度与滑动滤波

MQ-2输出的模拟电压直接连到PA0，用STM32F103内置的12位ADC来读。配置我用STM32CubeMX完成：ADC1、通道0（PA0）、采样时间55.5周期，转换模式为单次转换。这里有个细节，连续转换模式下偶尔会读到因电源纹波造成的噪声，所以我最终采用了单次转换加多次采样的方式。

实际读取代码做了8次采样取平均，相当于一个简单滑动滤波器：

#include "adc.h" uint16_t smoke_get_adc_value(void) { ADC_ChannelConfTypeDef sConfig = {0}; uint32_t sum = 0; for (int i = 0; i < 8; i++) { HAL_ADC_Start(&hadc1); HAL_ADC_PollForConversion(&hadc1, 100); sum += HAL_ADC_GetValue(&hadc1); } return (uint16_t)(sum / 8); }

为什么不能直接读一次就用？因为MQ-2的响应特性是缓慢变化的，同一时刻读到的值受气流扰动影响会有几十到上百LSB的跳动，直接拿单次值做阈值判断很容易造成临界状态下报警反复触发。取平均之后波动能压到很小。如果要更强一点，可以用中位值滤波，把8次采样排序取中间值，能有效剔除个别离谱的尖峰。我代码里默认用的是平均值，因为计算简单、实时性好。

另外我建议你留一个“基线记录”功能，开机后先让系统跑30秒，把这段时间的ADC平均值存下来作为干净空气基线。后面报警判断时，用当前值减去基线值再和阈值比较，这样即使换了传感器环境，也不用重新编译代码。

4.2 DHT11单总线温湿度读取

DHT11的读取时序是这个项目里最磨人的部分。它用的单总线协议，只有一根数据线，所有通信靠严格的时序完成，步骤是：

• 主机把总线拉低18~20ms，作为起始信号。
• 主机释放总线，拉高20~40us。
• 传感器响应，先拉低80us，再拉高80us。
• 然后连续输出40位数据：湿度整数、湿度小数、温度整数、温度小数，最后8位是校验和。

每一位的读法是：传感器先拉低50us表示起始，然后拉高，如果高电平持续26~28us代表“0”，持续70us左右代表“1”。所以代码里读取一个位的核心逻辑就是测量高电平持续的时间：

uint8_t dht11_read_bit(void) { while (DHT11_DATA_IN() == RESET); // 等待50us低电平结束 delay_us(40); // 在40us处采样高电平状态 uint8_t bit = DHT11_DATA_IN(); while (DHT11_DATA_IN() == SET); // 等待剩下的高电平结束 return bit; }

这里最关键的一点是微秒级延时必须准确。我是在SysTick中断和代码执行路径都干净的情况下，用简单的空循环延时函数实现的。如果你开了操作系统或者多个中断，微秒级时序很容易被打断，一个中断处理进去几十微秒就过去了，读出来的数据全是错的。我的处理办法是读取DHT11期间关中断，读完再开，虽然简单粗暴但非常有效。

每次读完40位数据后，还要做一次校验：湿度高8位、湿度低8位、温度高8位、温度低8位四个字节相加，取低8位，应该等于第五个字节。校验不过就直接丢弃这次数据，不参与状态判断，避免驱动程序的时序问题污染决策逻辑。

4.3 火焰检测与预警状态机

火焰传感器的数字输出接到PA2，读到的电平就是“有无明火”的粗判。但是单独靠它做判断肯定不行，阳光、白炽灯、红外加热设备都会干扰。所以我在软件里没有让任何单一传感器直接判定警报，而是用一个状态机综合多路数据：

typedef enum { STATE_NORMAL, STATE_WARN, STATE_ALARM } alarm_state_t; alarm_state_t alarm_update_state(uint16_t smoke_adv, uint8_t flame, float temp) { if (flame == 1 || smoke_adv > SMOKE_HIGH_TH || temp > TEMP_HIGH_TH) return STATE_ALARM; if (smoke_adv > SMOKE_WARN_TH || temp > TEMP_WARN_TH) return STATE_WARN; return STATE_NORMAL; }

阈值我分成了两级：预警阈值和警报阈值。比如烟雾值超过预警阈值但没到警报阈值，系统只响蜂鸣器、快闪LED，不切负载；超过警报阈值，或者检测到明火信号，继电器才动作，排风扇启动、危险负载断电。

这里我还要加一层去抖逻辑：状态不连续保持一定次数不切换。也就是两次采样间隔200ms，连续三次都判定为警报，才真正进入警报状态。这样可以滤掉火焰传感器受瞬时红外干扰产生的尖峰，避免系统一秒钟前还在正常、一秒钟后就误动作。去抖导致的延迟是400ms左右，对火灾响应来说完全可接受。

4.4 报警联动与显示逻辑

执行输出我用一个统一的函数来更新，根据状态枚举值去设置蜂鸣器、LED和继电器，主循环只负责采集数据和调用状态机，界面逻辑被彻底隔离出来：

void alarm_output_update(alarm_state_t state, uint16_t smoke, uint8_t flame, float temp) { switch (state) { case STATE_NORMAL: HAL_GPIO_WritePin(BUZZER_GPIO, BUZZER_PIN, GPIO_PIN_RESET); HAL_GPIO_WritePin(RELAY_GPIO, RELAY_PIN, GPIO_PIN_RESET); break; case STATE_WARN: HAL_GPIO_WritePin(BUZZER_GPIO, BUZZER_PIN, GPIO_PIN_SET); // 预警持续响 HAL_GPIO_WritePin(RELAY_GPIO, RELAY_PIN, GPIO_PIN_RESET); break; case STATE_ALARM: HAL_GPIO_WritePin(BUZZER_GPIO, BUZZER_PIN, GPIO_PIN_SET); HAL_GPIO_WritePin(RELAY_GPIO, RELAY_PIN, GPIO_PIN_SET); // 联动动作 break; } display_update(state, smoke, flame, temp); printf("[ALARM] state=%d smoke=%d flame=%d temp=%.1f\r\n", state, smoke, flame, temp); }

实际到项目里，蜂鸣器驱动我用了定时器PWM做节奏控制，预警状态是响一秒停一秒，警报状态才是连续响。PWM控制的好处是声音不是生硬的“啪”一下，而是软件可控的长鸣或短鸣，不会因为持续高电平把蜂鸣器烧坏。OLED显示就简单了，用软件I2C接SSD1306，一行显示状态，一行显示温度和湿度，一行显示烟雾ADC值。串口日志我开了重定向，接上USB转TTL在电脑上就能看到实时数据，这个功能在调试阶段帮了我大忙。

主循环大概长这样：每200ms扫一次传感器，读取ADC和DHT11，跑状态机，更新输出。没有用定时器中断去轮询，直接阻塞式循环，逻辑简单，时序稳定，适合这个体量的系统。

5. 实操复现：从仿真到实物

5.1 环境搭建与CubeMX配置

先准备三样软件：Keil5用于编译下载，STM32CubeMX用于图形化配置，Proteus 8用于仿真验证。如果你不喜欢Proteus，Wokwi在线仿真平台也能做快速验证，但Proteus对STM32F1的模型支持更成熟，硬件外设更全，所以我还是选了Proteus作为官方仿真的载体。

用CubeMX配置工程有几个关键步骤不能漏：

• 芯片选择STM32F103C8。
• SYS标签页把Debug设为Serial Wire，否则ST-Link下载一次就锁死。
• RCC设为外部晶振，时钟树里HCLK直接拖到72MHz。
• ADC1使能通道0，采样时间可以选55.5周期，这个值偏长，但读取更稳定。
• PA1、PA2、蜂鸣器、继电器等引脚全部设为GPIO输出或输入，速度选中速即可。
• 串口1使能，波特率115200，用于调试日志。

生成代码之后，把传感器驱动和状态机对应的.c文件加进工程，编译一遍确认没有警告清零。Keil里输出选项记得勾选生成HEX文件，因为Proteus仿真需要hex文件，ST-Link下载也可以用hex。

5.2 Proteus仿真联调的关键点

打开仿真工程后，第一眼看到的是完整电路：STM32F103C8、三颗传感器等效模型、蜂鸣器、LED和继电器。Proteus元件库里并没有真实MQ-2模型，我用的是一个电位器接到ADC通道来模拟烟雾浓度变化——这其实是仿真环境里很合理的替代方式。DHT11在Proteus里有现成模型，双击它可以直接改温度值。火焰传感器用开关量模拟，给高电平代表检测到明火。

仿真调试最有价值的点在于，你能在不接任何真实硬件的情况下验证状态机的逻辑是否正确。操作方法是：启动仿真后，旋转那个模拟烟雾浓度的电位器，观察OLED上的ADC数值变化；把温度值改成60度以上，看系统是不是进入了警报状态并让继电器动作；给火焰信号置高，确认蜂鸣器开始响。

仿真跑通只能证明软件逻辑对，硬件问题它是测不出来的。这也是我为什么总要强调仿真和实物结合的原因。仿真阶段把逻辑验证扎实，到了焊接实物阶段，你只用专心排查电气问题，不用再纠结代码写没写对。

5.3 焊板、烧录与实物验证流程

实物接线严格对照我写在README里的表格：

焊接完成后，上电前先用万用表蜂鸣档检查电源正负极之间有没有短路，这是第一道保险，免得烧芯片。然后插上ST-Link，按住复位，在Keil里点下载。如果下载失败，检查SWDIO和SWCLK有没有接反，Debug配置里的下载器型号有没有选对。

实物调试有个大坑必须先说：MQ-2首次通电后不能马上用来判断数据，它内部的加热丝需要时间让敏感层稳定下来，一般要预热五分钟以上，读数才会落到一个平稳的基线。我第一次调试时不知道这个，开机电平一高一跳，直接触发了一轮警报，吓了自己一跳。正确做法是上电后跑一个“开机标定”流程，程序里记录预热结束时的基线值，后续所有判断都基于相对变化量。

最后做验证实验：用酒精棉球靠近MQ-2，观察ADC值上升；用打火机不点火只出气靠近，触发警报；把加热设备启动，观察温度曲线变化。每触发一次都要确认蜂鸣器、继电器动作正确。全部通过，这套系统就算真正落地了。

6. 常见问题与排查技巧实录

6.1 传感器数据异常的排查速查表

实际调试中我踩了不少坑，整理了一张速查表，基本覆盖了最常见的翻车现场：

6.2 仿真与实物不一致的根本原因

仿真跑得好好的，实物一接就不对，这是每个做嵌入式项目的人都会经历的事。根本原因在于仿真环境把很多东西理想化了：Proteus里的ADC不会有电源噪声，DHT11模型不会出现时序微差，继电器的吸合电压也不需要大电流驱动。

我遇到最典型的问题是，仿真里用电位器模拟烟雾浓度，效果非常完美，但实物接上MQ-2后，ADC读数在警报阈值附近来回横跳，导致蜂鸣器响一下停一下。排查发现原因有两个：一是MQ-2的响应本身就带有波动，二是USB供电在蜂鸣器动作瞬间电压被拉低，影响了AD转换的参考电压。解决办法是给蜂鸣器和继电器单独从5V供电端走线，ADC采样前端加RC低通滤波，并且把状态机的去抖次数从3次提高到5次。这些问题在仿真里永远碰不到，只能在实物阶段慢慢磨。

6.3 误报与漏报的调优经验

整套系统调完以后，最花时间的是平衡误报和漏报。阈值设得太低，空气稍微有点湿度变化就报警；阈值设得太高，真着火又不响应。

我的经验是分三步调：

第一步，搭一个干净环境，记录开机标定后稳定运行的基线值。烟雾ADC基线值可能因为传感器个体差异、供电电压不同而不同，必须以实际测量为准。

第二步，人为制造不同强度的干扰源，比如酒精挥发、打火机气体、热风枪加热，记录每种情况下ADC值和温度值的变化范围，找出预警阈值和警报阈值之间的合理间隔。

第三步，引入滞回比较。当烟雾值超过阈值时触发报警，但当烟雾值回落到“阈值减去一个滞回量”时才恢复。这个滞回量能有效防止临界状态下的反复抖动。比如预警阈值设为基线加300LSB，滞回量设为80LSB，那么报警后要降到基线加220LSB以下才恢复。这样现场环境造成的微小波动就不会让系统来回横跳。

漏报问题主要靠传感器布局解决。MQ-2要安装在空气流通路径上，不要装在墙角或者设备背面；火焰传感器要朝向可能的明火来源，避免被机柜挡住。多传感器之间用“或”逻辑，任何一个确认都足以触发联动，这也是我为什么坚持要在系统里同时保留烟雾、温度和火焰三路信号的原因。

最后再聊点我自己实际操作中的体会。做这种带传感器和继电器的系统，花时间的往往不是代码逻辑，而是电气问题：接触不良、电源拉垮、接地混乱，我调试时有接近一半时间花在这上面。仿真跑通只代表逻辑对，实物上电前一定要先量电源、再量信号，逐模块点亮，先把不确定的东西排除掉。代码里保留串口打印是特别值得的，很多看起来玄学的问题，一旦把实时数据打出来看，原因就现形了。

这个项目后续扩展空间我觉得挺大：加ESP8266把数据推到物联网平台，加OLED菜单在本地配置阈值，用FreeRTOS把采集、判断、显示拆成独立线程，或者整体换成ESP32做低功耗无线终端，都是很好的练手方向。仓库里后续我还会补更详细的注释和使用视频，如果你复现过程中遇到问题，优先对照引脚表和接线表，再对照排查表逐条查，大概率能自己解决。希望这套开源资源能让你少走点弯路。