仓储环境最怕的就是闷、潮、粉尘。以前去仓库巡检拿个手持温湿度计挨个点位记录又慢又容易漏更别说半夜湿度过大没人发现一仓库纸箱受潮直接损失惨重。所以我自己搭了一套基于STM32的仓库环境控制系统把温湿度、粉尘监测、自动通风除湿和ESP8266上云一次做齐了。这套方案成本不高、原理清晰既能跑起来当实用系统又能拆开当毕业设计或者竞赛项目做非常适合电子爱好者、自动化专业学生和做物联网方案的人参考。1. 项目整体设计与方案选型1.1 为什么选STM32F103C8T6做“大脑”主控这块我几乎没有犹豫直接选了STM32F103C8T6。很多朋友问我既然都要上云了干脆用ESP32一个芯片既能采集又能联网多省事。这话理论上没错但从分工角度看数据采集、逻辑控制、继电器驱动这些实时性要求高的活和网络协议栈这种容易阻塞的任务放在同一个芯片上容易互相干扰——比如你要精确读取DHT11的时序结果WiFi中断一来时序被打乱读取直接失败。STM32F103C8T6在这个场景里有几个实打实的优势72MHz主频、64KB Flash、20KB RAM跑一个采集加控制的逻辑绰绰有余有足够多的GPIO和定时器能同时驱动多个传感器ADC是12位的接粉尘传感器输出足够用USART资源也够跟ESP8266通信完全不用省。更关键的是资料极其丰富标准库和HAL库都能写遇到问题搜一圈全是答案。从项目稳定性和可维护性来讲STM32做主控、ESP8266只负责透传上云就是最合理也最不容易翻车的组合。功耗上我实测过整机正常运行电流大概在300mA左右主要是继电器和风扇的功劳如果做电池供电版本可以加睡眠模式控制。这块后面在软件部分会细说。1.2 传感器选型温湿度和粉尘监测的搭配逻辑温度湿度我用了DHT11这个传感器虽然精度一般温度误差±2°C湿度误差±5%RH但胜在便宜、接口简单、资料海量。如果对精度有更高要求可以直接换成DHT22或者SHT30代码改动量不大——我把DHT11的读取函数封装成了独立模块就是考虑到后面要替换。粉尘检测用的是夏普GP2Y1010AU0F这是一颗红外光电式粉尘传感器能检测PM2.5左右的颗粒物浓度。它内部有一个红外发射二极管和一个光电晶体管空气经过检测腔时粉尘颗粒会散射红外光光电管接收到的信号强度变化就反映了粉尘浓度。输出电压和粉尘浓度近似线性关系灵敏度大约0.5V/(100μg/m³)。需要注意的是这颗传感器需要周期性脉冲驱动——红外LED不能一直点亮必须按照datasheet要求给脉冲信号采样时机也要卡准这个我放在第三章讲。还有个方案是用PMS5003这类激光散射传感器直接输出串口数据还能直接给出PM2.5和PM10数值。但我没选它一来价格高出好几倍二来功耗大三来它对风道有要求需要加风扇抽气结构上麻烦一些。GPY1010AU0F输出模拟量接STM32的ADC引脚就行结构简单仓库这种大空间的监测够用。1.3 ESP8266上云方案AT指令还是固件二次开发ESP8266接入云端我最终选了AT指令方案。原因很简单稳定、可靠、好调试。ESP8266刷原厂AT固件STM32通过USART发AT命令控制它连接WiFi、建立TCP连接、发送MQTT消息整个流程清晰明了。你不需要在ESP8266上写复杂逻辑它就是个“无线透传模块”所有业务逻辑都集中在STM32这边。网上也有人给ESP8266刷MicroPython或者NodeMCU固件然后直接在ESP8266上写采集逻辑。这种方案适合快速原型验证但问题是ESP8266的ADC只有一个你还得外接传感器逻辑一复杂就很容易内存爆炸。更像我这种既要采集又要控制还带云交互的场景STM32AT指令是体验最好的。有朋友推荐过用ESP8266的NonOS SDK做二次开发直接在8266上写联网逻辑。这个方案性能确实更好但开发门槛高调试也费劲如果不是为了学习SDK本身我建议还是避开。后面第四章我会专门讲AT指令方式下一些容易踩的坑包括粘包、回显处理、超时判断这些。2. 硬件电路设计与搭建要点2.1 供电系统设计三路电压轨一次搞定这套系统里面有12V的直流风扇、5V的ESP8266和继电器、3.3V的STM32和传感器所以电源设计是整个硬件能不能稳定运行的关键。我用了一个12V/2A的适配器作为总输入然后做两级降压。12V到5V用AMS1117-5.0注意这玩意儿是线性稳压压差7V功耗主要是电流乘以压差。系统电流如果到300mAAMS1117上要吃掉约2W热量虽然是SOT-223封装但时间久了会烫手。所以我在输入端加了一个散热焊盘同时把5V的负载尽可能控制在合理范围——继电器和风扇都直接从12V取电不经过AMS1117这样5V轨只负载ESP8266和逻辑电路电流大约80-100mAAMS1117勉强扛得住。5V到3.3V用AMS1117-3.3这级压差只有1.7V散热压力小很多可以安心用。每路输出都加了10uF电解电容和0.1uF瓷片电容组合避免负载突变时电压跌落。这里有个非常容易被忽略的问题ESP8266是WiFi模块它瞬间发射电流能达到200-300mA如果3.3V给ESP8266供电的走线太细、电容不够WiFi一发射电压就掉表现就是掉线重启、TCP连接失败。用AMS1117-3.3单独给ESP8266供电同时靠近ESP8266的VCC引脚加一个470uF电解电容这样实测基本稳如老狗。如果是做电源板集成直接用MP1584或者LM2596这类DC-DC模块效率更高发热更小但要注意电感布局噪声稍微大一点对ADC采集有影响。2.2 传感器接口与继电器驱动电路DHT11接口很简单DATA引脚接STM32一个GPIO加上一个4.7kΩ到10kΩ的上拉电阻单总线协议时序后面细讲。接线距离超过20cm的话用屏蔽线或者尽量缩短否则读出来的湿度值容易跳变。GPY1010AU0F有6个引脚VCC和LED电源接5VLED引脚需要接一个150Ω电阻然后LED控制信号引脚接STM32的GPIO输出脉冲A0是模拟输出接STM32的ADC输入。需要注意的是V-LED引脚应该通过一个150Ω电阻接5V但我看到很多人的原理图直接把5V串150Ω就接到LED引脚上了这其实也是可以工作的但不严谨。完全按datasheet来接更稳。继电器驱动我用的ULN2003这个芯片内部达林顿管集成了续流二极管直接驱动12V继电器非常合适——如果你用三极管驱动千万别忘了那个续流二极管不然继电器断电瞬间线圈产生的反向电动势能烧掉三极管甚至打到STM32芯片上这个坑我身边不止一个朋友踩过。每个继电器线圈电流大约70mAULN2003一路能承受500mA完全没问题。还有一个值得注意的点继电器和STM32之间要有隔离最简单的方式是用光耦比如PC817或者EL357N。我用的是光耦加ULN2003的组合给继电器做隔离输入侧是3.3V逻辑接光耦二极管输出侧是12V接继电器线圈。这样一来STM32和高压侧完全隔离即使继电器出问题也不容易殃及主控板。2.3 接线与布局的实操笔记具体接线我给一套我验证过的方案照着连大概率一次成功STM32F103C8T6最小系统板PA0接DHT11的DATA。PA1接GPY1010AU0F的A0模拟输出PA2接GPY1010AU0F的LED控制引脚输出脉冲。PA9和PA10接ESP8266的RXD和TXD交叉连接注意波特率设置。继电器1控制12V排风扇继电器2控制除湿机或加热器我用的PA6和PA7输出去控制光耦输入端。OLED显示屏I2C0.96寸接PB6和PB7实时显示状态调试的时候非常方便。PCB布线的话最好把数字地和模拟地分开铺然后单点连接。GPY1010AU0F的模拟输出离开关电源的GND远一点否则ADC采样出来的数据会有很大的毛刺。我是先用杜邦线飞线调试跑通了整个系统再画PCB不然硬件问题很难跟软件问题区分开来。3. 软件架构与核心代码实现3.1 外设初始化时钟、GPIO、ADC、定时器一锅端软件我用的标准库也有HAL版但标准库是真的清晰直观功能简单场景下省事很多。整个工程按模块划分了几个文件main.c、dht11.c、dust_sensor.c、control.c、esp8266.c、oled.c、cloud.c。各模块独立封装这样调试哪个坏点一目了然。系统时钟配置为72MHzPLL倍频9倍外部8MHz晶振。这一步不懂原理的话直接照抄ST的SystemInit函数就行但记得检查RCC配置正确后主频是72MHz否则后面延时函数全部不准确。GPIO配置按功能区分PA0配置为上拉输入DHT11PA1配置为模拟输入ADCPA2配置为推挽输出粉尘传感器LED脉冲PA6和PA7推挽输出继电器USART1的PA9、PA10复用推挽I2C的PB6、PB7开漏输出加上拉。ADC用的是ADC1的通道1即PA1采样时间尽量拉长我设置的采样周期是239.5周期这样内阻高的信号源也能准确采样。定时器方面我开了TIM2做全局延时基准TIM3用来产生40kHz左右的定时中断——做粉尘传感器LED的脉冲驱动后面讲。3.2 DHT11采集时序卡不准啥都白搭DHT11是单总线协议一次完整数据传输是40bit包含湿度整数、湿度小数、温度整数、温度小数、校验和。逻辑非常吃时序主机MCU必须在微秒级别精确控制电平高低。我封装了一个读取函数核心逻辑是这样的// 简化代码重点看时序 uint8_t DHT11_Read_Bit(void) { while(GPIO_ReadInputDataBit(port, pin) SET); // 等待低电平结束 while(GPIO_ReadInputDataBit(port, pin) RESET); // 等待低电平后的高电平开始 delay_us(40); // 延时40us后判断电平 if(GPIO_ReadInputDataBit(port, pin) SET) { return 1; } else { return 0; } }细节在于DHT11在主机发送起始信号后会在总线上先拉低80us再拉高80us然后开始传输数据。每个bit是从低电平开始高电平的时间长短决定数据0还是数据1——高电平26-28us是0高电平70us是1。所以读到高电平之后延时40us再采样就能稳定区分。用示波器看波形是这个项目调试中最有效的步骤我强烈建议有条件的朋友接个逻辑分析仪不然时序问题只能靠猜效率非常低。还有一个容易忽视的坑连续两次读取DHT11之间最好间隔1秒以上因为DHT11本身的采样频率有限你读太快它内部还没更新返回的还是旧数据尤其做快速循环控制系统的时候明明传感器没坏但就是数据不变化容易误判成硬件故障。3.3 粉尘传感器采集模拟量不是简单读ADCGPY1010AU0F的输出特性决定了它不能像光敏电阻那样一直接着读。红外LED需要脉冲驱动datasheet上给的参考波形是周期10ms脉冲宽度0.32ms然后在脉冲开始后的0.28ms时刻采样输出电压。也就是说MCU要在每个周期内做两件事先输出一个0.32ms的高电平给LED控制引脚再延时0.28ms立刻读取ADC值。这个时序用软件延时可以做但精度不高。我是用TIM3定时器产生10ms中断在中断服务函数里控制PA2电平翻转同时触发一次ADC转换。读取的原始ADC值经过滤波算法后再和电压-浓度曲线做换算。换算公式建立在输出电压和粉尘浓度的线性关系上大致是浓度(μg/m³) (Vout - 0.6V) / 0.5V × 100实际每个传感器零点有差异所以我在代码里保留了一个校准偏置变量通过标定实验填进去。我这里用了一个简易中值滤波加滑动平均的双重滤波ADC原始值连续采5次取中值再对中值做滑动平均这样比单纯读一次稳得多。实际测试下来在粉尘浓度变化剧烈的时候采集曲线依然比较平滑不会出现跳变的毛刺。粉尘传感器还有一个坑是它容易被灰尘堵塞如果在粉尘浓度特别高的环境中长时间运行检测腔会积灰导致输出信号衰减。我当时给传感器进风口加了一层过滤棉定期拆下清洗实测运行一个月后输出下降了不到5%效果可以接受。3.4 控制逻辑阈值判断加迟滞防止继电器疯狂抖动控制逻辑是最能体现工程思维的地方。如果你写的判断逻辑是“湿度大于70%就开风扇小于70%就关风扇”那系统运行起来会非常频繁地开关继电器——因为湿度在阈值附近波动时风扇一开湿度下降一下降就关关了湿度又回升于是又开。继电器频繁吸合触点寿命会急剧缩短。我设计的是迟滞控制湿度 ≥ 75%RH开启排风扇、除湿机湿度 ≤ 65%RH关闭排风扇、除湿机温度 ≥ 35°C开启排风扇散热温度 ≤ 30°C关闭排风扇散热粉尘浓度 ≥ 150μg/m³开启排风扇通风粉尘浓度 ≤ 100μg/m³关闭排风扇通风这个75%和65%之间、35°C和30°C之间的差值就是“迟滞带”它能让执行机构在阈值附近变“迟钝”避免反复开关。每个阈值我都预留了修改宏定义方便根据不同仓库的实际需求调整。控制周期我做了个1秒的扫描循环每1秒采集一次并刷新比较给执行机构足够的时间响应又不会太频繁地做判断。实际跑下来这套控制逻辑最大的好处是继电器动作次数大幅减少。我之前做过一个不做迟滞的版本运行一天继电器动作超过300次加了迟滞之后一天不到30次触点和执行机构寿命都能明显延长。另外我还在控制逻辑里加了保护机制——如果排风扇连续运行超过2小时系统会自动暂停10分钟这叫“循环保护”主要是防止风机长时间运行过热。3.5 ESP8266 AT指令联网初始化序列与粘包处理ESP8266通过AT指令跟STM32通信波特率我统一设置为115200。模块上电后STM32要先做一套“标准动作”关闭回显ATE0、设置Station模式ATCWMODE1、连接WiFiATCWJAPSSID,PASSWORD、开启透传模式ATCIPMUX0ATCIPMODE1然后才能建TCP连接或者MQTT连接。提示AT指令每一条发完一定要等模块返回“OK”或者“ERROR”再去发下一条。很多人栽在这上面——模块还没处理好上一条指令就发了下一条结果模块直接返回乱码。我写了一个带超时等待的函数最多等5秒超过就重发重发3次还失败就记录错误并重启模块。粘包问题也要提前处理。ESP8266在透传模式下云端返回数据可能一次来一大段也可能分几次来。我的接收解析用了环形缓冲区加状态机每次USART中断只塞进缓冲区主循环再解析完整数据帧。如果你用简单的“收到一个字节就处理一个字节”在MQTT大量数据交互的时候很大概率丢包或者解析错位。3.6 上云接入巴法云MQTT发布订阅一次打通我用的云平台是巴法云理由就三个免费、免备案、接入文档简单。MQTT协议在这套方案里的角色是发布订阅STM32通过ESP8266作为客户端连到云端发布主题里带传感器数据订阅主题接收控制指令。MQTT协议在STM32上的实现网上有很多移植好的MQTT库比如paho MQTT嵌入式C库可以在STM32上跑。但我为了降低复杂度直接用AT指令调用ESP8266内置的MQTT透传能力只要把云平台地址、端口、client ID、username、password这些参数按AT指令格式发给ESP8266模块自己就完成了MQTT协议交互。我这边只做了两件事一是按固定格式拼数据串二是解析云端下发到订阅主题里的控制命令。实测数据上报频率设为每10秒一次云端能稳定收到数据没有出现掉线断连的情况。数据格式我用的是JSON比如{temp:26.3,hum:68.5,pm25:45.2}。巴法云控制台会自动解析展示不用自己再去写后台和数据可视化面板。想扩展的话还可以在巴法云设置告警规则比如温度超过阈值就推送消息到手机。我给数据上报设计了一种带序号的数据帧结构方便排查丢包问题每帧数据里加一个自增序号通过比对云端连续收到的序号就能知道有没有漏报。同时做了一个心跳机制每60秒发一个短消息如果云端超过3次心跳没收到就判定这条链路有问题触发本地重启WiFi模块重连。4. 常见问题与排查技巧实录4.1 DHT11数据老是读不出来怎么定位时序问题这应该是最多人卡住的地方。DHT11读取失败不外乎三个原因上下拉电阻没接、延时函数不准、读取间隔太短。我的排查顺序是先用逻辑分析仪抓DHT11引脚的波形如果波形只有一簇密集的脉冲说明DHT11根本没应答主机——大概率是起始信号时序不对或者上拉电阻忘接了。如果是波形就像一片毛刺电平翻转时间完全是乱的多半是MCU主频配置错了延时函数因此全部失真。我自己踩过最大的坑是用软件延时函数算错指令周期。标准库环境下一个简单的循环嵌套延时容易因为编译器优化导致时间完全不等所以我后来统一改用SysTick做延时用定时器来计时这样延时精度才能有保障。网上很多帖子的软件延时函数是拿旧版编译器测试出来的你自己换了个编译器之后可能就完全不对了。解决方法是给DHT11读取函数加超时保护如果40bit数据在某个bit上等了超过200us还没翻转就直接判定失败返回错误码主循环里做重试。这样系统不会死等一个传感器卡住整个控制流程。4.2 粉尘传感器读数一直偏高或跳变怎么办粉尘传感器输出飘高或者乱跳先排除电源质量问题。我的测试经验是如果供电纹波大ADC读出来的粉尘浓度会整体偏高且波动剧烈。用示波器看AMS1117-3.3的输出纹波超过50mV就需要加滤波电容或者改DC-DC方案。零点漂移是另一个常见问题。GPY1010AU0F在无尘环境下输出电压理论上是0.6V左右实际会有偏差。我系统里做了一个校准流程开机后先让传感器运行5分钟预热然后采100次数据取均值作为零点偏置之后每次换算都减掉这个偏置值。这个做法简单实用比手动填一个固定偏置强得多。另外脉冲采样的时序直接影响数值。LED脉冲的周期和宽度必须严格按datasheet来我遇到过用普通delay写的采样函数采样时刻从0.28ms漂到0.2ms读数直接少了近一半。如果发现数值整体偏小先检查采样点是否准了。4.3 ESP8266连不上云平台或频繁掉线连不上云平台先做分步排查先看ESP8266是否连上路由器ATCWJAP?查询状态再检查TCP/MQTT端口和地址是否填对最后看云端账号密码是否有问题。很多人卡在这一步其实是云平台里的用户私钥和密码填反了或者topic拼写错误导致订阅不到消息。频繁掉线我遇到最多的是供电问题。ESP8266发射瞬间电流大如果3.3V电源拉胯就会在发射时电压跌落模块自动复位。这个在2.1节已经重点讲过了再强调一次去耦电容必须靠近模块引脚。还有就是WiFi信号问题如果ESP8266离路由器太远或者隔着货架金属信号弱会导致TCP超时掉线。我用了一个简单的心跳保活机制如果连续5次心跳无响应就重启ESP8266重新初始化实测可靠性提升明显。AT指令粘包问题在调试助手端也会出现。有些AT指令返回结果是多行的比如ATCWJAP连接成功后会有“WIFI CONNECTED”、“WIFI GOT IP”如果程序里用一条strstr去匹配“OK”就可能被中间多出来的字符串搞混。正确做法是匹配关键状态字段比如“WIFI GOT IP”才算连上了WiFi。4.4 继电器频繁吸合或者动作不响应继电器不动作大概率是驱动电路问题用万用表测ULN2003输出端是否拉低。如果输入有控制信号但输出不拉低检查光耦输入端电流够不够3.3V串联限流电阻阻值是否太大导致LED电流过小。我之前遇到过一次输出端加继电器负载后完全没反应查了半天原因是ULN2003输入端的限流电阻选太大输入电流只有不到2mA达林顿管没有完全导通。继电器频繁吸合是迟滞没做好这个在3.4节已经讲过。如果加了迟滞还是频繁动作可能是传感器数据的噪声太大导致阈值比较时频繁跨越边界。解决办法是加滤波对湿度、温度、粉尘浓度三个数据都做一阶低通滤波比如新值 上次值 × 0.7 本次值 × 0.3。这样即使原始数据有波动进入判决逻辑的数据依然平滑继电器自然安静了。4.5 数据上报到云端但控制指令下发的实时性不够有一次我在测试中发现数据能稳定上报但从云端下发控制指令到系统执行延迟总在5秒以上。排查后发现不是网络问题而是我的STM32只监听了ESP8266透传数据但主循环里串口解析的优先级太低被其他任务拖住了。我把串口数据解析放进了一个独立状态机并且在下发控制指令时使用高优先级串口中断打断当前循环延迟立刻降到了1秒以内。实话说这套系统做完之后我自己有个很深的感受最花时间的往往是那些“理论之外”的细节比如一个上拉电阻的位置、一个滤波参数的调整、一次供电纹波的排查。把这些问题逐一解决掉整套系统才真正从“能跑”变成了“稳定跑”。另外提一句这套系统后续我觉得还可以往两个方向扩展一是把所有传感器换成RS485总线版本比如Modbus RTU协议这样就可以接更远的点位实现仓库多点位分布式监测一台主机带几十个传感器子节点二是加4G模块作为备选通信链路因为仓库里WiFi信号毕竟不是随时都有保障。如果你正准备做类似的毕设或者实际改造建议从一开始就留好这两个接口的扩展位。