STM32+WiFi物联网环境检测节点：烟雾粉尘噪音远程监控实战

1. 为什么我要做这个环境检测节点

前阵子有个做工厂安全管理的朋友找我，说车间里粉尘大、噪音吵，工人反映不舒服，但管理层看不到数据，也没法量化到底哪个时段、哪个区域超标。他问我能不能搞一个便宜、能联网、能实时看数据的检测设备。我第一反应就是STM32加WiFi模块，传感器用现成的烟雾、粉尘、噪音三合一方案，数据直接推到云平台，手机和电脑都能看曲线。

这个项目说白了就是一个环境检测物联网节点：STM32做主控，采集烟雾浓度、粉尘浓度、噪音分贝三个核心指标，通过WiFi模块把数据上传到云平台，实现远程监控、历史查询和超标告警。它解决的核心问题是——把看不见的环境风险变成看得见的数据，让管理者能追溯、能预警、能决策。

适合谁来参考？如果你有STM32基础，玩过串口和GPIO，想入门物联网项目，这个方案非常合适。如果你是纯小白，也没关系，我会把每个环节拆开讲，包括传感器选型、接线、代码逻辑、云平台配置，甚至踩过的坑都给你标出来。整套硬件成本控制在百元级别，复现门槛不高。

我实测下来，这套方案在室内环境下数据稳定性不错，连续跑一周没掉线。下面我把整个项目的设计思路、核心细节、实操过程和排查经验完整分享出来，你照着做基本能一次跑通。

2. 整体方案设计与选型思路

2.1 系统架构怎么搭

整个系统分三层：感知层、控制层、云端层。感知层就是三个传感器，负责把物理量转成电信号；控制层是STM32，负责采集、处理、打包数据；云端层是WiFi模块加云平台，负责传输、存储、展示。

数据流向是这样的：传感器输出模拟或数字信号，STM32的ADC或外部中断读取，经过滤波和换算得到实际物理值，再通过串口发给WiFi模块，WiFi模块以MQTT协议推送到云平台，云平台做数据存储和可视化，用户在网页或App上查看。

为什么选MQTT而不是HTTP？因为MQTT是长连接、轻量级、开销小，适合这种周期性上报小数据的场景。HTTP每次都要建连接，功耗和流量都浪费。实测下来，MQTT在STM32这种资源有限的平台上跑起来更顺畅。

2.2 主控为什么选STM32

市面上主控很多，ESP32自带WiFi更省事，但我还是选了STM32加独立WiFi模块的方案。原因有几个：第一，STM32的ADC精度和稳定性更好，粉尘和噪音信号对采样要求高；第二，STM32生态成熟，资料多，出问题好查；第三，独立WiFi模块可以灵活更换，不会被主控绑定。

具体型号我用的STM32F103C8T6，也就是常说的“最小系统板”，72MHz主频，64KB Flash，20KB RAM，资源够用，价格便宜。如果你手头有F4系列也完全可以，性能更充裕。

2.3 三个传感器怎么选

传感器是整个项目的眼睛，选错了后面全白搭。我逐个说。

烟雾传感器：我选的是MQ-2。它对液化气、丙烷、氢气、烟雾都有响应，模拟输出，接STM32的ADC引脚。优点是便宜、通用，缺点是预热时间长，大概要预热20秒以上数据才稳定，而且受温湿度影响。

粉尘传感器：我选的是GP2Y1010AU0F，夏普那款光学粉尘传感器。它内部有红外LED和光电接收管，通过检测散射光强度来判断粉尘浓度。输出也是模拟信号，但需要驱动LED脉冲，时序有要求，不能直接当普通ADC读。

噪音传感器：我选的是模拟噪音模块，核心是一个驻极体麦克风加放大电路，输出模拟电压，对应声压级。注意它输出的是瞬时值，不是直接的分贝数，需要软件做峰值检测和换算。

三个传感器都是模拟输出，STM32的ADC通道够用。这里有个细节：MQ-2和噪音模块输出范围大概0到3.3V，粉尘模块输出范围小一些，大概0到1V左右，ADC参考电压要设对，不然精度浪费。

2.4 WiFi模块和云平台的选择

WiFi模块我用的是ESP-01S，也就是ESP8266核心板，通过AT指令和STM32串口通信。为什么不用ESP32直接做主控？前面说了，我想保留STM32的ADC优势，而且ESP-01S便宜、体积小、AT指令成熟。

云平台我选的是一个支持MQTT协议的通用物联网平台，具体名字不点了，市面上这类平台很多，功能大同小异。选平台看三点：支持MQTT、有免费额度、能画实时曲线。注册后创建产品和设备，拿到三元组（产品Key、设备名、设备密钥），后面代码里要用。

注意：云平台的三元组信息相当于设备的身份证，不要泄露。代码里如果硬编码，建议做简单混淆，别直接明文放在开源仓库里。

3. 核心细节解析与实操要点

3.1 电源设计别偷懒

很多人做项目直接用USB供电，觉得5V够用。但MQ-2加热丝电流不小，大概150mA，加上WiFi模块发射时瞬间电流能到300mA，如果电源不稳，STM32会复位，WiFi会掉线。

我的做法是：输入用5V/2A的电源适配器，板上加一片AMS1117-3.3给STM32和传感器供电，WiFi模块单独用一片LDO或者直接从5V经分压供电（ESP-01S是3.3V的，千万别接5V）。另外在每个传感器的电源脚旁边并一个0.1uF和10uF电容，滤掉高频和低频噪声。

实测下来，电源做扎实了，ADC读数波动能小一半。这个细节看起来不起眼，但它是数据稳定的基础。

3.2 ADC采样与滤波

STM32的ADC是12位的，参考电压3.3V，理论分辨率是3.3/4096≈0.8mV。但实际读数会有跳动，尤其是WiFi发射的时候。所以软件滤波必须做。

我用的方法是多次采样加中值滤波：每个通道连续采15次，去掉最大和最小的3个，剩下的取平均。这样既能滤掉突发尖峰，又能平滑随机噪声。采样间隔我设的是10ms，15次大概150ms，对这三个慢变量来说完全够用。

代码逻辑大概是这样：

#define SAMPLE_TIMES 15 uint16_t adc_filter(uint8_t ch) { uint16_t buf[SAMPLE_TIMES]; for(int i=0;i<SAMPLE_TIMES;i++){ buf[i] = adc_read(ch); delay_ms(10); } // 冒泡排序 for(int i=0;i<SAMPLE_TIMES-1;i++) for(int j=0;j<SAMPLE_TIMES-1-i;j++) if(buf[j]>buf[j+1]){ swap } // 去掉首尾各3个，取中间9个平均 uint32_t sum=0; for(int i=3;i<SAMPLE_TIMES-3;i++) sum+=buf[i]; return sum/(SAMPLE_TIMES-6); }

这个滤波方法我用了很多年，简单有效，资源占用也小。

3.3 粉尘传感器的时序坑

GP2Y1010AU0F这个传感器有个坑：它的LED需要脉冲驱动，不是一直亮。典型时序是：LED亮0.32ms，然后等0.28ms再采样，整个周期10ms。如果你直接读ADC，读到的值完全不对。

具体操作是：用一个GPIO控制LED驱动脚，拉低点亮（注意它是低电平点亮），延时0.32ms，然后启动ADC采样，采样完拉高熄灭，再延时9.68ms进入下一个周期。这个时序必须用示波器或者逻辑分析仪确认，光靠延时函数有时候不准。

我当时的做法是用定时器产生PWM，周期10ms，占空比3.2%，然后用ADC的外部触发在PWM下降沿后0.28ms采样。这样时序最稳，不占用CPU。

3.4 噪音分贝的换算逻辑

噪音模块输出的是交流信号的包络，不是直接的分贝值。要得到分贝数，需要做几步：先采一段时间内的峰值，然后换算成电压，再根据模块的灵敏度曲线换算成声压级。

我用的模块灵敏度大概是-44dBV/Pa，输出经过放大后，每帕斯卡对应多少伏要看具体电路。简化做法是：在安静环境下测一个基准电压，然后用标准声源（比如手机放一个固定音量的白噪声）标定一个参考点，之后用线性关系估算。

更严谨的做法是取一段时间内的最大值和有效值，用公式dB = 20*log10(V/Vref) + K来算，其中Vref是基准电压，K是校准常数。这个K需要你自己标定，不同模块不一样。

提示：噪音测量受环境影响很大，建议在传感器外面加一个防风罩，减少气流噪声。另外采样窗口不要太短，我一般取1秒内的峰值，这样读数比较稳。

3.5 WiFi模块的AT指令配置

ESP-01S出厂固件支持AT指令，但默认波特率可能是115200或者9600，要先确认。我的配置流程是：

1. 发送AT确认通信正常
2. 发送AT+CWMODE=1设为Station模式
3. 发送AT+CWJAP="SSID","PASSWORD"连接路由器
4. 发送AT+CIPMUX=0设为单连接
5. 发送AT+CIPSTART="TCP","broker地址",1883连接MQTT服务器
6. 发送AT+CIPSEND=长度然后发送MQTT报文

这里有个大坑：AT指令的响应有延迟，不能发一条等一条，要用状态机或者超时重试。我一开始用阻塞式延时，结果WiFi信号不好的时候整个系统卡死。后来改成非阻塞状态机，主循环里轮询，就稳多了。

另外，MQTT报文需要自己拼装，包括固定头、可变头、载荷。CONNECT、PUBLISH、PINGREQ这几个报文必须实现。如果嫌麻烦，可以用现成的MQTT AT固件，但那样灵活性差一些。

4. 完整实操过程与核心环节实现

4.1 硬件接线清单

先把接线理清楚，这是最容易出错的地方。我列一个表：

接线的时候注意：ESP-01S的TX接STM32的RX，RX接TX，别接反了。还有ESP-01S的供电一定要足，我用的是单独一片AMS1117-3.3，输入5V，输出3.3V，旁边并470uF电容。

4.2 STM32端代码框架

代码分几个模块：ADC采集、传感器换算、串口通信、MQTT报文、主循环调度。我用的是标准库，HAL库也可以，逻辑一样。

主循环的节奏是这样的：每2秒采集一轮数据，采集完做换算，然后拼MQTT报文发给WiFi模块，WiFi模块负责发送。同时每30秒发一次PINGREQ保持连接。

关键代码片段：

// 主循环 while(1){ if(tick_2s_flag){ tick_2s_flag = 0; uint16_t smoke_raw = adc_filter(0); uint16_t dust_raw = adc_filter(1); uint16_t noise_raw = adc_filter(3); float smoke_ppm = smoke_convert(smoke_raw); float dust_ugm3 = dust_convert(dust_raw); float noise_db = noise_convert(noise_raw); mqtt_publish_data(smoke_ppm, dust_ugm3, noise_db); } if(tick_30s_flag){ tick_30s_flag = 0; mqtt_ping(); } wifi_state_machine(); }

smoke_convert这些函数就是线性映射，根据传感器的数据手册曲线来。MQ-2的曲线不是线性的，我用分段线性近似，在常用浓度范围内误差可以接受。

4.3 MQTT报文拼装细节

MQTT的CONNECT报文格式是固定的，我直接给一个可用的模板：

// CONNECT报文 uint8_t connect_pkt[] = { 0x10, 0x1A, // 固定头，剩余长度26 0x00, 0x04, 'M','Q','T','T', // 协议名 0x04, // 协议级别 0x02, // 连接标志，Clean Session 0x00, 0x3C, // 心跳60秒 0x00, 0x0A, // 客户端ID长度 'c','l','i','e','n','t','0','0','0','1', 0x00, 0x08, // 用户名长度 'u','s','e','r','n','a','m','e', 0x00, 0x08, // 密码长度 'p','a','s','s','w','o','r','d' };

PUBLISH报文要动态拼，主题和载荷长度会变。我写了一个函数，传入主题字符串和JSON载荷，自动计算长度并拼装。JSON格式我用的是{"smoke":12.5,"dust":35.2,"noise":58.3}，简单明了。

注意：MQTT的剩余长度字段是变长编码，小于128用1字节，128到16383用2字节。我一开始没注意，数据量大的时候报文就错了。后来写了个编码函数，自动处理。

4.4 云平台配置与数据展示

云平台那边，注册后创建产品，添加设备，拿到三元组。然后在平台的“数据流”或“物模型”里定义三个属性：smoke、dust、noise，类型都是浮点。这样平台才能解析你上报的JSON。

数据展示我用的是平台自带的仪表盘，拖三个折线图，分别绑定三个属性。设置刷新间隔2秒，就能看到实时曲线。告警规则也简单：smoke超过某个阈值、dust超过某个阈值、noise超过某个阈值，就触发邮件或App推送。

实测下来，从传感器采集到云端显示，延迟大概1到2秒，完全满足实时监控需求。历史数据平台会存，可以导出CSV做进一步分析。

4.5 外壳与安装

外壳我用的是标准塑料防水盒，尺寸大概100x68x50mm。开孔位置要注意：MQ-2和粉尘传感器要暴露在空气中，不能封死；噪音传感器的麦克风孔要朝外，但又要防尘。我在噪音传感器前面贴了一层薄薄的无纺布，既能透声又能挡灰。

安装位置很关键。烟雾传感器要装在可能泄漏源的上方，因为烟雾和某些气体比空气轻；粉尘传感器要装在呼吸带高度，大概1.5米；噪音传感器要远离设备本身的风扇噪声。我朋友那个车间，我建议他装在车间中部，离地1.6米，避开通风口直吹。

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

5.1 数据跳动大怎么办

这是最常见的问题。排查顺序：先看电源，用示波器看3.3V和5V的纹波，如果超过50mV，加电容或者换LDO；再看传感器预热，MQ-2要预热至少20秒，粉尘传感器也要几秒稳定；最后看滤波参数，采样次数不够就加大，中值滤波的窗口可以调到21次。

我遇到过一次，数据跳得厉害，最后发现是WiFi模块和ADC共用了一个LDO，WiFi发射时把电源拉低了。分开供电后立刻就好了。

5.2 WiFi连不上或者频繁掉线

先确认路由器是2.4G的，ESP-01S不支持5G。然后看信号强度，AT+CWJAP?可以查RSSI，低于-70dBm就不太稳。再检查供电，ESP-01S发射瞬间电流大，LDO响应要快，输出电容要够。

如果频繁掉线，加一个看门狗，STM32检测WiFi状态，超过一定时间没响应就复位ESP-01S。我还在代码里加了自动重连逻辑，掉线后每隔10秒重试一次，直到连上。

5.3 MQTT连接被拒绝

一般是三元组不对，或者客户端ID重复。云平台通常要求客户端ID唯一，如果你用同一个ID多设备连接，会被踢。检查产品Key、设备名、设备密钥是否和平台一致。还有，有些平台要求用户名和密码有特定格式，比如设备名&产品Key，要看平台文档。

5.4 粉尘传感器读数一直是0或者满量程

先检查LED驱动时序，用示波器看PA2脚有没有脉冲。如果没有，可能是GPIO配置错了，或者定时器没启动。如果有时序但读数不对，检查VO脚的电压范围，正常应该在0.1V到1V之间。如果一直是0，可能是传感器坏了或者供电不对；如果一直是3.3V，可能是LED没亮或者接收管饱和。

5.5 噪音读数不随声音变化

噪音模块输出的是交流包络，如果你用普通ADC读，读到的可能是直流偏置。要确认模块输出是否隔直，如果没有，加一个隔直电容。另外，采样率要够，噪音变化快，ADC采样间隔要小于1ms，不然峰值抓不到。

我一般用定时器触发ADC，1kHz采样率，采1秒，然后软件找峰值和有效值。这样读数才跟实际听感一致。

5.6 常见问题速查表

5.7 几个独家避坑技巧

第一，ADC参考电压要稳。STM32的VDDA如果和数字电源共用，噪声会串进来。我一般给VDDA单独加LC滤波，效果明显。

第二，串口通信加超时。AT指令的响应不能无限等，每个指令设500ms超时，超时就重发，重发3次还不行就复位WiFi模块。

第三，数据上报加时间戳。虽然平台会加接收时间，但设备端加时间戳更准，尤其是网络延迟大的时候。STM32没有RTC的话，可以用开机时间累加。

第四，固件留OTA接口。虽然这个项目简单，但留个串口升级接口，以后改参数不用拆机。我一般留一个命令，收到特定指令就进入Bootloader。

第五，外壳做防尘防水。工业环境粉尘大，传感器窗口容易堵。我建议每三个月清理一次，或者加一个微型风扇做气流循环。

6. 后续可以怎么扩展

这个项目跑通之后，扩展空间很大。比如加一个继电器，超标时自动启动排风扇；加一个SD卡模块，本地也存一份数据，防止网络断了丢数据；加一个OLED屏，现场就能看读数，不用掏手机。

软件层面，可以把数据推到多个平台，做冗余备份；可以加边缘计算，在STM32上做简单阈值判断，超标才上报，省流量；还可以做低功耗版本，用电池供电，定时唤醒采集。

我自己下一步打算加一个CO2传感器，把空气质量也纳入进来。传感器选型上，NDIR的CO2模块贵一些，但精度好，适合室内环境监测。

这套方案的核心价值在于：用最低的成本，把环境数据数字化、网络化、可视化。硬件不到一百块，代码开源思路清晰，云平台免费用。你照着做，一个周末就能跑起来。真正花时间的是调试和标定，但这也是最有意思的部分——看着曲线随着环境变化跳动，那种成就感比刷手机强多了。