做仓库环境控制系统源于我一个做仓储的朋友的抱怨。他那个彩钢瓦库房一到雨季就闷出一股霉味门口挂的指针湿度计卡住了都没人发现后排靠墙的纸箱返潮软到能直接按出手印。后来我用STM32配ESP8266做了一套温湿度加粉尘监测、自动通风除湿、数据上云的方案从硬件选型到云端联调前后折腾了不到一个月。这篇文章把整体设计、关键代码、控制逻辑和现场踩过的坑都整理出来适合正在做环境监控类毕业设计、或者准备给自家仓库/机房上一套低成本监控系统的朋友参考。文里的接线引脚、控制阈值、AT指令调试经验都是实测过的可以直接抄作业。1. 仓库环境控制到底在“控”什么需求拆解与架构设计很多人一上来就画原理图买模块结果做完发现既不知道每天该怎么看数据也不知道风机该什么时候开。做系统前先把需求拆清楚后面所有硬件和代码选择都会顺很多。1.1 温湿度、粉尘、通风除湿这三个环节背后的实际需求仓库环境的痛点本质上是三件事防霉、防潮、防爆。防霉靠温湿度。一般纸制品、纺织品仓库相对湿度超过65%RH就会逐渐受潮超过70%RH再加通风不良霉菌会很快繁殖。温度同样重要夏季密闭库房内部温度能比室外高出8到10度高温高湿叠加会让货损成倍放大。防爆靠粉尘浓度监测。面粉、木材、塑料颗粒、饲料这类仓储场景悬浮粉尘浓度达到一定值就有闪燃风险。虽然不需要做成工业级的粉尘爆炸监测仪但一个实时数据显示和超限报警对日常安全管理是实打实的价值。通风除湿是执行手段。检测到问题后系统要能自动打开排风机、除湿机甚至联动声光报警。这里的关键不是“能控制”而是“控制得合理”——什么时候开、开多久、怎么避免频繁启停这才是控制逻辑的难点。1.2 总体架构和模块划分检测、控制、传输三层各司其职这套系统的总体架构我分成了三层检测层温湿度传感器、粉尘传感器负责把环境物理量变成电信号。控制层STM32读取传感器数据按滞回控制策略决策通过继电器驱动风机/除湿机/声光报警。传输层ESP8266把实时数据、设备状态上报到云端同时接收远程下发的控制指令。主控选STM32F103C8T6而不是Arduino一是因为它便宜稳定二是ADC、定时器、串口资源够用三是在工厂现场需要看门狗、掉电存储这类可靠性机制时单片机比带Linux的开发板更不容易死在异常重启里。ESP8266-01S负责上云。它自带WiFiAT指令固件成熟只需占用STM32一个串口。整套系统BOM成本控制在80到120元以内比动辄上千的工业环境监控设备便宜得多这也是这类项目选型的核心逻辑够用、可靠、便宜。1.3 电源方案最容易翻车但不被重视的一环这一节值得单独说。很多人画系统框图时不把电源画进去结果上电瞬间反复重启找半天找不到原因。这套系统里有三类电源负载STM32、传感器、ESP8266需要3.3V/5V直流电流不大但对纹波敏感。继电器线圈需要5V驱动动作瞬间有几十毫秒的电流冲击。风机、除湿机是220V交流负载通过继电器隔离控制。我的供电方案是12V/2A适配器作为总输入一级降压到5V给继电器模块和DHT11二级高精度LDO降到3.3V给STM32和ESP8266。这里有个重要经验ESP8266射频发射瞬间电流能冲到240mA以上如果和STM32共用同一条3.3V供电线电压跌落会把MCU直接拉复位。所以ESP8266的3.3V电源要从LDO单独走线并在模块附近放一个100uF电解电容和一个0.1uF陶瓷电容实测重启概率明显下降。220V交流侧必须和直流侧完全隔离继电器模块的IN脚由STM32驱动但模块本身的光耦已经做了隔离控制信号线尽量短和220V走线保持距离。安全方面再强调一次所有交流侧接线要套热缩管接线端子用阻燃材质调试时戴绝缘手套这不是可以省的地方。2. 传感器选型与数据采集DHT11和GP2Y1010这两个“娇气包”传感器是整个系统最容易出“看起来没坏但数据不对”问题的部分。温湿度我用过DHT11、AHT20、SHT30粉尘用的是夏普GP2Y1010AU0F。各有各的脾气下面把接线、时序和采样代码逐一说清。2.1 DHT11单总线时序拆解拉低18ms唤醒之后要读什么DHT11是单总线协议只有一个DATA引脚时序要求精确到微秒级。接线很简单DATA接STM32的一个GPIOVCC接5V部分批次3.3V也能工作但5V更稳DATA和VCC之间要接一个4.7k上拉电阻。这里有个隐蔽的问题如果信号线长度超过20cm单总线很容易受干扰读取会时不时返回校验错误。所以传感器到主控之间的杜邦线要尽量短如果必须拉长果断换成AHT20或SHT30这类I2C接口传感器。DHT11的时序分为两个阶段——主机唤醒和传感器应答。主机先把DATA线拉低至少18ms然后释放并延时20到40us传感器收到信号后会主动把总线拉低80us再拉高80us作为应答随后输出40bit数据湿度整数、湿度小数、温度整数、温度小数、校验和。每位数据的高电平持续时间不同26到28us代表逻辑070us代表逻辑1。用带定时器的GPIO读引脚电平宽度就能解析出温湿度。实际代码里最值得注意的地方是“读超时”处理。DHT11的时序非常依赖延时精度如果用HAL_Delay这种毫秒级函数读到微秒级信号必挂。我当时用了一个简单的微秒延时函数配合在while循环里读引脚电平核心逻辑是这样的uint8_t dht11_read_bit(void) { uint8_t cnt 0; while (DHT11_IN_READ() 0 cnt 80) { // 等待低电平结束 delay_us(1); cnt; } uint32_t start 0; while (DHT11_IN_READ() 1 start 80) { // 计算高电平时间 delay_us(1); start; } return (start 40) ? 1 : 0; // 高电平时间大于阈值判为1 }判断阈值根据DHT11的数据手册50us作为0和1的分界线是安全的。读完所有位后还要做校验和验证如果校验失败就丢弃本次数据等待下次采样。另一个经验是连续两次读取之间要间隔至少1秒不然传感器响应不过来返回的数据也是错的。2.2 GP2Y1010粉尘传感器LED脉冲和采样时序才是关键GP2Y1010AU0F是夏普的红外粉尘传感器模块上有一个红外LED和一个光电接收管。它的工作原理是LED发射的红外光照射到空气中悬浮颗粒上产生散射接收管把散射光强度转换成电压粉尘浓度越高电压越大。模块有6个引脚很多人第一次接容易搞错。引脚分配如下LED-VCC、LED-GND驱动红外LED的电源接STM32的PWM引脚和地。VLEDLED脉冲驱动端需要接一个150欧姆电阻到PWM引脚。S-GND传感器地。Vout模拟输出接STM32的ADC输入引脚。VCC传感器供电5V。这里的核心难点不是接线而是LED驱动时序。GP2Y1010的红外LED不能一直亮必须用100Hz左右的PWM脉冲驱动脉冲宽度在320us左右。传感器在LED亮起后的280us处采样信号也就是那个时刻的输出电压才是有效的。我用定时器输出320us高电平、10ms周期的PWM然后在高电平出现后大约280us处触发ADC采样。STM32的定时器可以配置成比较输出触发ADC第一次实现有点绕但这就是保证数据稳定的关键。如果用软件延时打PWM再读ADC数据会跳得非常厉害。下面是我在项目中用的采样代码节选// 假设定时器以320us高电平、10ms周期触发 // 从定时器更新事件到ADC采样的延时设为280us void dust_sample_init(void) { // TIM2 CH1 - PA0PWM模式周期10ms脉宽320us // ADC1 IN0 - PA0由TIM2的TRGO或比较事件触发 } uint32_t dust_read_raw(void) { uint32_t sum 0; for (int i 0; i 32; i) { // ADC触发一次后读取循环采集32次 sum adc_read_single(hadc1); delay_us(100); // 等待下一个采样周期 } return sum / 32; } float dust_convert_voltage(uint32_t raw) { float voltage (float)raw * 3.3f / 4095.0f; return voltage; }ADC采到的电压到粉尘浓度的换算理论公式是线性关系但模块个体差异和安装位置影响非常大。我的做法是在洁净环境下记录基准电压然后在已知粉尘环境的对比值下标定一个系数最后得到浓度公式dust_mg_m3 (voltage - V0) / K。不同批次模块的V0大概在0.45V到0.55V之间K需要自己做一元线性回归。如果需要高精度测量建议购买厂家标定好的版本或者用PMS5003这类激光粉尘传感器当然价格会高不少。2.3 数据防抖连续采样、滑窗滤波和异常值剔除传感器数据直接拿去控制执行器几乎必然会出问题。GP2Y1010在自然气流下相邻两次采样可能差出20%以上DHT11偶尔也会冒出一个校验通过的坏值。所以我在控制器里加了三层数据处理连续采集N次求平均。粉尘是32次ADC平均温湿度是连续读取3次后取中位值。滑窗滤波。维护一个长度为10的采样窗口每次新数据进来替换最旧数据输出窗口平均值。这个逻辑能平滑掉短时波动又不至于像一阶低通那样改变信号相位。跳变剔除。判断当前值与上一轮输出的偏差如果超过设定阈值比如温度突变超过5度、湿度突变超过10%RH、粉尘突变超过0.3mg/m³则本次数据不参与滤波直接丢弃并把异常次数加一。连续多次异常则触发传感器自检流程。这套防抖逻辑的效果在实测里很明显没加滤波前粉尘浓度读数会在0.1到0.6mg/m³之间乱跳加上滑窗和跳变剔除后数据曲线平滑得像工业仪表的输出。3. 自动通风除湿的控制策略滞回区间和多因子联动检测数据只是手段最终目的是让风机、除湿机按合理的规则自动启停。如果直接把阈值写成“湿度超过65就开、低于65就关”系统会在临界点疯狂震荡继电器几秒钟动作一次电机寿命急剧缩短。这就是控制策略设计的核心问题。3.1 滞回控制怎么调触发和恢复阈值为什么要分开滞回控制的思想是开启触发值和停止恢复值之间留出一个死区。比如高温通风触发值设为35度恢复值设为32度。温度升到35度时启动风机降到32度时才停止。这个3度的间隔让风机不会在临界点附近反复切换实际体验就是“风机转一段时间、歇一段时间”而不是像抽风一样一会开一会关。我最终的控制参数表如下控制对象启动条件停止条件附加说明排风机温度 35.0℃温度 32.0℃冬季模式下温度下限不参与控制除湿机湿度 65%RH湿度 55%RH启动后最短运行10分钟排风机除湿联动除湿机启动除湿机停止后延时2分钟风助排湿粉尘排风机粉尘 0.8mg/m³粉尘 0.5mg/m³同时触发声光报警声光报警粉尘超标/温度超45℃粉尘恢复/温度回落报警持续到人工远程复位最小运行时间这个参数很重要。除湿机这类设备频繁启停非常伤压缩机我加了最短运行10分钟、两次启动间隔不小于5分钟的限制。实现上用一个简单的计时器状态机就可以。3.2 多因子联动高温、高湿、高粉尘同时出现时谁优先仓库环境往往不是单一参数超标。夏季午后可能同时出现高温高湿生产车间粉尘也可能在湿度高时一起上来。这时候需要给控制动作排优先级第一优先级是安全粉尘超标必须立即启动排尘风机并报警即使当前正在除湿也要先让排尘风机转起来。第二优先级是降温温度超限且湿度未超限时立即通风。这里要注意如果湿度同时超限只开排风机不开除湿机因为伦理性上降温优先避免除湿机在高温环境下工作压力过大。第三优先级才是除湿湿度超标时启动除湿机联动排风机辅助排湿。这个优先级用简单的条件语句就能实现但要在代码里留一个运行状态位避免同时启动多个设备导致电流超载。我给风机和除湿机分别加了独立的运行标志在每次控制周期先计算期望运行状态再一次性更新GPIO输出。3.3 继电器驱动感性负载的硬件保护细节控制风机、除湿机靠的是继电器通断220V交流。这里的硬件保护要是没做好后果不只是继电器损坏还可能干扰到传感器和ESP8266。我用的模块是光耦隔离继电器模块三路分别控制排风机、除湿机、声光报警。驱动逻辑是低电平触发STM32引脚上电默认高电平恰好保证上电瞬间不会误触发设备这点在选择继电器模块时要特别确认。感性负载断电瞬间会产生反向电动势会在继电器触点间产生电弧同时通过电源线反馈成尖峰干扰。我的解决方案是继电器线圈两端并联续流二极管方向反向吸收线圈断电时的反压。220V负载端风机并联一个阻容吸收电路R取100欧姆、C取0.1uF耐压630V吸收触点电弧。继电器模块供电用独立5V和传感器电源分开避免继电器动作瞬间拉低传感器电压。第一次现场联调时我的继电器没有加续流和保护结果每次风机启动的瞬间ESP8266就掉线一次。后来把上述保护加上同时给整个5V电源加了1000uF电解电容这个问题彻底消失。4. ESP8266上云AT指令开发、串口协议和断网补报整块WiFi上云链路是整个项目里最容易让人卡住的部分。很多人卡在“开发时好好的断电重启就连不上”“程序死在等待OK回复里”这类问题上下面把我的做法和教训写细一点。4.1 方案选择ATMQTT直连还是ATTCP自组协议ESP8266接入云端有几种常见路线对资源有限的STM32来说我对比下来最优的是ATMQTT直连。AT固件里自带MQTT相关指令使用4.0以上AT固件的ESP8266模块可以直接发ATMQTTUSERCFG、ATMQTTCONN、ATMQTTPUB这类指令完成连接和订阅。这种方式的优势是云端选型灵活可以对接标准MQTT Broker比如EMQX或各类物联网云平台STM32只负责拼字符串和解析回复不需要关心TCP协议栈。如果手头模块的AT固件版本比较老不带MQTT指令也可以退回到传统方案用ATCIPSTARTTCP,服务器地址,端口建立TCP长连接然后自己封装一个简单的JSON协议。这种方式的缺点是需要自己在云端做协议解析还要设计心跳、分包工作量大不少。我建议优先检查固件版本一条ATGMR就能看到。如果固件支持MQTT直接走MQTT路线最省事。4.2 串口通信解析为什么你的程序会卡死在等待“OK”里ESP8266通过串口和STM32通信AT指令交互是“发送指令-等待回显-等待OK/ERROR”的模式。很多人在这一步会踩一个很经典的坑用阻塞式循环等待串口返回“OK”结果模块返回的是“ERROR”或其他字符程序就在死循环里出不来。这个问题我在调试时遇到过现象是运行一段时间后系统卡死重启就好但过会儿又卡死。后来排查发现是等待函数里只搜索“OK”字样而ESP8266在WiFi不稳定时会返回一堆乱码或“WIFI DISCONNECT”的主动上报字符串被截断了搜索“OK”永远找不到。正确做法是设计一个带超时的非阻塞等待函数uint8_t esp_wait_string(const char *target, uint16_t timeout_ms) { uint32_t start HAL_GetTick(); while ((HAL_GetTick() - start) timeout_ms) { // 从串口缓冲区读取一个字符 // 如果收到完整的一整行与目标字符串比较 // 匹配则返回1不匹配则清空缓冲区继续等待 if (strstr(rx_buf, target) ! NULL) { memset(rx_buf, 0, sizeof(rx_buf)); return 1; } // 如果等待期间收到ERROR或乱码清空缓冲后继续 } memset(rx_buf, 0, sizeof(rx_buf)); return 0; }回复“OK”和“ERROR”之外的主动上报字符串比如“MQTTPUB: OK”或者“WIFI DISCONNECT”都要考虑进去。一次完整的AT指令交互我用的是“发送指令加回车换行等待预期回复超时重试最终失败则执行重连逻辑”这一套流程不依赖单次成功。4.3 云端物模型和数据链路断网缓存补报设计上云不只是把数据发出去还要设计数据格式、控制下发链路和断网补偿机制。这套系统的物模型我定义了四类数据点温湿度数据{temp: 25.6, hum: 63.2}每5秒上报一次。粉尘数据{dust: 0.32}与温湿度合并后同帧上报。设备状态{fan: 1, dehum: 0, alarm: 0}状态变化时立即上报。远程控制指令{cmd: fan_on, val: 1}云端下发到设备后执行。上报MQTT的典型指令格式ATMQTTPUB0,topic/device/data,{\temp\:25.6,\hum\:63.2,\dust\:0.32},1,0注意MQTT的QoS我选的1确保消息至少送达一次。云端侧订阅一个控制topic收到指令后解析JSON回复设备状态topic确认指令已执行。断网补报是我觉得这套设计里最值得复制的部分。仓库现场的WiFi信号、公网链路不可能一直稳定如果断网导致监控数据丢失系统就失去意义了。我的实现是在STM32内部维护一个环形数据缓冲区每条缓存记录12字节包含时间戳和温湿度粉尘值。断网期间每秒写入一条最多缓存500条也就是约8分钟的数据。重连成功后按时间顺序逐条发送每条发送完确认收到再发下一条避免数据拥塞。如果缓冲区写满就丢弃最早的记录保证数据时间线不出跳跃。5. 现场实测与调试实录彩钢瓦仓库里踩过的坑写到最后一部分也是最实用的一部分。这套系统从焊好板子到现场跑通我在那个彩钢瓦仓库里来回跑了四五趟下面这些经验都是用故障换来的。5.1 WiFi信号问题金属结构仓库里的信号衰减彩钢瓦仓库对2.4GHz WiFi信号屏蔽非常严重。第一次去现场ESP8266在仓库中间完全搜不到路由器的WiFi就算放在门口信号强度也只有两格。解决办法是升级天线。普通ESP8266-01S是用PCB板载天线信号增益很弱。我换成了外置天线版本型号是ESP8266-01S带IPEX座引出一根2.4G天线通过开孔伸到仓库外墙。天线用一根1米长的馈线延长实测外置天线版本在仓库中央也能稳定维持在距离路由器30米、穿两层钢板墙的条件下不掉线。如果仓库更大我建议在仓库内加一个AP做无线中继或者直接换成4G模块这个后面的扩展思路里会提到。5.2 传感器安装位置带来的测量偏差这部分踩坑比较多而且是那种“看着合理、实则不对”的坑。湿度传感器最初装在仓库进门右侧的墙上结果每次大门打开冷热空气对流都会让湿度瞬间飙升10%RH以上系统就会误启动除湿机。后来把传感器移到仓库中部靠货架的位置避免空调口和门口直吹区域读数平稳了很多。粉尘传感器也有类似的教训。第一版安装时我把GP2Y1010直接挂在风机出风口旁边气流直接吹向传感器读数波动极大风机一转粉尘数值反而飙高。后来给传感器加了一段黑色的PVC遮挡管进气方向设计成侧向开口避免光线直射和气流直吹数据才回归正常。总结是传感器要放在能代表整个环境的位置要避免直吹、直晒、门口、墙角这类特殊区域。安装支架用3D打印做了两个一个放温湿度传感器一个放粉尘传感器都是45度向下倾斜防止积灰和凝结水滴。5.3 电源瞬降导致ESP8266循环重启这个问题我在1.3节提到了但值得用一次现场故障来具体说明。首次部署完的第二天仓库管理员反馈说系统“一会儿在线一会儿不在线”远程看数据发现温湿度上报时断时续。到现场用示波器测ESP8266的3.3V引脚发现每当继电器吸合风机启动时3.3V会瞬间跌到2.7V左右持续几十毫秒。ESP8266的供电电压下限约2.9V电压一掉它就重启了重启后重新连接WiFi连接过程中风机可能已经停了电压恢复接着再启动陷入循环重启。根因是LDO输出电容太小无法吸收继电器线圈吸合瞬间的瞬态电流。修复方法前面说过在ESP8266电源端加100uF电解电容和0.1uF陶瓷电容同时把继电器模块供电从同一个3.3V LDO上挪到独立的5V直接供电模块本身是5V继电器问题彻底解决。这再次说明多模块系统里电源设计不是搭个LDO就完事要按各模块的动态电流逐项核算。5.4 看门狗、日志与自恢复机制系统在无人值守的仓库里运行不可能每次出问题都派人去按复位键。我给STM32加了两个关键机制独立看门狗和运行日志。独立看门狗IWDG每500ms喂一次主循环任何位置卡死超过时间就会自动复位系统后重新初始化。看门狗必须在正确的位置喂不能在中断里喂否则主程序卡死了看门狗照样被喂失去意义。我是在主循环的最后喂狗并在喂狗时检查所有任务的时间戳是否超时比如ESP8266最近一次心跳超过3分钟就先复位ESP8266再继续。运行日志通过串口1输出到调试口同步写到STM32内置Flash的一个页里以环形记录方式保存最近100条日志。这样即使设备掉线也能通过USB读日志分析故障前后的上下文。日志格式很简单时间戳加事件代码比如[12345] DHT_ERR、[12679] ESP_REBOOT。这套机制在后期排查问题时帮了大忙尤其是“系统为什么半夜3点自己重启了”这类问题日志一看便知。6. 二次开发的扩展思路从仓库环境监控到更多场景整套系统跑通后我在想怎么让它发挥更大价值。现在这个架构里STM32的串口、定时器、GPIO都还有富余扩展能力很强。最直接的扩展是增加更多传感器。仓库如果有漏水风险可以在墙角加一个水浸传感器接在ADC或GPIO上报警逻辑和粉尘报警一样走声光报警加云端推送如果有贵重物资可以加一个被动红外传感器做入侵检测。只需要在物模型里增加对应数据点控制逻辑里添加新的联动规则即可。传输层方面如果现场实在没有WiFi或者仓库太大把ESP8266换成4G DTU模块使用标准AT指令拨号加TCP连接也能很快对接到原STM32代码。这样一套硬件基本不用改只是把串口指令从“连WiFi发MQTT”换成“拨号发TCP”而已。还有一条很实用的方向是本地显示。现在系统只上报云端现场想直接看数据还得掏手机。加一块0.96寸OLED或者1.8寸TFT屏用I2C接口接上把温湿度、粉尘浓度、风机状态、WiFi连接状态循环显示现场巡检体验会好很多。OLED的I2C只用两根线对现有系统零改动。云端侧如果想再进一步可以用接入时序数据库配合可视化仪表盘把温湿度变化曲线拉出来这样就能自己做环境趋势预测比如“连续三天湿度持续上升预计后天达到65%RH提前开启除湿机”。这一步开始有点工业智能化的意思但技术门槛并不高核心就是先把数据稳定存下来。从硬件选型到现场部署这套方案的每一个环节我都走了一遍完整闭环。如果再让我做一次我会先把数据链路画清楚再动手焊板子传感器采样到MCU、MCU到控制逻辑、MCU到ESP8266、ESP8266到云端、云端到APP每一跳都明确断点时的处理策略和恢复机制。想清楚这些再动手整个开发周期至少能缩短一半。