最近一直在被问同一个题目：基于STM32的智能家居安防系统设计。这名字听起来很像老掉牙的毕业设计，但真的一步步去落地，会发现里面能讲的东西其实非常多。从芯片选型、传感器信号处理，到报警逻辑怎么写、误报怎么压下去，每一层都有实实在在的坑。这篇文章我没打算做成PPT式的“系统介绍”，而是直接用我实际搭这套系统时的思路来讲：每个芯片为什么选它，每根线怎么接，代码里哪个地方最容易翻车，排障时用什么顺序去查。如果你正准备做这个项目，或者想把一套demo级别的东西改得像能用的真系统，那这篇内容应该能让你少走不少弯路。
这套系统最终做完，本质就干三件事：感知异常、发出本地声光报警、把状态同步到本地屏幕上。传感器用的是人体红外（PIR）、烟雾传感器（MQ-2）、温湿度传感器（DHT11），主控是STM32F103C8T6，报警输出是无源蜂鸣器和LED，显示用I2C接口的OLED屏。它适合谁？我觉得三类人最合适：正在搞嵌入式课程设计、需要一个能讲透的项目来面试的开发者，以及家里正好有点动手能力、真想把门窗和火情监控做出来的普通爱好者。难度不高，但五脏俱全，做一遍基本就把GPIO、中断、定时器、ADC、I2C、状态机这些嵌入式最常见的东西全碰了一遍。
1. 先把需求聊透：这套安防系统到底要防什么
很多新手拿到题目就开始逛淘宝买模块，我觉得顺序反了。先把需求拆清楚，才知道哪些传感器是必须买的，哪些纯粹是买了吃灰。安防系统不是功能越多越高级，而是要在“该报警的时候一定报、不该报的时候不乱报”之间找到平衡。这个平衡，才是整个设计真正花力气的地方。
1.1 功能拆解和模块清单
我给自己列的原始需求清单就四条：
- 能检测到有人入侵，主要覆盖室内活动区域和门口；
- 能检测烟雾和异常高温，防止火情早段没被发现；
- 能实时看温湿度，既有安防作用，也有环境监测价值；
- 一旦有异常，现场要有明显的蜂鸣和灯光报警，同时状态要显示在OLED屏上。
于是模块选型就很直接了：PIR人体红外模块负责入侵检测，MQ-2气敏传感器负责烟雾，DHT11负责温湿度，有源蜂鸣器加LED负责声光报警，0.96寸OLED负责显示。这里先提一句：我刻意没有把摄像头和远程视频放进去，因为那涉及到的带宽、存储和图像识别完全是另一个量级，会冲淡安防逻辑本身的学习重点。做成一个“传感器+控制+本地报警”的闭环，既能把核心逻辑讲透，又方便后续扩展。
这套系统要实现的最终状态是：人在家里的时候，可以切到“撤防模式”，不触发报警；人出门之后，按下布防按钮进入警戒状态，PIR一旦检测到移动，蜂鸣器立刻响，OLED屏幕上显示出报警类型。烟雾和温湿度一直持续监测，不管什么模式下，只要烟雾浓度超过阈值或者温度异常升高，都得给出提示。这样设计，整个项目就有了“逻辑深度”，面试官或者老师问你为什么要做状态切换时，你不会只能说一句“为了不误报”。
1.2 为什么选STM32而不是51或Arduino
这个问题我基本每次都会被问。答案是：这套系统的核心考点在“多外设协同”，而不是“点个灯”。8位单片机当然也能勉强跑，但当你同时要处理PIR的边沿信号、MQ-2的ADC连续采样、DHT11的单总线超时时序、OLED的I2C刷新、蜂鸣器的定时控制时，51那种裸奔轮询会让代码变得非常拧巴。尤其是DHT11的时序要求达到微秒级，8位芯片用软件延时很容易跑偏，读出不稳定数据后你还得怀疑自己的传感器是不是坏了，非常折磨。
Arduino写起来快，但它把底层封装得严严实实，写完了你收获有限。我自己在项目里用到的关键知识，比如GPIO复用、ADC校准采样、状态机设计，全是靠STM32直接接触寄存器级别或者HAL库的回调机制才真正理解的。STM32F103C8T6这块板子的优势还在于便宜、资料多、CubeMX一键初始化工程，遇到问题随便一搜就有案例。性能和性价比摆在这里，做安防类项目它就是那个“最稳的选择”。
还有个容易被忽略的点：STM32跑在72MHz主频下，做实时响应非常从容。PIR模块给出的信号本质是一个开关量，但它需要你“快速检测到上升沿并进入确认流程”；DHT11要求主机释放总线后等待应答，窗口期微妙；这些用定时器中断和高主频处理起来都非常轻松。所以选它的真正理由不是“别人都用它”，而是它的外设资源、主频和调试工具刚好能把这套系统的所有环节都支撑得很舒服。
1.3 传感器选型背后的逻辑
选传感器时我做了点功课，核心看三个东西：输出形式、反应时间、精度够不够用。
PIR我选了HC-SR501。它内部已经做了红外信号处理和比较器，直接输出高/低电平，不需要自己算红外数据，只需要把它当做一个“有人移动时产生高电平”的开关。它的灵敏度距离和输出延时可以通过背面的两个电位器调节，这一点太关键了。实际安装时，如果装在墙角对着窗户，阳光变化或者窗帘飘动都会让输出乱跳，这时候你拧灵敏度电位器就能压下去。
MQ-2选它是看重它的成熟度和对可燃气体、烟雾都敏感的特性。它的输出有模拟量（AO）和数字量（DO）两路。很多人图省事直接接DO，但我建议接AO到STM32的ADC，自己设阈值。道理很简单：DO那一路内部比较器的阈值是固定的，不同环境下你根本没法微调；接AO之后，你可以通过采样多次取平均、设置动态阈值，实现“天稍微热一点也不会误报”的灵活控制。
DHT11在温湿度传感器里算入门级，精度不算高，温度±2℃，湿度±5%RH，但做安防报警完全够用了。关键在于它只靠一根数据线通信，读时序需要精确到微秒级，逻辑上是个很好的训练点，也比I2C的传感器更有“手写驱动”的感觉。OLED屏我选SSD1306驱动的0.96寸款，走I2C，只占用两个IO，省下来的引脚可以留给按键和继电器扩展。
选型这件事，最忌讳的是全上最贵的模块。安防场景里，PIR加MQ-2再加一个DHT11，三个传感器构成的感知层已经覆盖了“闯入、火情、环境异常”三大类主要风险。再加摄像头、指纹锁、烟雾消防联动，那是产品级的事情，不是课程设计和家庭实验的首选。
2. 硬件侧细节：从接线到上电前的检查
硬件部分决定了项目能不能稳定运行。说实话，80%的“代码没问题但现象不对”最后都查出来是硬件或者接线的问题。我一开始也犯过类似的错，觉得接线嘛，对着引脚图插一插就完了，结果OLED死活不亮，最后发现是SDA和SCL两根线接反了。所以说，硬件这块千万别图快，每一个连接都要有据可依。
2.1 板卡选型与电源设计
主控板我直接用最流行的STM32F103C8T6最小系统板，也就是大家常说的“蓝板”。它引出了所有GPIO，上面带一个LED和两个晶振，板上已经有AMS1117稳压芯片，输入5V USB供电就能稳压到3.3V，不需要自己搭电源电路。这个板子在学生项目里特别常见，因为最小系统板比自己画的板子更容易排查问题，出了问题你能确定是板级问题还是自己外设的问题。
电源是整个系统最容易翻车的地方。我的三个模块加一个主控，功耗都不算大，但如果全部从USB口的5V取电，还要注意电流余量。PIR模块工作电流大约小于15mA，MQ-2的加热丝比较耗电，常温下电流在150mA左右，DHT11不到1mA，OLED加上蜂鸣器最大也就几十毫安。总的峰值电流控制在300mA以内，普通电脑USB口输出500mA是够用的，但如果你同时还接了一个ESP8266做远程上报，Wi-Fi发射瞬间电流能飙到300mA以上，这时候整个3.3V电源就会抖动，DHT11读数据就开始出错。
所以我的电源策略是：传感器和主控用USB 5V供电，3.3V由板载LDO输出；如果后面要扩展到Wi-Fi模块，那就要单独配一个5V/2A的适配器，并且给ESP8266单独做一个3.3V供电，不要共用主控板的LDO，否则一开Wi-Fi就复位。这一点是很多人做到后面才发现的坑。
2.2 传感器接线图和信号处理要点
主线连接我整理成表，按表接线可以少走弯路：
| 外设 | 引脚 | 连接到STM32 | 说明 |
|---|---|---|---|
| HC-SR501 PIR | VCC、GND、OUT | 5V、GND、PB0 | 输出高电平表示检测到移动 |
| MQ-2 | VCC、GND、AO | 5V、GND、PA0(ADC1_IN0) | 模拟输出，经ADC换算烟雾浓度 |
| DHT11 | VCC、GND、DATA | 3.3V、GND、PB10 | 单总线协议，需上拉电阻 |
| 0.96寸OLED | VCC、GND、SCL、SDA | 3.3V、GND、PB6、PB7 | I2C1，地址0x3C |
| 有源蜂鸣器 | 正极、负极 | PB1(经三极管驱动)、GND | 不能直接接GPIO灌电流 |
| LED指示灯 | 正极、负极 | PB12、GND | 串联100-220Ω限流电阻 |
| 按键 | 两端 | PB13、GND | 用于模式切换和手动复位 |
DHT11的数据线上必须接一个4.7kΩ到10kΩ的上拉电阻。很多人只按照买到的模块接三根线，模块上自带的上拉电阻其实已经在里面了，所以如果买的是带PCB的模块，通常不用另外加。但如果你买的是裸DHT11元件，那一定得外接上拉，不然数据线没有足够的驱动能力，读取回传的数值就是0xFF这种看似有数据、实则无效的结果。
PIR的输出是TTL电平，可以直接接STM32的GPIO输入，但要注意它的输出高电平是3.3V还是5V。老版本的HC-SR501可能是5V输出，好在STM32F103的GPIO大多数是5V容忍引脚，PB0是FT（Five-volt tolerant）脚，可以直接接。不过为了保险，我一般在PIR的OUT到GPIO之间串一个1kΩ电阻，既有降压防过流的左右，又能在信号抖动时稍微钝化边沿。
蜂鸣器这里一定要单独拿出来讲。有源蜂鸣器内部有振荡源，给个直流电平就会响，听起来方便，但它工作电流往往在20mA以上。STM32的GPIO在推挽模式下勉强能提供20mA左右的电流，但我不建议直接用GPIO去驱动蜂鸣器，因为一上是瞬时冲击大，二是长时间高电平会让芯片发热、引脚电压被拉低。正确做法是加一颗NPN三极管（比如S8050）做开关，GPIO输出高电平，三极管导通，蜂鸣器接在5V和集电极之间，基极串联一个1kΩ电阻做限流。我自己第一次就是偷懒直接驱动蜂鸣器，结果声音发闷，后来用三极管一接，声音马上脆了。
2.3 上电前必须做的几项检查
硬件接完，千万别着急上电。我每次调试新系统都有一个固定的检查清单，顺序不能乱：
- 先用万用表量一遍5V和3.3V有没有短路，特别是USB座的电源正负极，反接是整个系统报废的第一步。
- 对照引脚定义逐根线看一遍，重点检查OLED的SDA和SCL有没有接反，I2C两根线接反后屏不会坏，但就是不亮。
- 检查蜂鸣器模块有没有串联限流电阻，基极电阻是不是1kΩ级别，不要用0Ω直连。
- 检查所有模块的共地。不同模块的VCC可以来自5V也可以来自3.3V，但GND必须都接到主控的GND上，否则信号参考地不一样，GPIO读电压就是乱的。
- 单独给MQ-2通电，开表笔量加热丝两端的电压，正常应该是5V且稳定，不要在模块还没预热完成时就急着灌代码判断烟雾浓度。
我实际做的时候，第4条“共地”出过问题。当时OLED和STM32共用一个5V，但PIR单独接了一个充电宝的5V，结果PIR检测到人时，STM32读到的信号时高时低完全不稳定。后来把两个电源的地线用一根杜邦线连起来，现象立刻正常。这种问题在实验室里不仔细根本发现不了，遇到怪异的随机现象，第一个先查共地。
3. 软件侧实现：状态机、外设驱动与报警逻辑
硬件是骨架，软件才是灵魂。这块我的经验是：不要想着一口气把所有模块都跑通，而是先点亮OLED，再读DHT11，再把PIR读出来，最后才把它们串到一个状态机里。软件分四层，我自己在工程里也是按这个顺序写的：外设配置、驱动函数、业务逻辑、主循环调度。每层测好，再往上一层走。
3.1 软件架构：为什么用状态机而不是一堆if else
大多数新手写完代码是这样的：主循环里先读PIR，再读烟雾，再读DHT11，然后随便几个if嵌套，判断触发就报警。这种写法在功能演示时表面上能用，但一旦你想加“撤防/布防”切换、报警延时、恢复自动复位，嵌套的if就变成意大利面条了。所以我采用状态机，把系统抽象成几个稳定的状态，状态之间的迁移条件明确，代码清晰，调试也方便。
我的状态定义：
- IDLE：空闲态，系统持续读温湿度和烟雾浓度，OLED正常显示，但不响应PIR触发。
- ARMING：布防倒计时状态，按下布防键后延时10秒，方便人离开房间。
- ARMED：警戒状态，此时PIR的检测结果才会参与逻辑，一旦检测到移动就进入报警状态。
- ALARM：报警状态，蜂鸣器响、LED闪、OLED显示报警类型。持续10秒后自动回到撤防状态，或者按下按键手动退出。
- ERROR：传感器异常状态，比如DHT11连续多次读取超时，系统提示用户检查传感器。
状态机的好处是，任何时刻系统都清楚自己“该响应什么、不该响应什么”。比如在ARMED状态下，PIR触发是有效的；在IDLE状态下，主人自己走动不会引发误报。这个逻辑用状态机表达毫无歧义，而用if else写逻辑你很容易写漏状态迁移条件，后面加需求就会头疼。
3.2 CubeMX初始化配置要点
工程初始化我用STM32CubeMX生成，勾选外设后自动生成代码，再把业务代码填到USER区就行。关键配置有以下几处：
- RCC：外部高速时钟HSE选择晶振/陶瓷谐振器，可能我用的是8MHz晶振，PLL配置为倍频9倍，得到72MHz系统主频。别选成内部时钟，否则后面串口波特率和延时都会不准。
- GPIO配置：PB0作为输入模式，可以选择上拉输入，因为PIR输出高电平有效，上拉能让空闲电平稳定；PB1、PB12配置为推挽输出，初始电平设为低；PB13配置为输入，开启内部上拉，读取按键状态。
- ADC1：使能通道0（PA0），采样时间我设为239.5周期最慢档。烟雾传感器的输出变化本来就慢，用慢采样能得到更稳定的数字量，还能降低噪声影响。
- I2C1：标准模式100kHz，PB6-SCL、PB7-SDA。DHT11不需要I2C，它用的是普通GPIO模拟单总线，配置PB10作为输出模式即可。
- 定时器：我用TIM3做1ms周期中断，在回调里做时间计数。这个1ms心跳是整个系统的呼吸节拍，消抖、报警延时、OLED刷新都以它为准。
配置完这些后，生成MDK工程或Makefile工程。使用HAL库但请记住一个原则：不要在中断回调里做耗时操作，中断里只置标志位，在主循环里处理。
3.3 核心驱动代码实现
外设驱动我不逐个贴全量代码，挑三个特别容易写错的模块讲：DHT11读取、MQ-2滤波、PIR消抖。
DHT11单总线读取时序，网上代码很多，但有一半是错的。核心流程是：主机拉低数据线至少18ms，然后释放并延时20-40us，读取从机应答信号；从机先拉低80us表示应答，然后拉高80us准备数据。后面每位数据是50us低电平加上26-28us的高电平表示0，70us的高电平时长表示1。难点在于读取每一位高电平持续的时间。我刚开始用for空循环做延时，发现不同编译优化级别下时间完全不同，非常不靠谱。后来改用DWT（Data Watchpoint and Trigger）做微秒级延时，或者直接用定时器时基，问题就解决了。下面是个简化版本的读取流程：
uint8_t DHT11_ReadByte(void) { uint8_t bit, data = 0; for (int i = 7; i >= 0; i--) { while (HAL_GPIO_ReadPin(DHT11_DATA_PORT, DHT11_DATA_PIN) == GPIO_PIN_RESET); // 等待50us低电平结束 delay_us(30); if (HAL_GPIO_ReadPin(DHT11_DATA_PORT, DHT11_DATA_PIN) == GPIO_PIN_SET) { bit = 1; while (HAL_GPIO_ReadPin(DHT11_DATA_PORT, DHT11_DATA_PIN) == GPIO_PIN_SET); // 等待高电平结束 } else bit = 0; data = (data << 1) | bit; } return data; }这段代码的关键在于while等待状态结束，以及微秒延时30us的准确性。30us的原因在于数据位的低电平只有50us，读的时候如果延时太长，可能错过后面的高电平判断。30us是安全取值。如果你发现读出来永远是0x00或0xFF，十有八九是延时函数不准，换DWT或者查一下SysTick优先级。
MQ-2的模拟量读取就简单多了，ADC采样后，为了稳住数值，我会连续采10次取平均。烟雾浓度和输出电压大致成正比，但没必要追求绝对浓度值，只要看它相对空气中“基线”变化了多少。我自己的做法：系统上电后先连续读20次，取平均值作为基线，保存下来。之后每次读到ADC值，如果比基线高出设定阈值，就判定为烟雾报警。阈值我设置为基线加300左右（12位ADC，0-4096范围），这个值需要根据模拟量输出电压和传感器摆放位置调整。
uint32_t smoke_base = 0; for (int i = 0; i < 20; i++) { smoke_base += Read_ADC_Average(); HAL_Delay(50); } smoke_base /= 20; // 空气基线 // 主循环中 uint32_t smoke_current = Read_ADC_Average(); if (smoke_current > smoke_base + 300) { Set_Alarm(ALARM_SMOKE); }PIR消抖更要用心。PIR输出的是开关量，但它在传感器被触发的前几秒会来回抖动。直接读GPIO就判断报警，经常出现“响一声又停一下再响一声”的现象。我用一个简单的去抖算法：连续读10次，间隔20ms，如果有8次以上是高电平，才认为真正触发。这是安防系统的“确认机制”，宁可晚几百毫秒报警，也不要因为抖动而误报。
3.4 报警状态机的完整逻辑
把上面的外设驱动收拢起来，主循环长这样：
while (1) { heartbeat_ms += Get_Timer_Tick(); // 1ms自增 switch (current_state) { case IDLE: Display_HomePage(temp, humi, smoke_percent); Check_Smoke_And_Temp(); // 烟雾和温度始终检测 if (Button_Pressed()) Start_Arming_Countdown(); break; case ARMING: Display_CountDown(arm_countdown); if (arm_countdown <= 0) current_state = ARMED; if (Button_Pressed()) current_state = IDLE; // 取消布防 break; case ARMED: Display_HomePage(temp, humi, smoke_percent); Check_Smoke_And_Temp(); if (PIR_Trigger_Confirmed()) { Set_Alarm(ALARM_INTRUSION); current_state = ALARM; } break; case ALARM: Alarm_Output_Active(); // 蜂鸣器+LED闪烁 if (Alarm_Timeout_Reached() || Button_Pressed()) { Stop_Alarm(); current_state = IDLE; } break; } }状态切换之前的条件判断，我全都在主循环里做，不会放到中断里。另外每个状态都有超时机制，比如ARMING倒计时10秒，ALARM状态最长持续15秒后自动退出。这个15秒的超时是必须的，否则家里一直没人，蜂鸣器会把周围邻居都吵疯。
报警输出部分，我用TIM3的1ms心跳来翻转LED和蜂鸣器，响200ms停200ms的模式。有源蜂鸣器控制逻辑异常简单，GPIO输出高就响，但要注意虽然你在逻辑上让它“每隔200ms翻转”，真正实现时不要用HAL_Delay阻塞，否则整个系统的其他逻辑包括按键响应都会卡死。延时用非阻塞的方式，记录上次翻转时间，到了就翻，这是嵌入式编程最常见的习惯。
4. 实测记录与常见坑：现场排障实录
这一节是整篇文章含金量最高的部分。我为了写这篇总结，专门把当年调试时记在手机备忘录里的问题翻了出来，挑出最有代表性的几个，整理成速查表。这些问题你在网上不一定搜得到标准答案，但遇到了几乎每个都会让你卡半小时以上。
4.1 高频问题速查
| 现象 | 最常见原因 | 排查步骤 | 处理办法 |
|---|---|---|---|
| OLED屏完全不亮 | 地址配置或接线反了 | 先用I2C扫描程序看设备地址 | 确认地址0x3C还是0x3D，对调SDA/SCL |
| DHT11第一次能读，重启后偶尔读到255 | 上电时序不稳，数据线没有上拉 | 用示波器或逻辑分析仪看时序 | 上拉电阻改为4.7kΩ，读失败时重试5次 |
| 蜂鸣器声音很小或无声 | GPIO直驱电流不够 | 量GPIO输出电压，看有没有被拉低 | 改用三极管驱动，基极串1kΩ电阻 |
| PIR误报频繁 | 灵敏度电位器调得过大 | 拧小灵敏度旋钮，观察触发距离 | 降低灵敏度，避免阳光和热风直吹 |
| MQ-2读数一直很高 | 传感器还没有预热完成 | 查看模块指示灯是否稳定 | 通电预热10-15分钟再校准基线 |
| 按下按钮没反应 | 按键抖动或GPIO内部上拉没开 | 量按键两端电压 | 开启内部上拉，代码做20ms消抖 |
| 报警后无法自动复位 | 状态机没有超时机制 | 看代码是否卡在while里 | 报警状态加自动退出计时 |
这个表我是按“现象→排查→处理”的排障顺序写的，实操的时候不要跳步。遇到问题最忌讳的是直接改代码、改参数，一定要先确认硬件现象和软件现象各占多少比重。我见过有人为了修OLED不亮，把代码里的I2C时序改了三遍，最后发现是电源接触不良——这种现象级的低级错误，排查顺序对了，五分钟就能定位。
4.2 误报问题排查实录
安防系统最怕的不是不报警，而是乱报警。我实验室里把PIR装在桌面上，对着门口，距离大概三米，结果一天能误报七八次。后来逐个排查，发现三个因素叠加：
第一是灵敏度旋钮拧到了最大。HC-SR501的灵敏度调节范围大约是3到7米，我那个距离三米的环境只要把距离调到最小挡的1.5倍就够了。把电位器逆时针拧到约1/3位置，误报立刻少了一半。
第二是模块正对着一扇窗户。白天太阳移动、玻璃反光突然变化，PIR感应到的红外背景会突变，有时候就会误判成“有人移动”。我把传感器稍微转了个角度，让它的探测扇形避开窗户，误报又少了很多。
第三是模块装得太低，导致半个感应范围覆盖到暖风空调的气流。空调一开，热风呈立体扩散状在房间里移动，PIR会把气流边缘的温度变化当成热源移动。后来我把传感器固定到离地1.8米左右的支架上，并且探测方向斜向下，专门扫门口到客厅的中间通道，误报基本归零。
总结下来，PIR误报的排查顺序是：灵敏度是否过大、视角内是否有高频热源移动、供电是否稳定、有没有窗帘或者树叶遮挡。这四个检查做完，能解决90%的现场问题。
4.3 DHT11读取与MQ-2预热问题
DHT11的坑主要在时序和上电。有段时间我发现系统上电后第一次读总是失败，第二次就正常，后来查明白是DHT11需要500ms以上的稳定时间。我在初始化里加了一个延时，等待传感器上电自检完成，再开始读取，问题解决。另外DHT11对读间隔也有要求，两次读取至少要间隔1秒以上，读太频繁不但数据不会更新，还可能让传感器内部逻辑混乱。所以我在主循环里控制读取频率，每秒最多读一次温湿度。
MQ-2方面，新模块一上电，ADC读到的数值会从很低慢慢爬升到一个稳定值，这个过程需要10多分钟。如果你一上电就开始判断“当前值是否超过阈值”，大概率会被初始的异常基线带偏。我给出的方案是上电后不立刻采集，而是先让MQ-2工作，期间OLED上提示“Sensor warming up”，等到180秒后再取基线。这个预热时间可以短一些，但绝不能跳过去直接做判断。还有一点：MQ-2的功耗和发热都不小，探头表面工作温度接近几十度，不要用手直接碰，安装在通风位置就行，装在密闭外壳里测烟雾会不准确，因为气敏元件需要空气流动才能更快响应。
5. 可以扩展的部分：从安防Demo到实用系统
如果你按上面的步骤做完，你已经有一套能够稳定运行的安防系统原型了。但如果只是停在这里，说实话它还只是“课程设计”。要让它更接近真正能用的智能家居设备，还有几个扩展方向。我这里不讲太多，挑三个性价比最高的聊聊。
5.1 远程上报提醒
现场声光报警很响，但人不在家，报警响了也听不到。最直接的扩展是加一个ESP8266模块，让STM32通过串口给它发送状态数据，它再通过家里Wi-Fi转发到公网物联网平台，接着在手机App或微信小程序上收到通知。这里的核心难点不是云平台配置，而是串口通信协议的设计。我建议STM32侧使用简单的帧格式，比如帧头0xAA、数据类型、数据长度、数据体和CRC校验，避免直接把状态数据裸发出去后，在解析的时候出现错位。
供电上要注意给ESP8266单独加一个3.3V稳压模块，并且电源容量留足余量。软件上ESP8266上电后先配置AT指令接入Wi-Fi，然后建立TCP连接，之后周期性上报数据。实测中这个链路很可靠，只要家里路由器不重启，系统跑几天都不掉线。远程通知不是必须的，但加上了之后整个项目的“智能感”立刻提升一个档次。
5.2 低功耗与断电备电
安防设备最怕没电。市电停了，如果设备也跟着断电，那安防就成了摆设。扩展方案可以做两件事：电源端加一个锂电池或者UPS模块，让系统在5V断电时自动切到电池供电；软件端在电池供电模式下，降低采样频率、OLED亮屏改为定时唤醒，把系统平均电流压到几十毫安以内。因为STM32有多种低功耗模式，比如STOP模式加RTC闹钟唤醒，这是真正产品级的思路。普通课程设计一般不强制要求低功耗，但如果你在简历上写上“实现了低功耗待机策略”，这会是面试官比较感兴趣的点。
5.3 数据记录与联动控制
再往上走，就是给系统加SD卡或者Flash芯片，把报警事件和温湿度历史记录下来。别小看这个功能，有了历史数据，你就能画趋势图，判断家里环境有没有突变。联动控制方面，可以再加一个继电器模块控制电磁阀或排风扇。当烟雾浓度升高时，自动切断燃气阀门或者打开窗户排风扇，这是很典型的智能家居联动场景。这部分的难度主要在继电器防触电安全，选光电隔离继电器模块，驱动逻辑其实和驱动蜂鸣器很相似。不过我不建议在实验室环境里真的去接220V设备，模拟一个指示灯展示联动逻辑就够了。
这些扩展如果全部做完，这个项目就不仅仅是一个“基于STM32的智能家居安防系统设计”了，它已经具备了一个小型智能家居控制中枢的雏形。技术栈上也从单片机裸机开发，延伸到了通信协议、低功耗设计、数据存储和多设备联动，含金量完全不一样。
最后再分享一个我实际调试中的小技巧：每当系统行为变得诡异，不要先在代码里猜，先做“最小系统验证”。把OLED以外的模块全部断开，单独跑一个GPIO翻转程序，主循环里让LED闪烁，如果能正常闪，说明主控和核心代码没问题；然后再接回传感器，一个一个加上来，每加一个就观察一小段时间。这样做虽然慢，但能确保每加入一个模块后系统依然稳定。很多人被乱七八糟的现象折磨了一下午，最后发现是电源线虚接，其实都被“想快点看到完整效果”的心态害了。稳扎稳打，才是做嵌入式项目最值钱的经验。
