企业官网建设流程全解析

1. 为什么家庭火灾报警不能凑合：从一次差点误事的经历说起

前阵子帮亲戚家处理了一次厨房冒烟事故，要不是人刚好在房间里，后果不敢想。回头去检查他家的“火灾报警器”，才发现是一个几十块钱的独立式烟雾报警器，电池供电，响起来全家都能听见。听起来没毛病对吧？可问题就出在：报警器装在客厅天花板，厨房开着抽油烟机炒菜，油烟稍微大一点就误报，报了几次之后全家都麻木了，觉得它就是个“炒菜报警器”。等到真的锅烧干冒烟，报警器响的时候，亲戚还以为是又误报，愣是过了两三分钟才反应过来。

这件事让我下定决心，把家里的火灾报警系统彻底重新做一版。标题里说的“智能家庭火灾报警系统”，不是一个简单的烟雾传感器加蜂鸣器，而是多传感器融合、分级预警、本地加远程双重通知的一整套方案。这篇文章完整记录了从需求分析、硬件选型、系统架构、核心算法到焊接调试、实测数据的全过程。资料我已经整理成了可复现的版本，包括完整接线图、代码框架、阈值参数和踩坑记录。不管你是电子爱好者、智能家居玩家，还是想给家里老人装一套靠谱安防设备的动手派，照着这篇都能搭出一套自己的系统。

先说清楚这套系统和市面上成品报警器的本质区别。成品独立式报警器的问题不在于“能不能检测到烟雾”，而在于它的输出只有本地声音，而且几乎不做环境判断。人不在家，它响了也没人知道；人在家但睡熟了，卧室门一关，厨房的报警声未必能吵醒人，尤其是老人。更关键的是单传感器方案在误报和漏报之间几乎没有取舍余地：灵敏度调高，油烟就误报；灵敏度调低，阴燃火灾的早期烟雾又检测不到。智能系统的核心思路是让多个维度互相印证——烟雾浓度要涨，温度要异常上升，火焰特征要出现，至少两个条件同时满足才触发最高级别报警，单靠一个维度最多到预警级别。这样才能做到既不放过真火情，也不被一碗油泼辣子整得全家鸡飞狗跳。

这套系统还有一个很现实的出发点——响应链路。家里着火之后最宝贵的不是检测的那几秒钟，而是告警从传感器到人的那几秒钟。所以设计目标里有一条硬指标：无论家里有没有人、人有没有醒、WiFi通不通，告警都要能到达。这就意味着不能只依赖云端推送，本地声光报警必须兜底，远程通知必须有多一条通道备用。后面我会详细展开这些设计取舍。

2. 系统架构设计：感知层、决策层与通知层各干什么

2.1 总体架构：不搞复杂总线，一台主控加三路传感器

很多人一听到“智能系统”就想着上Home Assistant、上智能音箱联动、搞一堆自动化场景。这当然可以，但作为安防设备，第一原则是可靠，第二原则是简单到不会坏。我把整个系统拆成了三个层次，每一层的职责非常明确：

感知层负责采集环境数据，包括烟雾浓度模拟量、火焰红外信号、环境温度数值三个维度。决策层跑融合判断算法，输出正常的待机、预警、报警三级状态。执行层和通知层负责把状态变成人能感知的告警：板载蜂鸣器和高亮LED负责本地告警，OLED屏显示当前数据和状态，ESP32的WiFi模块负责把告警推送到手机。

不用复杂的RS485总线，也不用传感器并联去中心化组网，因为家庭场景里所有传感器都部署在同一个房间的合理范围内，单点汇聚到主控是最不容易出故障的拓扑。每个传感器用三根线（电源、地、信号）直接连主控，哪怕其中一路传感器坏了，其他两路还能继续采集，主控会通过通道自检发现异常并在OLED上提示。

2.2 为什么选ESP32而不是Arduino Uno或STM32

主控的选择直接影响整套系统的开发难度和后期扩展能力。对比下来我最终选了ESP32，核心原因有三个：

第一，自带的WiFi和BLE直接解决了远程通知问题。如果选Arduino Uno，要么外挂ESP8266串口透传模块，要么接有线网卡，结构上就多了一层不稳定因素。ESP32的双核处理器对于同时跑传感器轮询、算法判断和WiFi通信来说绰绰有余，不用担心网络重连时把检测逻辑卡死。

第二，ADC通道数量和输入范围够用。MQ-2烟雾传感器输出的是模拟电压，火焰传感器可以输出数字开关量也可以输出模拟量，温度传感器走单总线协议。ESP32有好几个ADC通道，而且12位分辨率比Uno的10位更能分辨烟雾浓度的微小变化。这一点在调阈值的时候特别重要：同一个传感器，分辨率高一点，软件曲线就从“阶梯状”变成“平滑曲线”，阈值的可调空间就大。

第三，性价比和扩展性。一块开发板十几二十块，板载USB转串口，烧录调试方便，GPIO足够多，以后想加空气质量传感器、加继电器控制排风扇，不用换主控。另外ESP32支持OTA在线升级，系统装到天花板或吊顶里之后，改了算法逻辑不用拆机器，这个体验对后期迭代太关键了。

当然，ESP32也不是没有坑，最大的问题是ADC的电压测量范围默认是0到3.3V，而不是0到5V，后面在硬件接线部分我会专门讲怎么处理。

2.3 传感器选型：每一路信号解决什么检测盲区

传感器是整个系统的眼睛，选型逻辑围绕一个核心问题：不同火灾阶段的特征信号到底是什么？

先说烟雾检测。家用场景中我选了MQ-2气敏传感器，它对烟雾、液化气、丙烷等多种可燃气体都有响应，灵敏度可以通过负载电阻调节。它的核心元件是二氧化锡气敏层，加热到200到300摄氏度时表面吸附氧分子，接触还原性气体（比如烟雾里的不完全燃烧产物）后电阻下降，输出电压随之上升。优点是对烟雾敏感度高、便宜、电路简单，缺点是上电需要预热、长期在油烟环境下会污染老化、对多种气体都响应所以没法区分气种。

很多人觉得烟雾检测到就够了，但油锅起火和电气火灾的早期阶段有一个共同特征——局部温度快速上升。所以我加了DS18B20数字温度传感器，它走单总线，不需要额外的ADC通道，精度正负0.5摄氏度，可以测到125摄氏度，足够覆盖家庭火灾的升温区间。温度这个维度最大的价值是提供“变化速率”参考，而不仅仅是一个绝对值。

第三路是火焰传感器。模块上的光电二极管对760纳米到1100纳米波段的红外光敏感，而火焰燃烧时这个波段有强烈的特征辐射。它加了滤光片和比较器，检测到火焰红外信号时输出低电平。这一路在明火阶段响应极快，毫秒级到百毫秒级，比烟雾到达传感器顶部再扩散过来快太多了。但它也有致命的干扰源——太阳光、白炽灯、遥控器的红外光，所以不能单独信它，后面算法部分会讲怎么用“波动特征”来过滤干扰。

2.4 硬件清单与成本明细

整套系统物料成本大约在100到130元，相比市面上真正带远程通知的智能报警器动辄三四百的价格，性价比很突出，而且模块化设计让后续维修替换成本极低。

注意：18650电池方案并不是要系统长期靠电池跑，而是在家庭断电或者电源适配器故障时，维持传感器采集和本地声光报警至少运行4小时。主控检测到USB供电断开后会自动切换到电池回路，并在OLED上提示当前处于备用电源模式。

3. 硬件搭建实录：接线、电源和三个容易踩的坑

3.1 接线图设计与电源分配

这部分直接给接线方案，方便照着做。ESP32的3.3V输出电流能力有限，驱动OLED和传感器模块建议统一从5V取电，信号线按各模块要求接入对应引脚。ADS1115不用加，直接占ESP32的ADC引脚就行。

具体分配如下：

• MQ-2模块的VCC接5V，GND接GND，模拟信号输出AO接GPIO34（ADC1通道6）
• DS18B20的红线接3.3V，黑线接GND，黄线（数据）接GPIO4，数据线与3.3V之间接一个4.7kΩ上拉电阻
• 火焰传感器模块的VCC接3.3V或5V均可，GND接GND，数字输出DO接GPIO35，同时把比较器输出也接到GPIO36做模拟读取，便于后续软件分析信号波形
• 蜂鸣器正极接GPIO25，负极接GND，注意有源蜂鸣器要选低电平触发或者加NPN三极管驱动，直接接GPIO可能拉不动
• OLED的SDA接GPIO21，SCL接GPIO22，VCC接3.3V，GND接GND

供电部分我用了共地设计，所有模块的GND全部接到同一个电源负极端子，避免不同地电位导致的信号漂移。电源输入是USB 5V，经过一个防反接二极管后分成两路：一路直接给ESP32的5V引脚供电，另一路经过充电保护板给18650电池充电；USB断电时，电池通过一个P沟道MOSFET自动切换输出给整个系统供5V。

3.2 MQ-2预热漂移：上电前30分钟的读数根本不能用

MQ-2的原理决定了它有一个加热过程，气敏层需要达到工作温度才开始稳定地吸附和脱附气体分子。实际测试中我发现，冷启动后前5分钟的读数波动极其剧烈，有时候在洁净空气中输出的电压能从0.8V一路飘到1.6V然后又掉回来，这种非火灾引起的信号变化如果直接进判断逻辑，必然触发严重的误报。

我的处理方式是两级防护。硬件层面，MQ-2模块的负载电阻先从默认的1kΩ换成4.7kΩ，这样在洁净空气中输出电压更低，留给烟雾浓度变化的动态范围更大。软件层面，主控上电后设置一个预热计时器，前60秒内温度、烟雾数据只采集不判断，OLED显示倒计时；直到加热进入平台期后，系统才切入正常检测模式。同时在算法里引入“开机基线自校准”，取预热最后10秒的烟雾平均值作为当前环境的洁净基线，后续所有判断都用相对基线偏移量而不是绝对电压值。这个细节直接消灭了冷启动误报。

3.3 火焰传感器的干扰源：阳光、白炽灯和空调红外遥控

火焰传感器在室内环境里是最容易“抽风”的一路信号。阳光透过窗户照到光电二极管上，输出直接拉低报警；空调遥控器对着传感器按一下，也能触发一个短脉冲；甚至节能灯在启动瞬间的频闪都可能引起误判。

解决分两层。第一层是硬件物理隔离：传感器加了一个遮光罩，只留一个约60度的扇形探测窗口，安装在灶台上方侧面，窗口朝向炉灶区域而不是窗户或客厅。第二层是软件特征识别：真正火焰的红外信号不是恒定的，而是以几十赫兹的频率波动（火焰闪烁的物理特征），所以我不用单次的低电平跳变做判断依据，而是连续采样100个点，统计其中的低电平脉冲次数和间隔规律，只有同时满足“脉冲次数超过设定值”和“最大低电平持续时长落在0.1到2秒区间”才判定为火焰特征。静态的红外干扰源（比如阳光）不会产生这种规律的脉冲序列，直接被过滤掉。

3.4 DS18B20的布点位置与单总线稳定性

温度传感器不能跟烟雾传感器挤在一起，因为烟雾传感器本身带一个加热器，会局部提高周围温度。我把DS18B20用一根1米长的三芯屏蔽线引出，固定在厨房吊顶的边缘，远离灶台正上方，同时避开了冰箱散热口和暖气片。这样做是为了让测到的温度尽量代表“房间整体环境温度”，而不是局部热源。

单总线协议有个常见问题：线长超过1米或并联多个设备时，需要降低上拉电阻阻值。我只用了一个DS18B20，线长一米，实验发现2.2kΩ上拉比标准4.7kΩ的波形更稳定，读取出错的次数显著减少。读取频率也不要太频繁，传感器转换一次需要750毫秒，所以我设置每2秒读一次，每次读到后做一次简单的CRC校验，异常值直接丢弃。

4. 融合判断算法：怎么把三路信号变成可靠的火灾判断

4.1 单传感器方案的死穴：误报和漏报只能二选一

所有做安防报警的人都绕不开一个矛盾——**灵敏度调高，误报率上升；灵敏度调低，漏报率上升。**独立式烟雾报警器把灵敏度固定在一档，应对家庭这种油烟、水汽、粉尘混杂的环境，基本就是在两瓶毒药里选一瓶。

我一开始也试过“三路信号各自设阈值，任一触发就报警”的简单方案，结果一个下午误报了四次：一次是炒菜油烟，一次是阳光反射，一次是电水壶水蒸气触发了烟雾传感器，还有一次是路由器重启导致WiFi断连，代码把断连当成异常状态报了警。当时我就意识到，多传感器不是“叠加报警条件”，而是“建立互相印证的证据链”。

新的判断逻辑改成这样：任何一个传感器触发阈值时，系统不直接报警，而是进入“疑似火灾”状态，同时把另外两路传感器的数据拉入高频采集模式。只有在设定的时间窗口内出现第二个维度的证据，才升级到确认报警。单维度信号持续超过更长的延时，也只到预警级别，呼叫用户自查而不做最高级动作。

4.2 加权评分：烟雾、温升和火焰特征怎么合成

具体实现时我用了一个加权评分模型。每隔一秒计算一次综合火灾得分 S，公式是：

S = 烟雾贡献值 Ws × 烟雾置信度 Cs + 升温贡献值 Wt × 升温置信度 Ct + 火焰贡献值 Wf × 火焰置信度 Cf

这三个置信度不是简单把传感器原始值归一化，而是根据各自的特征量算出来的：

• 烟雾置信度 Cs：取烟雾值相对基线的偏移量，除以标定的满量程偏移，饱和时为1。如果偏移量在60秒内缓慢上升，置信度打折为80%，因为缓慢漂移更可能是环境潮气或传感器老化；如果是快速攀升（20秒内偏移量翻了3倍），置信度全额计。
• 升温置信度 Ct：不光看温度的绝对值，重点看温升速率，单位是摄氏度每分钟。速率超过2℃/min且持续30秒，置信度按线性上升到0.8以上；速率低于1℃/min时置信度限制在0.3以下，防止夏天阳光晒屋顶导致的缓慢升温误判。
• 火焰置信度 Cf：根据100个采样点中红外脉冲的规律性打分，规律性强给高分，恒定高电平或完全无脉冲给零分。

三个权重我标定下来是Ws=0.5，Wt=0.3，Wf=0.2。烟雾和温度是火灾早期和中期的可靠指标，权重高；火焰信号响应快但干扰也多，权重低。S超过0.6判定预警，超过0.8判定确认报警。

4.3 状态机：待机、预警、报警和复位之间怎么流转

状态机是整个软件逻辑的骨架。我定义了四个状态，状态之间的转移条件用计时器而不是瞬时的判定，避免毛刺信号导致状态乱跳：

• 待机状态：系统正常运行，所有传感器在低频轮询，综合得分S保持低于0.6。任何信号触发阈值但分数不够，都只是刷新OLED上的提示，不做声光动作。
• 预警状态：S超过0.6，或者单维度信号超过阈值且持续15秒。进入预警后，OLED显示预警原因和当前各路数据，蜂鸣器每隔10秒发一次短促“滴”声（音量较小），同时通过MQTT推一条“疑似烟雾/升温”消息到手机。这个状态设计成一个软性提醒，用户看到消息回家检查一下即可，避免误报制造“狼来了”效应。
• 确认报警状态：S超过0.8并连续确认6秒。此时蜂鸣器发出连续高频急促报警音，LED高频闪烁，OLED全屏显示“FIRE ALARM”，同时立即推送最高级别通知。如果10秒内没有收到任何复位操作，再做第二次补推。
• 复位状态：报警或预警状态都支持按键复位和远程复位。但为了防止熊孩子或者误触把报警静音，我加了一个规则——如果复位时三路信号仍然全部超过阈值，不允许复位，必须等传感器数值回落到基线的80%以下才可以。这个逻辑在真火情但火被及时扑灭的场景下也很重要，烟雾残留还会让传感器读数偏高，强行复位会导致二次报警，所以复位条件里加了一个2分钟冷却计时。

4.4 环境自适应校准：每个家庭的气味都不一样

同一套电路板，在A家庭（天天爆炒，厨房油烟重）和在B家庭（主要吃水煮菜，几乎无油烟），传感器基线和动态范围完全不一样。如果阈值写死，A家庭会因为基线被污染而快速误报，B家庭则因为基线太干净而阈值偏严、真正的阴燃火灾反而不敏感。

我的做法是维护一个滑动窗口基线。系统每分钟记录一次温度、烟雾、火焰特征的均值，放到一个队列里，队列长度保持240分钟的历史。正常状态下，基线取这个队列的第10百分位数（剔除高峰值干扰）。只有状态机处于待机状态时才允许更新基线，一旦进入预警或报警，基线冻结，防止把火灾信号学进基线里。

这套自适应机制实测非常有效。系统从新装修的毛坯房环境移到正常做饭的厨房后，大约经过一天半的时间，基线自动调整到新环境，不需要任何人工配置。

5. 软件实现：代码结构、远程通知和兜底逻辑

5.1 程序主循环与任务划分

ESP32是双核，我把代码分成了两个核心任务。核心0跑传感器数据采集和状态机算法，这是最高优先级任务，每500毫秒完成一轮循环；核心1跑WiFi管理、MQTT通信、OLED刷新，这些操作有网络阻塞风险，放到另一个核心避免卡住检测。

主循环流程可以概括为：采集三路信号，做滤波和有效性校验，更新状态机的输入，计算综合得分S，根据当前状态执行对应动作，最后把关键数据推入环形缓冲区供通信任务消费。我在两个任务之间用了一个队列传递消息，而不是共享全局变量。比如检测任务发一条“ALARM: score=0.87, smoke=2.1v, temp_rate=3.5C/min”的消息，通信任务收到后才组装推送。好处是通信任务阻塞时，检测任务完全不受影响，报警逻辑永远在跑。

5.2 远程通知：MQTT为主通道，HTTP备用

远程通知我选了MQTT。家里局域网内跑一个开源Broker，ESP32作为客户端发布主题到sensor/fire_alarm，手机端装MQTT仪表盘类App订阅主题，同时可以用规则引擎在确认报警时把消息转发到手机系统通知。这种方式的好处是全链路都在自己控制内，不依赖某个厂商的云服务，不会被平台限制。

断网兜底是必须处理的场景。如果WiFi断了或者MQTT Broker挂了，系统自动切换到一个备用的HTTP模板接口——直接用HTTP POST把报警信息发给一个自建的轻量通知服务，再由这个服务触发手机推送。为了不让这条备用链路被滥用，接口地址硬编码在固件里，并且加了一个简单的设备ID鉴权字段。实际测试里，这条链路在WiFi恢复后的第一次连接尝试就能把积压状态补发出去。

5.3 本地声光告警设计：声音要有等级区分

本地告警很容易被忽略，所以声音设计成两种完全不同节奏的模式。预警是“短促滴声+屏幕提示”，音量较低，持续不超过30秒自动恢复静默；确认报警是急促的连续蜂鸣（1秒10次频率），音量用程序拉到最大PWM占空比。LED完全不同步：预警用低频呼吸灯，确认报警用8Hz高频闪烁，颜色用红色LED而不是绿色或蓝色，因为人眼在低照明条件下对红色最敏感。

还有一个很容易被忽略的设计——夜间自动降低OLED亮度。如果系统安在卧室或客厅，深夜整块屏幕亮着会影响睡眠。我在代码里按时间段切换亮度：22点到早上6点之间OLED亮度降到最小的20%，任何时候报警触发时恢复最大亮度。

5.4 状态记录与事件回放

系统每一条事件（传感器读数的阈值跨越、状态切换、报警推送、复位操作）都会带时间戳写到内置的Flash存储区。我用的是一个轻量的环形日志，最多保存500条记录。调试的时候这个功能帮了大忙——回放日志可以清楚看到“第12分钟烟雾值缓慢爬升，第14分钟温度速率达到3.5℃/min，第14分30秒状态从预警转为确认报警”这样的完整链路，而不是只看到一个孤零零的报警发生记录。

6. 实测数据与调试过程：误报怎么压下去的，漏报怎么防住的

6.1 油烟干扰测试：连续炒菜一小时

安装完成后第一轮实测用的就是最严格的场景——连续做三顿饭，每顿都是爆炒、煎炸，观察系统会不会误报。我把系统放在厨房和客厅之间的隔断处，距离灶台约3米，与传统独立式烟雾报警器并排放置对照。

结果很有说服力。传统报警器在第一顿爆炒时约在第7分钟报警，第二顿煎鱼时再次报警；我的系统在同样的油烟环境下，综合火灾得分最高到0.52，始终没有突破0.6的预警门槛。原因不难理解：油烟确实让烟雾传感器读数显著抬升，但厨房环境温度上升速率很平缓（油烟升温大约0.5℃/min），火焰信号也没有规律脉冲，加权算下来分数不够。这说明融合判断确实压住了油烟误报，而不是单纯调低了灵敏度。

但是预警一次也没有触发吗？我做了另一个测试——把锅烧干冒浓烟但不起火，这时烟雾读数快速攀升，得分在40秒内超过了0.6，系统发出预警推送。虽然按设计没进入最高级报警，但提示音和手机通知已经足够让用户去灶台看一看了。这个分级效果深得我心：轻度干扰不吵人，真正前兆能捞到预警线。

6.2 明火测试：蜡烛、酒精炉、纸张燃烧

明火测试更看重响应速度。我在安全环境下依次测试了蜡烛火源、小型酒精炉、纸张燃烧三种场景，传感器和火源的距离控制在1米内。火焰信号一路的响应时间是三者中最快的——蜡烛点火后0.4秒内识别出脉冲特征；酒精炉因为火焰更稳定，红外波动幅度更大，特征更明显；纸张燃烧时烟和火同时出现，综合分数在3秒内突破0.8，系统进入确认报警状态。

但这轮测试也暴露了一个问题：火焰传感器在小火苗（比如蜡烛）距离超过2米时几乎收不到有效信号，红外辐射随距离平方衰减，太弱了。家庭场景里不可能保证火源都离传感器很近。所以最终部署时，我在厨房灶台上方和客厅窗帘附近各放了一个火焰传感器，两个传感器信号通过不同GPIO接入主控，任一通道检出火焰特征即参与计分，把有效覆盖范围从扇形的一侧扩展到整个公共区域。

6.3 调试过程遇到最头疼的三个问题

第一个是烟雾传感器在油炸食物时基线反复漂移。一开始代码的基线更新队列是永续更新的，结果连续几天油炸后基线被拉到很高，导致真实火灾烟雾值对比基线反而“看起来不严重”，得分偏低。后来我加了“预警/报警期间冻结基线更新”的规则，并在每天凌晨用历史数据的最低5%分位数作为慢速基线校准，问题才消除。

第二个是MQTT消息偶尔重复推送。原因是通信任务里设置了QoS 1，Broker在未确认时重发，客户端处理时没有做去重。改成QoS 0加本地时间戳判断后，同一条报警消息最多只推一次。

第三个问题是OLED在系统启动时偶尔花屏。排查发现是I2C总线上拉电阻和DS18B20的上拉电阻共用了一个电源轨，启动瞬间多个设备同时拉电流导致电平毛刺。后面给OLED单独加了2.2kΩ上拉，并且把I2C时钟频率从默认的400kHz降到100kHz，花屏现象彻底消失。

6.4 连续运行稳定性观察

完成调试后系统连续运行了三个月。统计结果如下：这期间确认报警0次（且没有虚警，这个用户预期是对的），预警共触发5次，其中3次是炒菜油烟短暂超标，2次是冬季开窗冷空气导致温度速率计算抖动。这五次预警全部通过手机推送到达，没有一次遗漏。

功耗方面，整机待机功耗约180mA@5V，也就是0.9W左右；报警模式下蜂鸣器和OLED全开，功耗上升到260mA。18650电池（容量按2000mAh算）在满电情况下，理论备用时间超过11小时，实测断电运行8小时后还有26%余量。这个兜底余量足以覆盖大部分停电场景和电源故障场景。

7. 落地部署：安装位置、外壳处理和日常维护建议

7.1 传感器安装位置选择的几个原则

装好之后不是随便往哪儿一放就完事。烟雾传感器要避开通风口、空调直吹出风口和门窗缝隙，因为这些位置气流会把烟雾稀释或直接带走，导致响应变慢。我最终把它固定在厨房和客厅之间的梁下墙面上，离天花板约30厘米，这个高度既能提前捕获上升的烟雾，又能避开顶部积灰。火焰传感器则面向两处高风险区域：灶台和客厅电视柜附近，这两个区域是家庭火灾最主要的起火点。温度传感器放在相对中心和远离电器散热的位置，用来代表整个家庭环境的基准温度。

7.2 外壳与散热处理

所有的模块都装进了一个透明的工程塑料外壳，正面给OLED留了开窗，底部开了散热孔和传感器进气栅格。注意不要让外壳完全密封——MQ-2需要空气对流才能感知烟雾，密封外壳会让它变成聋子耳朵。我把主控和电源模块放在外壳的一侧，传感器模块放在另一侧，并用隔板隔开，防止ESP32的发热影响温度传感器读数。

火焰传感器的窗口朝外露出，在外壳上做了一小段遮阳檐，挡住上方直射光。这个遮阳檐看起来不起眼，实际上对抑制中午阳光误报起了决定性作用。

7.3 周期性维护与寿命提醒

家用火灾报警系统的最大敌人其实是时间——传感器会老化，灰尘会堆积，电池会衰减。我在系统里固化了一个维护提醒功能：从首次上电开始计时，每满90天，OLED会提示“注意：建议清洁传感器防尘网并重新校准基线”，时间到了推送一条维护消息到手机。这个周期不是拍脑袋定的，参照了MQ-2气敏元件在家庭环境下的典型污染速度，太频繁变成骚扰，太久则传感器性能可能已经劣化。

实际使用半年后我拆开检查，发现防尘网上的确有明显的油烟附着物，用软毛刷加无水酒精清洁后，传感器基线值恢复到了初装时的90%左右。这个经验提醒我，后期的持续可用性比一次性搭出来更难，维护提醒必须做进产品逻辑里。

8. 从这套项目里总结出的几条可复用经验

最后聊点这套系统之外的东西。做完这个项目，我最大的感受是安防类设备的设计哲学和普通智能家居玩具有本质区别。智能灯泡断电重启后变白灯，最多麻烦一下；火灾报警器却不能有“未初始化”“依赖云端”“需要用户手动复位”这种状态。所有可能影响可靠性的环节都要在代码层面有兜底，所有告警路径都要有第二条备用通道。

具体来说，有三条经验可以迁移到其他家庭安防项目上：

一是状态机比阈值堆砌可靠得多。直接拿连续传感器数值去比阈值，是在用瞬时值判断一个过程性的危险。给系统引入状态和持续时间之后，不仅抗干扰能力大幅提升，人机交互也自然得多——用户看到的是“系统正在预警，原因是温度异常”，而不是一个冷冰冰的报警图标。

二是远程通知必须有多通道冗余。WiFi、MQTT、云服务，任意一环都可能出问题。这套系统里MQTT推送挂了还有HTTP备用，备用也挂了还有本地声光报警，本地报警也没人听到那就是命数问题，但至少把能自动兜底的环节都兜住了。

三是调试阶段一定要建立事件日志和回放能力。没有日志的时候，误报排查纯粹靠脑补；有了时间线日志之后，几乎每个问题都能在十分钟内定位到具体触发路径。这套日志机制用的虽然是ESP32的小Flash，但设计思想完全可以直接迁移到更大型的物联网项目里。

如果你也想照着复刻，建议从第2节的硬件清单开始，先不做远程通知，把本地三路采集、融合算法和状态机跑通，再去接MQTT和备用推送。一步一步来，这套系统的难点不在焊接或者抄代码，而在理解每一个判断条件背后的取舍逻辑。把这些逻辑理顺了，你就不只是会搭一套报警器，而是具备了设计可靠物联网设备的底层思维。