基于STM32的温湿度检测报警系统设计实战

1. 项目脑图与需求还原：这个系统到底在解决什么问题

先说个实在话。很多刚接触嵌入式的朋友看到"基于STM32单片机温湿度检测报警系统的设计与实现"这种标题，第一反应是"又一个课设答辩题"，第二反应是"网上代码一大把，随便抄抄就完事"。但真把这个项目从头到尾跑通、调稳、甚至敢拿出来给客户或者导师现场演示，你会发现它根本不是"抄抄代码"那么轻巧的事。

我当年接手类似项目时，最先做的不是打开工程模板，而是把需求拆开揉碎。这里说的需求不是"能测温度湿度、超限报警"这种一句话描述，而是要逼自己回答几个具体问题：

• 检测精度要求是多少？是正负0.5度还是正负2度就能交差？
• 采样周期是多久？是每秒刷一次还是每分钟刷一次？
• 报警方式是什么？本地蜂鸣器加LED，还是需要远程通知？
• 人机交互怎么搞？按键设阈值、OLED显示，还是串口接上位机？
• 设备供电方式？USB供电还是电池供电？这直接决定功耗设计。
• 现场环境怎么样？是干净机房还是潮湿农业大棚？传感器的选型完全不同。

我之所以强调这些，是因为这个项目看似简单，实际它是一条完整的嵌入式开发链条：需求分析、器件选型、原理图设计、PCB或者面包板搭建、驱动调试、业务逻辑编写、异常处理、现场测试。任何一个环节偷懒，后期都会以"诡异Bug"的形式回来找你。

这个项目的核心价值也在这里：它不是教你背诵某个芯片的寄存器，而是让你经历一遍"从零到一做一个小型测控节点"的完整过程。做完这个项目，你再去碰MQTT上云、Modbus组网、RTOS任务调度，会有一种"底层通了、上层随便搭"的从容感。

我自己在带项目的时候常说一句话：单片机项目没有真正的"小项目"，只有还没暴露问题的"小项目"。温湿度报警系统就是那个最容易暴露问题、也最能锻炼人的样板。

1.1 要实现的完整功能清单

在动手之前，我习惯先把功能列成一张表，每条后面注明验收标准。这样做的好处是后期测试时有据可查，不会出现"我觉得这功能应该这样"的模糊扯皮。

这里的每一项拆开来看都不复杂，但合在一起就会互相牵扯。例如你要做掉电保存阈值，就涉及STM32内部Flash操作；你要做按键响应不抖动，就涉及软件消抖和长按短按逻辑；你要做串口上报有校验，就涉及帧格式设计。这些"组合起来的复杂度"，才是这个项目的真正学习点。

1.2 为什么选STM32而不是51或Arduino

这个选择在项目初期就会遇到。我见过不少同学上来就问："用51单片机不行吗？代码还简单。"当然行，但如果你的目标是"理解一个现代MCU的基本工作方式"，STM32明显更有代表性。51的架构太古老，中断、时钟树、外设复用这些概念在51上体现得不充分，学完再切到其他芯片还是会有断层感。

Arduino的问题正好相反，封装得太狠了。你调一个I2C传感器，Arduino库函数一行Wire.read()就完事，但底层是怎么产生START信号的、ACK/NACK怎么处理的，你完全无感。做项目如果只停留在"调库"层面，那和用现成模块拼积木没太大区别。

STM32处在中间位置：寄存器可以操作，HAL库也可以用，时钟树要自己配，引脚复用要自己查表，中断优先级要自己规划，但又不至于像裸写寄存器那么痛苦。做完这个项目，你会对以下概念有实打实的体感：

• 时钟树和总线频率（APB1、APB2、定时器时钟倍频）
• 引脚复用AF和上下拉配置
• 定时器的PWM输出和输入捕获
• I2C和UART通信时序
• ADC采集与参考电压
• 中断服务函数里不能做耗时操作（这个教训我会在后面详细讲）

一句话总结：STM32的复杂度刚好够用，既能让你踩到嵌入式的典型坑，又不至于被坑埋掉。

2. 硬件方案取舍：传感器和显示模块才是隐形坑王

这个项目的硬件选型说难不难，但有几个决定项目成败的细节。我先给出一套我实测稳定、被多个项目沿用过的配置，再逐项说明为什么这么选。

核心器件清单：

• 主控：STM32F103C8T6（最小系统板即可，性价比高，资料多）
• 温湿度传感器：DHT11（入门够用） / SHT30（想要精度可换）
• 显示：0.96寸OLED（I2C接口，4针），或者LCD1602（如果想玩并口）
• 报警：有源蜂鸣器 + 三极管驱动 / 无源蜂鸣器 + PWM驱动
• 输入：3个独立按键（设置、加、减）
• 供电：USB 5V转3.3V（AMS1117稳压模块即可）

2.1 温湿度传感器选型：DHT11、DHT22、SHT30怎么取舍

这是新手第一个容易踩的坑。我看到很多人一上来就选DHT11，因为教程多。但DHT11有两个硬伤：精度不高（温度正负2度，湿度正负5%RH），且采样周期要大于1秒。如果你的项目是"现代农业大棚环境监测"，这个精度根本不够看，湿度差5%可能导致风机判断错误；如果你的项目是"机房设备环境监控"，正负2度可能触发误报警。

我自己的选型建议分三档：

• 预算极有限、演示够用：DHT11，但要在代码里做软件滤波，把偶发的跳变值滤掉。
• 预算中等、追求可靠：DHT22（AM2302），精度提升到正负0.5度和正负2%RH，采样周期2秒起步。
• 预算充足、想学I2C通信：SHT30，精度高且自带CRC校验，直接走I2C总线，不用自己写时序驱动。

如果你选DHT11，我强烈建议用下面这段逻辑做数据有效性判断：连续读取两次，如果差值过大就丢弃本次数据，使用上一次有效值。这样能避免传感器偶发输出0或255这类明显异常值。

// 伪代码示例：DHT11数据有效性判断 uint8_t temp = readTemp(); // 假设是传感器返回的整数 uint8_t hum = readHum(); static uint8_t last_valid_temp = 0; static uint8_t last_valid_hum = 0; if (temp != 0xFF && temp != 0x00 && hum != 0xFF && hum != 0x00) { if (abs(temp - last_valid_temp) < 10) { // 温度突变超过10度视为异常 last_valid_temp = temp; } if (abs(hum - last_valid_hum) < 20) { last_valid_hum = hum; } } // 否则继续使用 last_valid_temp / last_valid_hum

我见过不少人读DHT11读着读着数据就变成255，查了半天发现是杜邦线接触不良导致数据线被拉死。这种问题在代码上做的防护就是上面这一层"数据有效性过滤"，硬件上则是把传感器排针焊死、上拉电阻接好。

2.2 显示方案：OLED的I2C地址坑与刷新策略

显示模块我优先推荐0.96寸OLED，因为I2C只占两个引脚，接线简单，显示效果也好看。但这个模块有两个坑值得提前说。

第一个坑是I2C地址。市面上常见的OLED驱动芯片是SSD1306，默认从机地址通常是0x3C，但也有厂家做成0x3D。你在初始化时如果发现屏幕不亮，第一件事就是检查地址是不是被写死成0x78（注意这里是7位地址左移一位后的8位地址写法）。我习惯在代码里留一个宏，方便切换：

#define OLED_I2C_ADDR 0x3C // 实测大多数模块是0x3C，个别是0x3D

第二个坑是刷新策略。如果每隔100毫秒就整屏刷新一次，你会看到明显的闪烁，尤其在显示数字变化时会有残影。更好的做法是"局部更新"：只在数值变化的区域写内容。SSD1306支持页地址模式，你可以用setCursor(x, y)先指定位置，再只发送几个字符的数据。这样显示稳定，CPU占用也低。不会写的朋友可以先查一下SSD1306的显示缓冲区和页概念，这个理解后OLED编程会清晰很多。

如果不用OLED，LCD1602也可以，但1602的并口接线要多4根数据线，按键加显示堆在一起会让面包板变得极其混乱。我不建议在原型阶段用1602，除非你用的I2C转接板。

2.3 报警电路与驱动：有源蜂鸣器为什么需要三极管

蜂鸣器分有源和无源两类。有源蜂鸣器内部自带震荡源，给高电平就能响，编程最简单；无源蜂鸣器需要外部给一定频率的方波才能发声，好处是可以改变音调做"滴滴、滴滴"的节奏感。我的做法是：如果只是做报警指示，用有源蜂鸣器加一个NPN三极管驱动就够了。

这里为什么要加三极管，而不是直接用STM32引脚驱动蜂鸣器？因为蜂鸣器正常工作电流在20到30毫安左右，STM32单个GPIO的最大灌电流和拉电流虽然手册上写的是正负8毫安左右，但长期接近极限输出会发热，而且蜂鸣器是感性负载，关断瞬间会有反向电动势，可能干扰单片机甚至导致复位。用一个S8050三极管做开关，GPIO只负责控制基极电流，蜂鸣器接在集电极回路里，供电直接走5V或者3.3V，这样两边各司其职，稳定很多。

典型接线（以NPN管为例）：

• 蜂鸣器正极接VCC，负极接集电极C
• 发射极E接地
• 基极B串一个1k欧电阻接单片机GPIO
• 蜂鸣器两端反并联一个1N4148二极管（吸收关断瞬间的反向电动势）

很多教程不提这个二极管，实测下来不接也能响，但系统可靠性真不一样。尤其是电池供电或者现场电磁环境复杂的场景，这个二极管能救你两次。

3. 软件框架与状态机设计：掌控全局的诀窍

接下来是软件部分。很多人写单片机代码是"裸奔式"写法：main函数里一个while循环，里面读传感器、刷新显示、扫描按键、判断报警，全部顺序执行。这种写法在功能简单时没问题，但一旦你要加"按键按下后进入设置模式、这时候传感器暂时停止报警"这种状态切换，顺序执行就会变得很痛苦。

我建议从项目一开始就引入"状态机"思想。不用上升到复杂框架的程度，只需要把系统分成几个明确的运行状态，每个状态下只处理该处理的事。

3.1 系统状态划分与状态跳转规则

这个项目我习惯分四个状态：

• IDLE / 正常运行态：采集数据、显示数据、判断报警条件。按键短按"设置"键进入设置态。
• SET_TEMP_HIGH / 设置温度上限态：显示当前上限值，按"加/减"修改，按"确认"或"设置"键切换下一个设置项。
• SET_TEMP_LOW / 设置温度下限态：同上。
• SET_HUM_HIGH / SET_HUM_LOW：湿度上下限设置。
• 也可以把所有设置项放在一个"设置态"里，用光标位置区分当前项。

状态跳转的规则要清晰定义：比如设置态持续30秒无按键，自动保存并退回IDLE态。这个"超时退回"细节非常重要，我见过很多项目设置到一半忘记按确认，结果阈值停留在奇怪的值上，设备一直在误报警。

状态机的核心实现其实很简单，一个uint8_t state变量加switch-case：

typedef enum { STATE_IDLE, STATE_SET_TEMP_HIGH, STATE_SET_TEMP_LOW, STATE_SET_HUM_HIGH, STATE_SET_HUM_LOW, STATE_ALARM, } SysState_t; SysState_t current_state = STATE_IDLE; void system_loop(void) { switch (current_state) { case STATE_IDLE: handle_idle(); break; case STATE_SET_TEMP_HIGH: handle_set_temp_high(); break; // ... } }

这样做的好处是，每个功能模块被限制在特定状态下运行，逻辑清晰，后期加功能不会把代码搅成一锅粥。而且出Bug时排查范围小很多。

3.2 按键扫描与消抖：从delay到非阻塞的进化

按键处理是新手另一个"重灾区"。最常见的问题是写一个delay(20)做消抖，然后发现按键偶尔会一次触发两次，或者在按键长按时系统卡死。

我的实测做法是"定时器节拍 + 状态标志"的结构。核心思路是：让定时器中断以1到5毫秒的周期运行，在中断里做按键扫描和消抖，把"按键事件"（按一下、长按、短按）以标志位的形式暴露给主循环。主循环检测到标志就把对应处理函数执行一次，然后清掉标志。

// 伪代码：定时器中断里的按键扫描 volatile uint8_t key_filter_cnt = 0; volatile uint8_t key_state_stable = KEY_RELEASE; volatile uint8_t key_event = KEY_NONE; void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update)) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); uint8_t level = GPIO_ReadInputDataBit(KEY_PORT, KEY_PIN); if (level == GPIO_ReadInputDataBit(KEY_PORT, KEY_PIN) && level == KEY_PRESS_DOWN) { key_filter_cnt++; if (key_filter_cnt >= 4) { // 连续4次采样均为按下 if (key_state_stable == KEY_RELEASE) { key_event = KEY_CLICK; // 刚按下，产生一次点击事件 } key_state_stable = KEY_PRESS_DOWN; } } else { key_filter_cnt = 0; if (key_state_stable == KEY_PRESS_DOWN) { key_event = KEY_RELEASE; // 松开事件 } key_state_stable = KEY_RELEASE; } } }

这个结构的好处是：扫描不阻塞CPU，消抖参数（连续4次）可以根据按键手感调整，而且还给后续"长按"、"组合键"留了扩展空间。按键的短按和长按可以在主循环里通过记录按下时间戳来判断。

3.3 阈值存储：用STM32内部Flash模拟EEPROM

设置好的温湿度上下限如果断电就丢，这个设置功能等于没用。STM32F103内部没有真正的EEPROM，但有一个办法：利用Flash的最后一个扇区（通常是1024字节），自己做一个简单的"存储-读取"接口。

这里有一个需要特别注意的坑：Flash的擦写寿命有限（F1系列大概1万次擦写寿命），而且擦除必须按扇区来。如果你每次设置完阈值就去擦除写一遍，可能几个月后Flash就废了。更稳妥的方案是"磨损均衡"：在扇区里按固定格式追加记录，读的时候从尾部往回扫描最新记录；当扇区快满时再整片擦除重写。

不过说实话，对于这个项目、个人学习场景，1万次擦写其实够了。你一天改10次阈值，也能用三年。所以我建议第一版直接实现最简单的方案：

• 在Flash扇区末尾地址写入固定字节数组（比如0xA5, 温度上限, 温度下限, 湿度上限, 湿度下限, 校验和）
• 上电时读取该地址，检查校验和，通过则加载，不通过则用默认值。
• 修改阈值时先擦除扇区再写入。

写入时一定要做校验和。不然哪天Flash里存了残留数据，读出来温度上限是0度，系统一开机就进入报警状态，那才叫欲哭无泪。

3.4 传感器通信时序：DHT11的单总线协议

如果你选SHT30，下面这段可以跳过，I2C通信由硬件外设帮你扛了。但如果用DHT11，你就得自己跟它的单总线协议死磕。这个协议的难点不在逻辑复杂，而在时序要求苛刻：主机拉低总线至少18毫秒启动采集，然后释放总线，传感器响应后拉低80微秒，再拉高80微秒，之后输出40个数据位。每一位的数据"0"是拉低50微秒后拉高26到28微秒，"1"是拉低50微秒后拉高70微秒。

测量这个"高电平持续多长"是关键。在STM32上最直观的办法是用定时器输入捕获，但新手往往嫌麻烦，直接用delay_us()加GPIO_ReadInputDataBit()轮询来做。我自己也这么干过，但必须提醒几个坑：

• 读取过程中要关中断，或者确保定时器中断不被触发，否则一个中断进去几十微秒，时序就崩了。
• 在STM32F103上，软件延时delay_us()在开启优化后有偏差，建议用示波器或者逻辑分析仪校准一下，尤其是有传感器完全不响应时要怀疑延时精度。
• 总线上最好接一个4.7k到10k的上拉电阻，DHT11虽然内部有上拉，但外部再加一颗会更稳定。

读出来之后还有一个细节：DHT11的湿度是整数位+小数位，组合方式是"湿度整数 + 湿度小数 + 温度整数 + 温度小数 + 校验和"共5字节，小数位在多数模块上恒为0。要按这个格式拆分，别把校验和当成数据。

4. 报警逻辑与异常场景设计：让系统"会判断"而不只是"会执行"

很多人做完这个项目，报警逻辑就是简单一句if (temp > max) beep_on();。这不叫报警设计，这叫条件判断。真正开发一个可用的报警系统，要考虑的问题比这多得多。

4.1 报警条件与迟滞控制

单一阈值报警有一个很讨厌的毛病：报警阈值附近温度抖动时，蜂鸣器会"反复横跳"。比如设置上限30度，实际温度在29.9和30.1之间跳，系统就会不停地"响-停-响-停"，既吵又伤蜂鸣器。

解决这个问题最常用的办法是"迟滞比较"。定义两个阈值：报警触发值和报警恢复值。比如温度上限设为30度，迟滞设为0.5度，那么触发报警要超过30度，但解除报警要降到29.5度以下。这样中间出现30.2度触发报警，降到29.8度时并不会立刻解除，必须等它一路跌到29.5以下才消停。这个"中间地带"就是迟滞区间。

#define TEMP_HIGH_ALARM 30.0f #define TEMP_HIGH_RECOVER 29.5f // 30.0 - 0.5 迟滞 if (state == STATE_ALARM) { if (temp < TEMP_HIGH_RECOVER) { state = STATE_NORMAL; buzzer_off(); } } else { if (temp > TEMP_HIGH_ALARM) { state = STATE_ALARM; buzzer_on(); } }

这个思路在工业现场用的极多，你可以把它理解为"给判断加了一点记忆"，避免系统在边界条件上反复震荡。同样的逻辑也适用于湿度下限报警。

4.2 传感器掉线与坏了怎么办

这里我要强调一个很多人忽视的点：传感器如果一直读不到数据，系统该怎么办？

我见过最粗糙的处理是：读不到数据直接返回0，结果温度显示0度，系统认为低温报警一直响。更合理设计是单独检测"传感器在线状态"，如果连续N次读取失败，就认为传感器掉线，这时候应该显示"ERR"并触发一个区别于超限报警的提示音，比如"滴-滴-滴"三声停顿，而不是一直长鸣。

实现方式是在状态机里增加一个SENSOR_ERROR状态，蜂鸣器以慢节奏鸣响，OLED上显示错误码。这样客户一眼看出是传感器问题，而不是阈值设置问题。

4.3 报警声音与指示灯联动：别把交互做成一团浆糊

报警不只是"响"那么简单，还要让人分清报警类型。我做过一个版本，用蜂鸣器节奏区分温度报警和湿度报警：

• 温度超限：每500毫秒响一次，滴、滴、滴。
• 湿度超限：每200毫秒连响三声，然后停一秒。
• 传感器错误：持续鸣叫但不闪烁。

配合LED状态灯也是一种方式：正常时绿色LED闪烁，报警时红色LED常亮，设置状态下黄色LED亮。如果有OLED，界面上的状态图标可以更直观。

这些交互设计的价值是：当现场只有一个人值班，设备半夜报警，他必须知道"发生了什么"才能快速处理。如果一切报警都一个响法，他只能爬起来看代码。

5. 系统稳定性与现场部署：从"能跑"到"跑得久"的关键几步

到了这个阶段，你的系统应该已经能正常工作了。但"能跑"和"能在现场长期稳定跑"之间，还隔着好几个问题。这个章节我会把我在实际部署中遇到的问题和验证方法讲透。

5.1 供电与电压跌落

很多人用USB线给单片机供电，然后传感器和蜂鸣器全从单片机3.3V引脚取电。看似没问题，实则隐患很大。蜂鸣器启动瞬间电流可能达到30毫安以上，加上OLED显示电流、传感器工作电流，如果USB线内阻大或者电源质量差，3.3V电压会被拉低，导致单片机复位。

我的建议是至少用两个供电分区：逻辑区（单片机、传感器、OLED）和功率区（蜂鸣器、继电器、LED）。功率区直接接5V或者外部电源，逻辑区从3.3V取。如果项目要控制继电器，一定再加光耦隔离，否则继电器电感产生的尖峰分分钟把单片机搞死。

实测技巧：用万用表测一下蜂鸣器启动瞬间单片机VDD引脚上的电压，如果跌落超过0.3V就要警觉。

5.2 看门狗到底怎么用

STM32内部有独立看门狗（IWDG）和窗口看门狗（WWDG）。在这个项目里我推荐用独立看门狗。它靠独立的40kHz内部低速时钟驱动，只要主循环在设定时间内没有"喂狗"，系统就自动复位。

喂狗的点应该放在主循环的某个固定位置，而不是放在中断里。如果放在中断里，即使主循环已经死掉，中断还在跑，看门狗永远不超时，就失去意义了。我在项目里是把"喂狗"放在状态机处理完成之后。这样如果程序卡死在某个状态机的死循环里，看门狗能把它拉回来。

但也要注意看门狗不是万能的。如果程序逻辑有Bug，复位后还是同样路径，机器就会陷入无限重启。所以调试阶段可以先把看门狗关掉，等逻辑稳定后再开启。

5.3 通信协议里的帧校验与超时处理

如果加了串口对接上位机，数据帧设计要简洁可靠。我习惯用"帧头 + 数据长度 + 数据 + 校验和"的结构：

// 上位机查询帧：0xAA 0x01 0x01 0x55 // 设备响应帧：0xAA 0x04 0xXX(温度高8位) 0xXX(温度低8位) 0xXX(湿度) checksum 0x55

校验和可以简单把前面所有字节相加取低8位。这个字段能挡住大部分串口干扰导致的错帧。另外接收端要做超时处理：如果收到了帧头但后续字节迟迟不来，超过一定时间要把缓冲区清空，防止错位。

这里还有一个经验之谈：串口接到单片机之前，先不要连TX线，只连GND和RX，用示波器或者逻辑分析仪看看上位机发过来的波形对不对。很多人一插上去发现数据乱码，查了半天是"单片机TX连到单片机TX"这种低级错误。

6. 项目调试实录与避坑经验速查表

最后这部分，我把这些年调试温湿度报警系统时踩过的坑集中列一下，并附带排查思路。之前项目里有一位朋友调试了整整三天，最后发现是OLED地址配错，屏幕一直黑，他还以为是I2C速率问题，把所有时序参数都改了一遍。这种经历我想让大家少走一点。

6.1 典型现象与根因速查表

6.2 调DHT11时的独门心得

我调DHT11时最崩溃的一次是：传感器单独用一个杜邦线接到板子，悬空放着读数正常，一装进外壳就读数失败。后来发现是外壳设计把传感器出风口堵住了，热空气积聚导致传感器周围温度比环境高，同时湿度饱和。这类"环境问题"在实验室里永远测不出来。

所以我在这个项目里养成了一个习惯：传感器区域要开透气孔，且不要紧靠MCU和其他发热元件。如果是做机箱内监测，传感器探头要尽量拉出来放到被测区域中央。数据不是"读出来"就完了，你得确认传感器测的是"你关心的那个位置的温度"。

另一个心得是：DHT11的上拉电阻不是可选项，是必选项。即使模块上标了"内部已带上拉"，我也强烈建议在数据线上加一颗4.7k到10k的电阻到VCC。这样在杜邦线稍长、寄生电容变大时，信号边沿不会太缓。

6.3 给新手的上手路径建议

如果你是从零开始做这个项目，我的建议顺序是：

1. 先点亮OLED，跑一个"Hello World"，把I2C通信确认通。
2. 再单读DHT11，把温湿度数值通过串口打印到电脑，确认数据可信。
3. 加上显示，让OLED显示实时数据。
4. 加入按键和状态机，实现阈值设置，这步要分小步做，每完成一个状态就测试。
5. 加入报警逻辑和蜂鸣器，先实现最简单的超限响，再加迟滞。
6. 最后做掉电保存、看门狗、串口协议、异常处理。

每走一步都要在真实硬件上验证。嵌入式调试没有"这代码肯定没问题"这种事，每一步验证过了，后面才敢叠功能。

6.4 代码维护习惯：注释和版本管理比你想的重要

这个项目做到后面，代码会膨胀到几百行。如果你不写注释，过两个星期再打开工程，你会看着自己写的代码发呆。我在代码里习惯用比较直白的注释标注关键逻辑：

// 注意：修改温度上限时，需同步修改下限，避免上下限交叉导致逻辑混乱

还有一个容易被忽略的点：用版本管理工具管理你的工程。哪怕是自己一个人做，也建议每完成一个阶段提交一次。这样当你改坏了想回退时，不会对着灾难现场无从下手。我见过有人为了改一个功能，把整个main函数重写，最后发现还不如旧版，但没有备份只能从头再来。

7. 向实际应用延伸：温湿度检测系统还能玩出什么花样

项目做到底，一定会有一个问题冒出来："然后呢？"。这个温湿度检测报警系统，其实是很多大型系统的"最小可用版本"。把它武装起来，可以往多个方向发展。

7.1 接入云平台：从本地报警到远程告警

最自然的方向是加一个ESP8266模块，通过串口和STM32连接，把温湿度数据以JSON格式上报到云服务（比如接入物联网平台）。这样你在手机上就能看到数据，超限时云端推送通知，不再是只能站在现场听蜂鸣器响。

接入WiFi时要注意：ESP8266模块的供电峰值高达300毫安级别，绝不能直接从STM32的3.3V引脚取电，否则电压跌落会让单片机复位。需要用外部稳压模块单独供电，并且STM32和ESP8266之间要共地。串口通信波特率建议115200，双方都要固定。

这部分扩展项目做完，你实际上就摸到了"物联网端侧采集 + 无线传输 + 云端存储"的完整链路，放到简历上比单一的本地报警系统有说服力得多。

7.2 多节点组网与RS485总线

如果检测点不止一个，可以考虑RS485总线组网。STM32的USART通过MAX485芯片转成差分信号，多台设备手拉手挂到总线上，通过Modbus RTU协议通信。主机轮询各个从机的温湿度数据，统一上报或统一报警。这套东西在小型农业大棚、仓库环境监测里都是标配。

组网时会遇到一个新的问题：地址分配和冲突检测。最简单的做法是每台设备一个拨码开关，用3个引脚读取拨码状态作为设备地址。Modbus RTU协议的CRC16校验也是必修课，不能只靠简单的校验和。

7.3 低功耗与电池供电

如果你的应用场景是野外无市电环境，功耗就是核心指标。STM32的低功耗模式包括睡眠、停止、待机三种。对于温湿度检测这种采样周期长的场景，你可以这样设计：

• 每60秒醒来一次，采集数据、判断报警、更新显示（或经过无线模块上报）
• 平时进入停止模式（Stop Mode），电流可以降到微安级别
• 用RTC定时唤醒或外部RTC芯片唤醒

这个方向对代码结构的要求会高一些，状态机的重要性会更加突出。因为"醒来做什么、做多久、怎么睡"变成了一个严格编排的过程，任何多余的延时都是在浪费电池。

我个人觉得，如果你真正把这个项目吃透了，它就像一套乐高积木的底座，后续扩展哪个方向，只是把对应模块"插"上去的事。这也是我为什么愿意花这么多篇幅，把一个看似简单的项目讲得这么细——它的学习密度和扩展价值，远超表面那几个功能。

最后说点实在的。我最初做这个项目时也走过不少弯路，最深刻的一条体会是：不要急着把全部功能堆到一起。先把最小系统跑通，确认传感器读数可靠，再一步一步加功能。每次只改一个变量、测一个功能，出问题时才能精准定位。一个能稳定运行的简单版本，永远好过一堆功能混杂的测试软件。希望这篇内容能让你少踩几个坑，把时间花在真正值得研究的细节上。