前阵子有朋友跟我聊，说想做一个能监测室内烟雾、粉尘和噪音的小设备，数据能传到手机上看，还要能报警。我第一反应就是：别想复杂了，STM32 + 几个传感器 + WiFi模块 + 云平台，这套组合就是最经典的方案。真正做完你会发现，难点不在“能不能测”，而在于“测出来的数到底可不可信”“数据能不能稳定送到云端”。这篇文章把我从硬件选型、接线、STM32采集代码、ESP8266上云到云平台告警的完整过程整理出来，顺便把我在调试中踩过的三个大坑也一起写了，给想复刻这个项目的人一条能直接走通的路。
整个项目做的事情很简单：用STM32采集三路模拟传感器信号，软件滤波和换算之后，通过ESP8266 WiFi模块，把打包好的JSON数据定时上报到云平台，然后在云平台上看到实时曲线、历史数据和告警通知。适合正在做物联网课设、嵌入式入门项目、智能家居DIY，或者想快速验证环境监测产品原型的朋友参考。
1. 先定整体架构：MCU采集 + WiFi透传 + 云平台这套组合怎么搭
很多新手一上来就想用Linux开发板加Python，觉得生态好、写起来快。真到做环境监测这种设备端项目，你会发现MCU才是主流选择。不是Linux板不能用，而是场景不匹配。
1.1 为什么采集端用STM32而不是Linux开发板
环境监测设备通常需要7x24小时通电运行，采集频率不高，但要求稳定、功耗低、成本可控。
拿STM32F103C8T6这种最普通的MCU来说，整板工作电流也就几十毫安级别，而Linux单板随便跑个系统就是几百毫安起。工业现场、配电箱、壁挂设备里，功耗就是硬指标。另外MCU上电几百毫秒就能进主循环，Linux板光系统启动就要几十秒，中途断电重启一次，数据断档就是一大段。
还有成本。STM32F103C8T6核心板市场上十多元就能搞定，加上传感器和外设，整套硬件成本压到六七十元毫无压力。Linux板动辄一两百元起，批量部署的时候差距非常明显。
当然，如果你后续要做摄像头图像识别、跑神经网络推理这种重计算任务，那Linux板是合理的。但纯环境数据采集，MCU方案是更务实的选择。STM32资源也够：12位ADC采集模拟传感器，多路UART和ESP8266通信，I2C接OLED显示屏，GPIO控制继电器，这个项目恰好把F103的常用外设都用上了。
1.2 整条数据链路拆解与模块划分
这套系统的数据流向，我习惯按四个环节拆开看：
- 传感层：烟雾传感器、粉尘传感器、噪音传感器分别输出模拟电压。烟雾和粉尘输出的是随浓度缓慢变化的直流电压；噪音模块输出的是一路交流波形，处理方式不同，后面会细说。
- 采集层：STM32的ADC把三路模拟信号转成数字量，经过软件滤波、数据换算，得到电压值、浓度估算值和分贝数值。
- 传输层：STM32通过串口给ESP8266下发AT指令，ESP8266连接WiFi、建立TCP连接，把JSON数据POST到云平台接口。
- 平台层：云平台上创建设备、设置数据解析规则，就能看到实时数据和曲线，再配好告警规则，超阈值就推送通知。
这四个环节是串联的，哪个环节出了问题，整条链路就断了。所以调试的时候一定分模块验证：先确认传感器输出有反应，再确认ADC读数在跳，再确认串口能收到数据，最后看云平台是否收到。不要一上来就盯着某一端猜，这是我做了几个物联网项目之后最深刻的体会。
1.3 硬件清单与成本估算
我在这个项目里用的硬件清单如下，都是很容易买到的通用型号：
| 模块 | 型号/类型 | 作用 | 说明 |
|---|---|---|---|
| 主控板 | STM32F103C8T6最小系统板 | 采集、逻辑处理 | 板载AMS1117-3.3稳压，IO引出齐全 |
| WiFi模块 | ESP-01S | 串口转WiFi | AT指令固件，成本低、资料多 |
| 烟雾传感器 | MQ-2模块 | 检测烟雾/可燃气体 | 模拟量输出，带比较器、电位器 |
| 粉尘传感器 | GP2Y1010AU0F模块 | 检测粉尘浓度 | 需要MCU提供LED脉冲驱动 |
| 噪音传感器 | 驻极体麦克风放大模块（MAX4466/MAX9814类） | 采集环境声压 | 输出交流波形，增益可调 |
| 显示（可选） | OLED 0.96寸 I2C | 本地实时显示 | 方便现场调试 |
这套硬件总成本大约在60到80元之间，具体取决于模块的做工和运费。如果你手里已经有STM32核心板，那后面几个传感器模块加起来也就四五十元。预算很亲民。
2. 烟雾、粉尘、噪音三路传感器的选型与接线细节
传感器是整个系统的“眼睛”。我用过几套不同方案的传感器，最后定下来的这三款，是在性能、成本、接线难度三者之间权衡后的结果。
2.1 三路传感器的选型思路与参数对照
先说烟雾传感器。MQ-2能检测液化气、丁烷、丙烷、烟雾等多种可燃气体，响应速度快，输出是模拟电压，非常适合做定性告警和粗略的浓度指示。它的核心是一个加热丝和氧化锡气敏材料，气体浓度升高时,材料电导率变化，模块输出电压跟着变化。缺点是功耗相对大，因为要保持加热温度。
粉尘传感器我选了GP2Y1010AU0F方案的模块。它内部有一个红外LED和一个光电晶体管，通过检测空气中的颗粒物反射光来判断粉尘浓度。这个芯片本身对驱动时序有严格要求：LED必须以10ms周期、0.32ms脉宽的方式脉冲点亮，MCU要在LED亮起后的特定窗口内采样输出电压。很多模块已经把外围电路做好了，你只需要接一个IO口来控制LED引脚。
噪音传感器用的是驻极体麦克风放大模块，这类模块以MAX4466、MAX9814为代表。它们的输出是跟随声音波动的交流电压信号，幅度通常在几十到几百毫伏量级。通过计算这个交流信号的RMS电压，可以换算成一个相对的分贝值。
| 传感器 | 输出信号 | 供电 | ADC处理方式 | 主要坑点 |
|---|---|---|---|---|
| MQ-2烟雾 | 0~VCC 模拟直流 | 5V（加热） | 直接采样电压，做阈值告警 | 预热漂移、输出可能超3.3V |
| GP2Y1010粉尘 | 0.9V~约3.6V 直流 | 5V | LED脉冲驱动后采样 | 时序不对读数恒为0或偏高 |
| MAX4466噪音 | 交流波形 | 3.3~5V | 采样后软件算RMS | 增益太大会削波失真 |
2.2 接线引脚与供电设计（这里藏着多数翻车点）
接线前先说一个最容易踩的坑：STM32的ADC输入范围是0到3.3V，而MQ-2模块如果按5V供电，它的模拟输出范围理论上可以到接近VCC，直接接PA0可能超量程。GP2Y1010的输出最大也可能超过3.3V。不能想当然地直连。
我采用的接线方案如下：
| STM32引脚 | 连接对象 | 说明 |
|---|---|---|
| PA0（ADC1_IN0） | MQ-2模块AO，经分压电阻 | 5V供电时用10kΩ+5.1kΩ分压，或者改给模块采样部分供3.3V |
| PA1（ADC1_IN1） | GP2Y1010模块Vout | 最好也做分压限幅 |
| PA2（ADC1_IN2） | MAX4466模块OUT | 幅度小，直连一般没问题 |
| PB0 | GP2Y1010模块LED驱动引脚 | 由MCU输出10ms周期方波脉冲 |
| PA9/PA10（USART1） | ESP8266 RX/TX | 接ESP8266前确认电平匹配 |
| PA2/PA3（USART2） | 调试串转USB | 打印日志，强烈建议保留 |
供电方面，我把5V和3.3V分开规划。STM32核心板通过USB或外部5V供电，板载稳压到3.3V。ESP8266对供电最挑剔，WiFi发射瞬间电流能达到300mA，如果和STM32共用一个3.3V LDO，电压容易被拉低导致模块重启。我的做法是：给ESP8266单独用一个AMS1117-3.3稳压模块供电，并在ESP8266的VCC和GND之间并一个大电容，比如470uF电解电容，实测能显著减少重启问题。
GP2Y1010的LED引脚驱动也要注意电流能力，STM32 GPIO直接推LED是没问题的，但如果模块说明里要求LED驱动波形，就需要用GPIO输出脉冲，别图省事把LED引脚直接接高电平。
2.3 模拟信号进ADC前的电平处理
模拟信号进ADC之前，我做了两个处理：
第一是限幅。对MQ-2和GP2Y1010，如果模块按5V供电，输出超过3.3V的概率存在，稳妥的做法是在ADC引脚前加电阻分压。MQ-2我串了一个10kΩ电阻到PA0，再从PA0对地接一个5.1kΩ电阻，这样即使模块输出5V，到PA0也只有约1.7V，始终在安全范围内。代价是分辨率降低，但对烟雾告警场景完全够用。
第二是滤波。每个模块输出脚和GND之间并一个100nF电容，滤掉高频耦合噪声。这个电容离STM32引脚越近越好，最好直接焊接在杜邦线末端或PCB上靠近MCU的位置。如果你用面包板飞线，走线太长又没电容，ADC读数会明显抖动。
电源侧同样要处理：传感器的模拟地线和STM32的数字地建议单点汇接，不要形成地环路。三路传感器供电脚各自并一个10uF+100nF电容组合，能显著改善数据稳定性。
3. STM32采集代码：ADC配置、数值换算与软件滤波
传感器接好了，下一步是让STM32把这些模拟信号变成“稳定、可解释”的数据。这一部分也是技术含量最集中的地方。
3.1 ADC多通道+DMA的初始化配置
STM32F103的ADC有12位分辨率，3路传感器刚好对应三个通道。我建议用ADC扫描模式加DMA搬运，让三路数据在硬件上自动连续采集，CPU只管从数组里取数据，省心而且数据一致性更好。
核心初始化代码如下：
/* 使用ADC1，扫描模式，3个通道，软件触发 */ ADC_ChannelConfTypeDef sConfig = {0}; hadc1.Instance = ADC1; hadc1.Init.ScanConvMode = ADC_SCAN_ENABLE; // 扫描模式 hadc1.Init.ContinuousConvMode = DISABLE; // 单次转换，由软件或定时器触发 hadc1.Init.DiscontinuousConvMode = DISABLE; hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START; // 软件触发，简单可控 hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT; hadc1.Init.NbrOfConversion = 3; // 3个通道 HAL_ADC_Init(&hadc1); /* 通道0：PA0，烟雾 */ sConfig.Channel = ADC_CHANNEL_0; sConfig.Rank = 1; sConfig.SamplingTime = ADC_SAMPLETIME_239CYCLES_5; HAL_ADC_ConfigChannel(&hadc1, &sConfig); /* 通道1：PA1，粉尘 */ sConfig.Channel = ADC_CHANNEL_1; sConfig.Rank = 2; HAL_ADC_ConfigChannel(&hadc1, &sConfig); /* 通道2：PA2，噪音 */ sConfig.Channel = ADC_CHANNEL_2; sConfig.Rank = 3; HAL_ADC_ConfigChannel(&hadc1, &sConfig); /* 定义DMA缓存 */ uint32_t adc_buf[3]; /* 触发一次采集：为下一次采集做准备时需要重新调用 */ void Adc_Sample(void) { HAL_ADC_Start_DMA(&hadc1, (uint32_t *)adc_buf, 3); } /* 转换完成后，在回调里取数据 */ void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc) { static uint8_t data_ready = 0; if (hadc->Instance == ADC1) { /* adc_buf[0] = 烟雾通道原始值 */ /* adc_buf[1] = 粉尘通道原始值 */ /* adc_buf[2] = 噪音通道原始值 */ data_ready = 1; } }采样时间我特意选了最长的239.5个周期。传感器模块的输出阻抗通常不低，如果采样时间太短，内部采样电容来不及充满，读出的值会偏低且不稳定。长采样时间多花的那点时间对低频环境信号来说完全无所谓。
这里有个容易被忽略的细节：GP2Y1010粉尘传感器的LED脉冲和ADC采样必须同步。我在主循环里用一个软件定时器，每10ms执行一次下面这段逻辑：
/* 粉尘传感器 LED 脉冲控制的伪代码逻辑 */ void Dust_Led_Sample(void) { HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_SET); // 点亮LED delay_us(280); // 等待280us，光源稳定 Adc_Sample(); // 启动ADC采集粉尘通道 delay_us(40); HAL_GPIO_WritePin(GPIOB, GPIO_PIN_0, GPIO_PIN_RESET); // 熄灭LED }原理是GP2Y1010的手册规定：LED脉冲点亮约0.28ms后，光电输出达到峰值，此时必须读取电压，然后在0.04ms内关断LED进入下一个周期。如果LED常亮，或者ADC触发时机不对，读出的粉尘电压要么恒高要么无反应。这个时序问题是粉尘传感器调试中最隐蔽的坑。
3.2 粉尘和噪音的数据换算逻辑
ADC原始值要先换算成电压，公式很简单：
float voltage = (float)adc_value * 3.3f / 4095.0f;但这里有个前提：如果我在2.3节加了分压电阻，必须把分压比例还原回去。比如MQ-2经过10k和5.1k分压，实际进入ADC的电压只有原始电压的5.1/15.1，所以真正的模块输出电压要除以这个比例。
粉尘浓度换算，GP2Y1010数据手册给出的典型特性是：无尘环境下输出约0.9V，浓度每增加1mg/m3，电压大约上升0.5V。所以估算公式为：
float dust_density = (voltage_dust - 0.9f) / 0.5f; if (dust_density < 0) dust_density = 0;这个公式只能做相对估算，因为每颗传感器之间存在个体差异，环境湿度、灰尘成分也会影响结果。如果你只是做告警和趋势观察，这个精度完全够用；如果要绝对准确，就需要用标准粉尘源标定，写一个校准系数进去。
噪音换算和前面两路不同。噪音模块输出的是交流信号，不能直接拿单次ADC值当音量。我采用的方法是：连续采样一段时间，计算RMS值，再换算成相对分贝。
#define SAMPLE_NUM 1000 float Noise_CalculateDb(void) { float sum_sq = 0; float v; for (int i = 0; i < SAMPLE_NUM; i++) { v = get_adc_voltage(CH_NOISE); sum_sq += v * v; delay_us(100); /* 10kHz采样率，覆盖100ms声音信号 */ } float rms = sqrtf(sum_sq / SAMPLE_NUM); /* 以1V为参考电平，换算相对分贝。实际场景中可再用手机分贝计校准偏移 */ float db = 20.0f * log10f(rms + 1e-6f); return db; }这个公式算出的分贝值不是绝对声压级，因为模块的增益、参考电压都影响最终数值。我的做法是：先用手机上的分贝计App在安静办公室和嘈杂路边分别测一下真实值，再和模块读数对比，记下两个校准偏移量，在代码里做线性修正。这样虽然没有专业声学仪器那么准，但对环境监测足够。
3.3 滑动平均+限幅滤波，让数据曲线不再发抖
传感器原始数据，尤其是粉尘和噪音，波动非常大。直接上云的话，曲线像心电图一样，没法看。我用了两层滤波：
第一层是滑动平均，窗口选8个点。窗口太小滤不干净，太大又会让数据反应迟钝，8到16是一个比较舒服的区间。第二层是限幅滤波，专门对付WiFi发射瞬间产生的偶发尖峰。
#define FILTER_WIN 8 float filter_buf[3][FILTER_WIN]; uint8_t filter_index[3]; float SmoothFilter(uint8_t ch, float new_value) { float sum = 0; filter_buf[ch][filter_index[ch]] = new_value; filter_index[ch] = (filter_index[ch] + 1) % FILTER_WIN; for (int i = 0; i < FILTER_WIN; i++) { sum += filter_buf[ch][i]; } return sum / FILTER_WIN; } /* 限幅滤波：如果新值与上次值差超过阈值，判定为毛刺，丢弃 */ float LimitFilter(uint8_t ch, float new_value, float max_delta) { static float last[3] = {0}; if (fabsf(new_value - last[ch]) > max_delta) { return last[ch]; } last[ch] = new_value; return new_value; }粉尘传感器每10ms采集一次，8个窗口就是80ms，一个周期80ms，反应速度足够。实测下来，滤波前粉尘电压在0.85V到1.3V之间乱跳，滤波后基本稳定在0.9V左右，很直观。
4. ESP8266上云：从AT指令初始化到断线重连
数据采出来了，接下来要把数据送到云端。这块我用的是ESP8266的AT指令方案，虽然看起来“土”，但胜在稳定、逻辑清晰、容易排查问题。
4.1 ESP-01S最小系统与STM32的串口接线
ESP-01S一共8个引脚，真正用起来比想象中简单。接线如下：
| ESP-01S引脚 | 连接 | 说明 |
|---|---|---|
| VCC | 3.3V（单独供电模块） | 绝不能接5V，会烧 |
| GND | GND | 与STM32共地 |
| TX | STM32 USART1 RX | 3.3V电平，可直连 |
| RX | STM32 USART1 TX | 3.3V电平，可直连 |
| GPIO0 | 上拉10k到3.3V | 复位时保持高电平，进入运行模式 |
| GPIO2 | 悬空或上拉 | 不要强制拉低 |
这里强调一下GPIO0。ESP8266复位时如果GPIO0为低电平，会进入UART下载固件模式，表现为模块不响应AT指令，串口输出乱码或“ready”反复出现。所以GPIO0必须默认上拉到3.3V。GPIO2同理，启动时内部默认是上拉，外部不要把它拉低。
4.2 AT指令初始化流程：WiFi连接、TCP建链、POST数据
ESP8266拿到的是官方AT固件，所以一切操作都可以通过串口指令完成。初始化顺序固定：
/* 1. 测试AT指令是否正常 */ AT -> OK /* 2. 设置Station模式 */ AT+CWMODE=1 -> OK /* 3. 连接WiFi，注意替换为自己的WiFi名称和密码 */ AT+CWJAP="MyWiFi","MyPassword" -> WIFI CONNECTED WIFI GOT IP /* 4. 关闭多连接模式，只保留一个TCP连接 */ AT+CIPMUX=0 -> OK /* 5. 建立TCP连接到云平台服务器域名或IP */ AT+CIPSTART="TCP","your.cloud.server",80 -> CONNECT OK /* 6. 准备发送数据，n是下面数据的字节数 */ AT+CIPSEND=89 -> OK /* 7. 发送HTTP POST请求 */ POST /api/envdata HTTP/1.1\r\n Host: your.cloud.server\r\n Content-Type: application/json\r\n Content-Length: 44\r\n \r\n {"smoke":0.42,"dust":0.38,"noise":52.3}代码里我封装了一个发送函数，底层逻辑是：发指令等待“OK”，发数据等待“SEND OK”，然后判断服务器是否返回了HTTP 200。
uint8_t ESP8266_SendData(float smoke_v, float dust_mg, float noise_db) { char payload[128]; char cmd[160]; int len; snprintf(payload, sizeof(payload), "{\"smoke\":%.2f,\"dust\":%.2f,\"noise\":%.1f}", smoke_v, dust_mg, noise_db); /* 拼HTTP请求 */ len = snprintf(cmd, sizeof(cmd), "POST /api/envdata HTTP/1.1\r\n" "Host: your.cloud.server\r\n" "Content-Type: application/json\r\n" "Content-Length: %d\r\n\r\n%s", strlen(payload), payload); /* 先建立连接，如果失败就返回0 */ if (!ESP_SendCmd("AT+CIPSTART=\"TCP\",\"your.cloud.server\",80\r\n", "CONNECT OK", 5000)) { return 0; } /* 通知ESP8266即将发送的数据长度 */ char send_len[32]; snprintf(send_len, sizeof(send_len), "AT+CIPSEND=%d\r\n", len); if (!ESP_SendCmd(send_len, "OK", 1000)) { return 0; } /* 发送实际数据 */ if (!ESP_SendDataRaw(cmd, "SEND OK", 3000)) { return 0; } return 1; }上报频率我设成了10秒一次。环境量变化本来就很慢，10秒足够及时，也不会给云平台造成压力。如果要做产品级方案，上报间隔需要根据业务需求动态调整，甚至可以在传感器数值变化剧烈时主动临时上报。
4.3 上云协议的取舍：HTTP先跑通，MQTT再做精
这套流程我一开始用的HTTP POST，图的是简单直观。但HTTP每次上报都要建立连接、传输、断开，数据传输效率不高，Server端也需要配套HTTP接口。如果你想把方案做得更规范、更省流量，建议换MQTT协议。
MQTT的优势是长连接、订阅发布模型、QoS保证，适合物联网设备这类小报文、频繁上报的场景。ESP8266的高版本AT固件已经内置MQTT指令，大致流程是：
/* MQTT配置 */ AT+MQTTUSERCFG=0,1,"clientId","username","password",0,0,"" /* 连接服务器 */ AT+MQTTCONN=0,"your.mqtt.server",1883,1 /* 发布数据到主题 */ AT+MQTTPUB=0,"device/001/data","{\"smoke\":0.42}",0,0MQTT对云平台的接入也更标准。如果你用某免费物联网云平台，或者自己搭了开源MQTT Broker，这段AT指令基本是通用的。我的建议是：第一次跑通项目用HTTP，确定方案能转了再切MQTT，不要一上来就两套协议并行，容易把自己绕进去。
4.4 断电重连与看门狗式恢复逻辑
WiFi链路不可能永远稳定。路由器重启、信号干扰、ESP8266固件偶发卡死，都是我实际遇到过的。没有重连机制的项目，跑一天就“失联”了。
我加了三层保障：
一是主循环里定期检查TCP连接状态。用AT+CIPSTATUS查询，如果返回值里没有“CONNECTED”或者返回错误，就主动重新AT+CIPSTART。
二是连续上报失败计数。如果连续5次通信失败，说明ESP8266可能已经卡死，用GPIO控制一个三极管拉低ESP8266的RST引脚，强制硬件复位，然后重新走一遍初始化流程。这个“看门狗式”复位逻辑，我用下来非常有效。
三是掉线重连的防抖处理。WiFi刚断开的时候，不要立即疯狂重连，退避机制是：失败1次等5秒，失败2次等10秒，失败3次以上等30秒。不然ESP8266会陷入“疯狂重连-发烫-更不稳定”的恶性循环。
5. 云平台侧数据解析、曲线面板与告警联动
设备端的数据发出去了，云平台这一侧才是用户真正能看到价值的地方。大部分人觉得云平台复杂，其实现在的物联网平台已经把大部分流程标准化了。
5.1 产品/设备/主题三层结构与接入参数
主流的物联网云平台基本都采用“产品-设备-数据主题”的三层结构。产品定义一类设备的属性，设备是具体的一个硬件实例，数据通过主题或数据流上传。
这个项目里，我在云平台上创建了一个“环境监测器”产品，产品下添加了一个测试设备。设备上报的数据格式我定义为：
{ "smoke": 0.42, "dust": 0.38, "noise": 52.3 }smoke单位用电压值（V），dust单位是估算的mg/m3，noise单位是分贝。这里的单位定义在云平台上要提前配好，方便后面搭建曲线面板。
接入方式上，由于我设备端用的是HTTP POST，我在平台里创建了一个数据接口，把设备唯一标识放在URL路径里，平台根据设备ID自动关联数据流。如果你用MQTT方式，操作更直接：设备订阅/发布对应Topic，平台自动解析JSON里的字段。
5.2 数据可视化面板和阈值告警配置
数据一旦到达平台，剩下的就是配置问题。
实时曲线基本是每个平台的标配功能。我把smoke、dust、noise三个字段分别绑定到一个折线图，时间窗口选1小时和24小时两个维度，这样既能看到实时波动，也能看长期趋势。实测下来，办公室的噪音曲线在工作时间会出现明显的规律性波动，粉尘曲线在开窗通风时会下降，这些趋势用曲线面板看非常直观。
告警规则我是这样设计的：
| 指标 | 告警阈值 | 触发条件 | 通知方式 |
|---|---|---|---|
| 烟雾电压 | > 1.2V | 持续2次以上超过阈值 | 平台消息推送 |
| 粉尘浓度 | > 0.8 mg/m3 | 持续5分钟超标 | 平台消息推送 |
| 噪音分贝 | > 75dB | 持续1分钟超标 | 仅记录，不推送 |
告警阈值不能设置得太灵敏。我一开始把烟雾告警设成电压超过0.8V就触发，结果厨房炒个菜的油烟都能被判定为“火灾隐患”，一晚上狂推消息。后来改成“连续2次采样都超标”才触发，误报率明显下降。做告警一定要有去抖机制，这和前面说的软件滤波是一个道理。
5.3 可扩展方向：继电器控制、小程序通知、本地缓存
这套系统做出来后，可扩展的方向非常多，我说几个我实践过或者规划中的：
继电器联动：STM32留出两个GPIO，接继电器模块，当粉尘或烟雾超阈值时，自动开启排风扇。这是很多环境监测产品的核心卖点——监测不是目的，联动控制才是。
小程序/App通知：云平台一般都提供小程序或App SDK，配置好告警推送后，消息直达手机。这类工作基本是配置工作，不需要设备端改代码。
本地缓存：现在设备断网后就傻眼了，数据全丢。可以外接一个SPI Flash芯片，把采样数据按分钟写入缓存，网络恢复后再补传。这块会增加不少工作量，但对于数据连续性要求高的工业场景很有价值。
6. 实测数据与排查实录：这几个坑不提前知道会很伤
项目做完、跑了一周之后，我记录了一些实测数据，也把几个高频问题的完整排查思路写在这里。如果你也准备做类似项目，这些经验能帮你省下好几个晚上的调试时间。
6.1 三种场景下的实测原始数据
我在三个场景下各记录了10分钟数据，取平均值：
| 场景 | 烟雾电压(V) | 粉尘估算(mg/m3) | 噪音分贝(dB) |
|---|---|---|---|
| 安静办公室 | 0.28 | 0.03 | 48 |
| 有人走动的走廊 | 0.31 | 0.12 | 58 |
| 点燃线香附近的桌面 | 1.75 | 0.85 | 55 |
可以看到，烟雾传感器对线香这类燃烧产物反应非常明显，电压从0.3V直接跳到1.7V以上；粉尘传感器的响应也很直观，但它的数据波动更大，必须靠滤波后的值判断趋势。噪音分贝值做了手机分贝计校准，误差在正负3dB以内，作为环境监测够用。
6.2 坑1：ESP8266一连接WiFi就重启，问题出在供电
现象是：系统单独跑传感器采集一切正常，可一旦ESP8266执行AT+CWJAP连接WiFi，模块就开始反复重启，串口日志里出现乱码和“ready”，过一会儿又消失。
排查链路是这样的：我先接一个LED在ESP8266的VCC上，观察供电电压。结果发现，WiFi建立连接的一瞬间，VCC电压从3.3V掉到了2.7V左右，而模块的欠压复位阈值大概在2.8V，电压一跌破就重启。
根因是供电不足。STM32核心板上的3.3V稳压芯片输出能力有限，ESP8266发射脉冲电流大，直接把电压拉垮。解决方法是独立供电：用一个单独的AMS1117-3.3模块给ESP8266供电，并在VCC和GND之间并联470uF电解电容。这样处理后，连接WiFi时电压波动降到0.2V以内，问题彻底消失。
6.3 坑2：粉尘传感器读数恒为0或偏高，先查LED脉冲时序
GP2Y1010这个传感器，有一个朋友照着我的电路接好，ADC值恒为0。我远程帮他看代码，发现他把LED引脚直接置成高电平，没有脉冲。这个芯片的LED必须周期脉冲驱动，常亮状态下光电接收端处于饱和状态，输出反而异常。
另一种现象是读数恒偏高且不受环境粉尘影响。这种情况一般是ADC采样时机不对，没有在LED脉冲点亮后的0.28ms窗口附近采样。因为GP2Y1010的输出电压是“LED亮起后迅速爬升，随后回落”的尖峰波形，如果你采样采在波形回落之后，读到的就是一个偏高且相对固定的值。
正确的做法就是我3.1节里写的那样：先拉高LED，延时280us，启动ADC转换，再延时40us，拉低LED。这个顺序不能乱，延时也不能随意改。用逻辑分析仪看波形来调时序是最直观的。
6.4 坑3：MQ-2刚上电数值乱飘，需要预热和基线校准
MQ-2刚上电时，加热丝要一段时间才能达到工作温度，气敏材料表面也在逐渐稳定。这期间输出电压会持续漂移，有时候能漂好几分钟。如果你一上电就做阈值判断，很容易误报。
我的基线校准方法是：代码里加一个“预热模式”，系统上电后前2分钟不断采集烟雾电压并计算平均值，作为当前环境的基线电压。正常工作时的烟雾电压要减去这个基线，再做告警判断。
/* 预热完成后记住基线 */ float smoke_baseline = 0.0f; uint8_t warmup_flag = 0; void Smoke_Calibration(void) { static uint32_t sample_count = 0; static float sum = 0; if (!warmup_flag) { if (sample_count < 1200) { /* 2分钟，每100ms采一次 */ sum += smoke_voltage; sample_count++; } else { smoke_baseline = sum / sample_count; warmup_flag = 1; sum = 0; sample_count = 0; } } }这个基线在设备长时间运行后也会缓慢变化，所以我还会每24小时悄悄重新校准一次基线，保证长期部署的稳定性。
6.5 最后给一个校准技巧和调试习惯建议
做环境监测这类项目，校准永远是个绕不开的话题。我的经验是：不要执着于绝对精度，先保证相对趋势准确，再用标准设备修正偏移。粉尘浓度用单点公式估算，噪音分贝用手机App对比修正，烟雾用浓度阈值告警而不是非要算PPM，这套系统工程上足够用。
调试习惯方面，强烈建议在STM32上留一路UART调试串口，把时间戳、三路原始电压、滤波后数值、ESP8266返回状态全部打印出来。说句实在话，我做这个项目的后半程，几乎全靠这路日志定位问题。没有它，光靠云平台上的数据根本猜不到是采集坏了、换算错了还是传输丢了。
很多朋友做这类项目习惯把目光盯着“云平台多高大上”，其实真正决定项目成败的，恰恰是采集端那些不起眼的细节：传感器时序、供电余量、滤波去抖、重连机制。把这些基础打扎实，剩下的上云部分，照文档配置就行。这套思路不光适用于烟雾粉尘噪音监测，你把它换成温湿度、气压、光照传感器，整个架构几乎不用改，稍微动动采集通道和换算公式就能复用。这也是我当初选STM32的原因——它能让你把时间花在真正难的地方，而不是不断搬家换平台。
