接手仓库环境控制系统这个项目时我脑子里列出的核心需求其实很清楚温湿度数据要能实时监测粉尘浓度不能靠鼻子闻通风除湿不能全靠人工去现场开设备最后还要把数据送到手机/电脑上方便远程盯。这几条拼到一起STM32做主控、ESP8266负责上云几乎是顺理成章的选择——STM32生态成熟、资料多、外设齐全ESP8266价格低廉、WiFi联网简单两者通过串口一接一套能自动运行、能上报数据的仓库环境监测终端就有了骨架。这篇内容我会把整个项目从选型到最终调试的完整过程拆开讲包括硬件电路设计、传感器驱动写法、控制策略的阈值逻辑以及ESP8266走MQTT上云时最容易卡住的几个问题。无论你是做毕业设计、电子竞赛还是真给自家仓库/车间做一套环境监控里面的实操细节应该都能直接拿来用。1. 仓库环境控制的痛点与方案定调1.1 为什么“温湿度粉尘”是仓库环境监控的第一优先级很多仓储场景最容易出问题的是这两类一类是湿度南方回南天或者地下库房墙面地面结露、纸箱变软、金属件生锈、精密仪器受潮都是湿度失控惹的祸另一类是粉尘电子制造车间、木材加工仓库、面粉/饲料储存区粉尘浓度过高既影响产品良率也有安全隐患。只装一个温湿度计、靠人每天去抄一次数的方式问题在于——数据是离散的你永远不知道夜间断电或设备故障时仓库里发生了什么。所以自动监测不是“锦上添花”而是把环境波动从“事后发现”变成“实时感知”。再加上自动通风除湿本质上就是把人的经验固化成程序逻辑湿度高了开排风机、开除湿机温度高了加强通风粉尘超标就声光报警并强制排风。1.2 方案对比纯机械定时控制 vs 传感器反馈闭环控制市面上很多仓库用的是最粗暴的定时通风方案——每天早上8点自动开风机、下午6点关掉。这种方案的缺陷很明显过分依赖经验季节变了、天气变了、仓库装的东西变了原来的定时策略就失效了。我这次选择的是传感器反馈闭环STM32持续读取温湿度和粉尘数据经过滤波和阈值判断后通过继电器控制排风扇、除湿机、加热器等执行设备。这样做的好处有三点控制是自动的完全不需要人工干预数据异常会主动报警执行动作有明确触发条件省电、减少设备空转所有历史数据可以上传到云端后续做分析也有据可查。1.3 系统整体框架速览从功能区块上看系统可以分成三层感知层DHT11温湿度传感器 GP2Y1010AU0F粉尘传感器控制层STM32F103C8T6负责数据采集、滤波、阈值判断、继电器控制同时通过串口与ESP8266交互上云层ESP8266通过WiFi连接路由器走MQTT协议把数据推送到巴法云/OneNET这样的物联网平台手机端实时查看。这三层之间的连接全是常规接口硬件成本控制在几十块钱级别非常适合作为一套可复制的仓库环境监测参考方案。2. 硬件电路设计与传感器选型细节2.1 主控选型STM32F103C8T6够不够用这个项目的负载并不重一路单总线读温湿度、一路ADC采粉尘电压、几路IO控制继电器、一路串口跟ESP8266通信。哪怕再加上OLED显示STM32F103C8T6的资源也完全够用——72MHz主频、20KB RAM、64KB Flash这些外设任务占用的资源连30%都不到。有人会用STM32F407甚至H7来跑这类项目我的看法是没必要。环境监控是慢变量系统传感器的数据更新频率本身就很低DHT11最多每秒读一次主控性能再强也发挥不出来。倒不如把成本省下来用在传感器精度的提升上。提示选STM32F103C8T6“蓝板”时注意市面上很多板载芯片是国产GD32替代的例程兼容性基本没有问题但ADC精度和低功耗表现跟原厂略有差别。要求严格的项目建议用正品芯片。2.2 温湿度传感器DHT11、DHT22还是SHT30三大温湿度传感器对比结果我列了张表传感器湿度精度温度精度价格接口优缺点DHT11±5%RH±2℃约3元单总线便宜耐用精度偏低测量频率受限DHT22±2%RH±0.5℃约15元单总线精度大幅提升但时序更严格SHT30±2%RH±0.3℃约8元I2C精度高、体积小、有官方库推荐预算充裕的话我建议直接上SHT30I2C接口写起来轻松很多精度也比DHT11高一个级别。但我这次用的是DHT11原因有几个一是手头库存充足二是仓库环境波动范围大±5%的湿度误差在控制策略里可以通过阈值回差hysteresis吃掉——后面会详细讲。DHT11的细节提醒一下单总线时序非常苛刻读数据前主机要拉低总线至少18ms来触发传感器应答之后切换为输入模式。很多初学的朋友挂在“切换IO方向”这一步上STM32的GPIO要不断切换模式写错了就读出一堆0xFF。代码里我通常用寄存器直接操作速度比HAL库快得多。2.3 粉尘监测GP2Y1010AU0F工作原理与ADC采样电路粉尘传感器选择的是夏普GP2Y1010AU0F内部结构是红外发光二极管配合光电二极管利用空气中颗粒物对红外光的散射效应来检测浓度。这个传感器吸入的空气经过检测腔粉尘颗粒越多散射光越强光电二极管输出模拟电压就越高。模块一共6个引脚VCC、GND、AOUT模拟输出、ILEDLED脉冲驱动、VLEDLED电源、还有一根空脚。典型驱动方式是给ILED一个周期10ms、脉宽0.32ms的脉冲信号驱动内部红外LED在脉冲开始约0.28ms后用ADC采样AOUT引脚的电压采样到的电压经过换算得到粉尘浓度。这里有个非常容易踩的坑GP2Y1010AU0F的推荐供电电压是5V而STM32的ADC输入范围是0~3.3V。模块输出电压在干净空气中约0.9V左右粉尘严重时可能逼近4V。如果直接把AOUT接到STM32的PA1去采集电压超过3.3V的部分全都会被削顶传感器“看”不到高浓度粉尘。我当时做的处理是分压在AOUT和STM32的PA1之间串一个10K电阻PA1再接一个10K电阻到GND也就是2:1分压把0~5V的输出范围压到0~2.5V保证ADC永远工作在量程内。分压会牺牲部分分辨率但12位ADC在0~3.3V下有约0.8mV的分辨率配合后面的换算公式精度完全够用。注意GP2Y1010AU0F上电后有大约1分钟以上的预热期预热期间输出会逐渐漂移。实际项目中第一次上电后的前1分钟数据不要当作真实浓度上报建议在程序里加一个“传感器预热标志”预热完成后才允许触发控制动作。2.4 执行机构继电器模块与光耦隔离的接线要点通风和除湿的执行端通常是220V设备——排风扇、除湿机、加热器。STM32的GPIO绝对不能直驱这些设备必须通过继电器中转。我用的是1路/2路继电器模块模块自带光耦隔离和三级管驱动STM32的GPIO输出高电平/低电平就能控制继电器动作。接线要点继电器模块的VCC和GND接外部5V电源不要从STM32的3.3V引脚取电否则继电器线圈吸合瞬间的电流跌落会导致主控复位STM32的GPIO通过一个1K电阻接到继电器模块的IN引脚模块内部光耦已经做了隔离不需要再额外加驱动220V侧接线必须使用正规电工端子线径要足够千万不能把强电和弱电走在一起。执行元件配置上我用了两路继电器一路控制排风扇一路控制除湿机。排风扇可以增加调速但实际测试下来仓库这种空间用开关量控制要么开、要么关已经足够不需要额外加PWM调速。2.5 供电设计不要把所有负载挂在同一路电源上供电是整个系统最容易出现“莫名其妙复位”的根源我遇到过太多类似的故障排查了。正确的供电拓扑应该是220V经降压模块输出12V给排风扇供电12V经过DC-DC降压模块输出5V给继电器模块和粉尘传感器供电5V经过AMS1117-3.3输出3.3V给STM32核心板和ESP8266模块供电。三个电压等级逐级降压好处是隔离了不同负载的瞬态干扰。12V风扇启动瞬间的电流尖峰会被5V/3.3V两级稳压模块吸收掉很大一部分不会直接冲击单片机。如果条件有限只能单电源供电我建议至少把继电器模块和单片机分开供电——哪怕用两个独立5V适配器也行然后共地。3. 下位机代码架构从裸机状态机到传感器驱动3.1 慢速系统的程序骨架定时调度与状态标志位整套系统的实时性要求并不高所以我采用裸机 定时器中断轮询的结构没有上RTOS。理由很直接状态数量少、任务周期长、逻辑顺序固定裸机完全可以满足还能免去FreeRTOS带来的动态内存和任务切换开销。程序的主循环可以简化为定时器每10ms触发一次中断在中断里累加计数计数达到20次即200ms时置位“需要读取DHT11”的标志计数达到100次即1s时置位“需要读取粉尘ADC”的标志主循环检测到标志后执行对应读取程序然后进入控制判断。这个结构看着简单但它解决了一个关键问题DHT11的读取过程有严格时序要求不能被打断否则数据全错。如果在主循环里靠延时函数穿插其他任务很容易出事。用定时器加标志位的模式可以保证每个传感器在读取期间独占CPU。3.2 DHT11单总线时序驱动核心逻辑DHT11的读取时序有三段起始信号、响应信号、40位数据。关键点在于每一段都有严格的时间窗口主机拉低总线18~30ms然后释放并延时20~40us传感器拉低80us表示响应再拉高80us准备输出数据每位数据从低电平50us开始之后高电平持续26~28us表示“0”70us左右表示“1”。代码表达上我建议用寄存器操作GPIO模式切换加定时器微秒延时避免HAL库函数级联带来的引脚翻转延时误差。读回来的5个字节如果校验字节不等于前4字节之和的低8位就丢弃这帧数据等下一次读取。经验DHT11的读取周期要保持在1秒以上不要连续读两次。连续读太快时传感器来不及更新内部数据返回的数值会保持不变很多人误以为传感器坏了。3.3 粉尘传感器PWM触发与ADC滑动平均滤波GP2Y1010AU0F的采集不是直接读AOUT就完事的模块要求先给ILED引脚一个周期10ms、高电平0.32ms的脉冲然后在脉冲高电平持续约0.28ms时去采集AOUT。简单说就是“先打光再采样”。在STM32上我用的方案是定时器PWM输出配置成100Hz频率、3.2%占空比单次PWM周期内正好是0.32ms高电平。开启ADC定时采样用DMA连续采8次后取平均。这样PWM触发、ADC采集、DMA搬运都不用CPU干预主循环只需要读DMA搬运完的内存数组。ADC采样到的电压值和粉尘浓度的关系近似线性粉尘浓度(mg/m³) (ADC电压 - 基准电压) × 灵敏度系数基准电压受传感器本身误差影响较大不同模块之间都能差出一截。实际项目里最好在干净环境中采集一次基准值然后通过程序里的校准系数调整。再叠加滑动平均滤波维护一个长度为10的环形缓冲区每来一个新样本就覆盖最老的数据然后输出平均值。这步能把粉尘数据的随机波动压得很平控制逻辑不容易因单次尖峰误触发。3.4 自动通风除湿控制策略阈值、回差与联动规则传感器读回来的数据最终要转化成执行动作这是用户最关心的部分。阈值设死了不行——比如湿度设到60%就开除湿机但环境在59%~61%之间跳动时继电器的频繁吸合会让人崩溃还会减少继电器寿命。所以控制上必须加深回差迟滞区。我的设定如下控制项触发条件关闭条件排风扇温度 30℃ 或 湿度 70%RH温度 28℃ 且 湿度 65%RH除湿机湿度 70%RH湿度 65%RH粉尘报警排风粉尘浓度 0.3mg/m³粉尘浓度 0.2mg/m³回差让设备一旦开启后不会因微小波动立刻关闭而是需要回落到一个更低阈值才停。这样做的好处减少继电器动作次数、稳定环境参数波动范围、保护执行设备。联动规则也重要。例如温度偏高和湿度偏高同时发生时只开排风扇可能不够这时可以排风扇除湿机同时开启快速降低绝对湿度如果夏天温度高但湿度低只开排风扇就行避免除湿机产生的热量加剧升温。4. ESP8266上云AT指令 MQTT的最稳实现路径4.1 用AT固件还是刷SDK我为什么选AT指令ESP8266上云有两种主流玩法一种是给ESP8266刷带MQTT库的NodeMCU固件或Arduino固件C代码直接在ESP8266上跑另一种是ESP8266保留官方AT固件STM32通过串口发AT指令来操作它。我在这个项目里选择的是AT指令方案原因有三个STM32已经存在ESP8266只是个外围通信模块把应用逻辑放在STM32上职责清晰AT指令方案调试直观——每一个环节都能通过串口监视器看到ESP8266的回显出了问题知道卡在哪一步后期如果换用其他WiFi模块比如ESP32-C3、Air724UG只需要改串口下发指令的代码控制逻辑不用动。当然AT方案也有短板AT指令处理是阻塞式的如果WiFi信号差导致AT响应超时STM32的串口发送线程这里是主循环就会被拖住。这个问题后面会在超时和重连策略里细讲。4.2 STM32与ESP8266的串口通信框架与超时处理STM32的USART2接ESP8266波特率115200。发送AT指令时我封装了一个自己的函数// 发送AT指令并等待指定应答超时返回超时标志 uint8_t AT_SendCommand(const char* cmd, const char* expect, uint16_t timeoutMs) { uint8_t buf[128]; uint16_t index 0; memset(buf, 0, sizeof(buf)); // 清空接收缓冲 while (__HAL_UART_GET_FLAG(huart2, UART_FLAG_RXNE)) (void)huart2.Instance-DR; HAL_UART_Transmit(huart2, (uint8_t*)cmd, strlen(cmd), 500); uint32_t start HAL_GetTick(); while (HAL_GetTick() - start timeoutMs) { while (__HAL_UART_GET_FLAG(huart2, UART_FLAG_RXNE)) { buf[index] (uint8_t)(huart2.Instance-DR 0xFF); if (index 127) return 0xFF; // 缓冲溢出 } if (strstr((char*)buf, expect) ! NULL) return 0x00; // 收到预期应答 } return 0xFF; // 超时 }这里的关键有三点发送指令前先清空接收缓冲区避免上一次的遗留回显干扰判断用strstr做模糊匹配不要求完全相等——因为AT固件回显里经常夹杂\r\n、等字符完全字符串比较极容易翻车一定要加超时参数没有超时的等待等于程序自杀。4.3 AT固件连接WiFi与MQTT的完整指令序列从AT固件开机到MQTT成功发布消息完整的指令序列如下我用的是巴法云1883端口匿名认证步骤AT指令预期返回1ATOK2ATCWMODE1OK3ATCWJAPSSID,密码WIFI GOT IP4ATMQTTUSERCFG0,1,clientId,user,pass,0,0,OK5ATMQTTCONN0,bemfa.com,1883,1OK6ATMQTTPUB0,topic,payload,0,0OK提示一点巴法云其实用TCP 1883端口连MQTT也可以它提供了一个不需要证书的通道正是AT固件能用起来的基础。如果换成需要TLS证书的平台AT固件就得折腾证书写入复杂度会显著上升。新版的AT固件比如1.7.x之后MQTT命令都是带数字参数的老资料里常见的ATMQTTCONN不带参数的写法已经不适用了。刷固件前务必确认版本。4.4 上云数据协议设计字段简洁、单位统一MQTT是消息通道消息内容格式完全由自己定。我第一次做的时候直接拼了一个带中文单位的长字符串结果云端显示乱码——问题出在STM32里保存的是UTF-8编码的中文到了巴法云的后台又按UTF-8解码两边不一致就全乱了。后来我把数据协议改成纯ASCII以JSON结构简化字段名用拼音和数字表示单位。{temp:25.6,humi:68.4,dust:0.12,fan:0,dehum:1}这个格式的好处没有中文从根本上杜绝编码问题字段短省流量AT固件发布消息的字节数有限制云端解析和第三方接入都很方便。如果你确实要在平台上显示中文名称我建议在云端规则里做映射而不是在STM32侧发中文。4.5 掉线重连和看门狗不要让设备“默默死去”仓库环境监控最怕的情况是传感器正常、设备断电了没人发现。所以稳定性设计必须前置。我的做法是在主循环里定期检查与ESP8266的MQTT连接状态通过ATMQTTCONN?查询如果查询结果不是MQTTCONN: 0,1就按“WiFi重连→MQTT重连→发布补数据”的顺序恢复串口操作超时之后记录错误计数连续超过5次就触发全片复位重新走初始化流程独立硬件看门狗IWDG周期设置为4秒主循环正常运行就喂狗卡死自动复位。这套机制跑下来设备在断网、路由器重启等场景下都能在1~2分钟内自动恢复基本不需要人工干预。5. 实测数据、调试踩坑与优化心得5.1 环境实测粉尘传感器的启动预热与零漂系统装好之后我做了一个72小时的连续测试放在一间约60平方米的半封闭储存间里前期暴露出了两个明显问题。一是粉尘传感器启动预热期的零漂。GP2Y1010AU0F刚上电时输出电压从0.6V左右缓慢上升大约1分钟才稳定到0.9V附近。如果把这个漂移过程中的电压当成真实浓度上报后台看到的粉尘曲线开头就是一段明显抬高的假期信号。解决方案前面也说了上电后延时60秒再开始上报粉尘数据同时用刚上电10秒内的平均值做基准校准换算公式。二是风机关闭时粉尘数据依然有波动。排查后发现是环境本底粉尘较高加上传感器安装在排风扇旁边的墙壁上排风扇停转后附近气流变化导致局部粉尘聚集。我把传感器进气口加长了一段PVC管同时加了一层可拆卸的粗滤棉数据稳定度明显提升——但要注意滤棉会截留粉尘用一段时间后需要更换否则读数会越来越低。5.2 调试中让我卡得最久的三个问题问题一ATRESTORE之后一直等不到“OK”这是我这次调试中最大的一个坑。ESP8266执行ATRESTORE后要重新启动整个恢复出厂过程约1~3秒如果程序在发送指令后立刻死等OK这期间模块的回显只有一堆乱码和启动日志根本没有OK。处理方式发送ATRESTORE后故意等待3秒再发送一个AT尝试握手等它返回OK后才继续后面的配置。不要做无超时的死等最稳妥的是把恢复出厂做成单独指令由上位机手动触发不放在自动初始化流程里。问题二ADC通道串扰我的粉尘传感器接的是PA1板上还有一个按键接在PA0。奇怪的是按键按下时粉尘ADC读数会跳变。查到最后是芯片内部相邻模拟通道之间的耦合加上PA0按键的光滑参考电压波动影响了同一ADC模块里正在转换的PA1。处理方式很简单把按键挪到PB0上避开ADC的邻居通道同时ADC采样时连续采集16次去掉最大最小再平均串扰问题就消掉了。这也提醒我GPIO规划阶段就要把模拟信号和数字开关信号尽量分开放。问题三继电器吸合瞬间STM32复位开始时继电器模块和STM32共用一个5V适配器每次吸合瞬间系统就重启。用示波器看5V电压在继电器吸合时跌落到3.8V左右维持了约20ms足够STM32复位。处理方式强电设备、继电器、传感器、单片机四路供电全部独立DC-DC隔离仅共用参考地。从那之后再没有出现过复位问题。长期运行中还加了一个简单的RC延时启动继电器模块的VCC经过一个10欧姆电阻和1000uF电容再上电避免上电瞬间的浪涌。5.3 长期运行优化建议系统先后跑了一个多月的连续测试汇总出几条很实在的优化建议数据落盘STM32的Flash写次数有限不建议高频写日志。我用了一片AT24C02I2C存最近100条超标记录按5分钟间隔滚动覆盖。掉电数据不丢也方便后续排查设备历史状态远程控制环境中转过来的告警要能反推执行设备状态建议在MQTT上行协议里加上设备当前开关状态字段云端和本地对照出现偏差时主动上报“执行异常”传感器校准周期粉尘传感器长期暴露在仓库环境里光学窗口容易被污染建议每1~2个月用干燥洁净空气做一次基准校准必要时拆开清理云平台数据保留免费平台的存储周期和消息条数都有限制高频数据建议本地缓存后周期汇总上传比如每5分钟上传一次均值既省流量也避免云端封顶。写在最后这套系统从画原理图、写驱动、调AT指令到整机联调前前后后花了两周多。回头整理一遍技术上的复杂度其实不太高真正花时间的地方都在处理“硬件不按照数据手册工作”这类事。我个人的体会是做这种多传感器上云的项目先别急着把代码写得多花哨把以下几件事做好整个系统基本就稳了一是供电隔离一定要舍得花成本继电器吸合导致单片机复位是环境控制类项目最高频的坑二是传感器的采样必须加滤波和校准机制裸数据直接用于控制迟早出问题三是串口和AT指令交互必须写好超时和异常处理永远不要假设ESP8266会按预期响应。如果后面要做升级我建议往两个方向扩展一是加一个OLED或者小尺寸LCD屏在设备端直接显示实时数据和设备状态方便现场巡检二是把粉尘传感器的检测换成激光散射式如Plantower PMS5003精度能提高一个量级当然成本也会上去。考虑到仓库粉尘检测的核心需求这个升级是最有价值的。