做仓库环境控制这个项目起因是朋友托我帮他解决一个实际问题库房里的纸质包装和金属件一到梅雨季节就受潮墙面返潮、纸箱发软偶尔还能看到细小的粉尘聚集在设备散热风扇附近。市面上成品的“仓库环境监控系统”要么贵要么根本不让改逻辑。想了想干脆自己用 STM32 搭一套既能实时监测温湿度和粉尘浓度又能根据阈值自动启动风机通风除湿顺手通过 ESP8266 把数据送上云端手机随时能看。这个方案不是实验室里的玩具而是真正可以放到库房里连续运行的控制系统尤其适合正在做嵌入式毕业设计、或者想给自家仓库/车间做环境改造的工程师参考。先说一点感受这类项目看似只是“传感器采集 继电器控制 网络上传”三板斧但真正做完你会发现坑几乎都藏在细节里——粉尘传感器的驱动时序、ESP8266 的 MQTT 报文构造、继电器频繁吸合导致的寿命问题、以及云平台和设备之间的心跳保活。这篇文章会把从选型到调参的完整过程都梳理出来附上实测数据和踩坑记录照着做基本能少走一半弯路。1. 整体方案设计与核心思路1.1 系统架构与功能拆解这套系统从功能上可以拆成四条链路传感采集、主控决策、执行输出、云端上报。传感采集由温湿度传感器和粉尘传感器组成。温湿度负责监测空气状态粉尘负责监测空气中颗粒物浓度这两个数据是后续通风、除湿逻辑的输入源。主控决策由 STM32 完成它读取传感器数据经过换算、滤波和阈值判断后决定是否开启风机。执行输出通过继电器控制交流风机或排气扇实现通风、排尘和除湿。云端上报由 ESP8266 承担它将温湿度、粉尘浓度和设备状态打包成 JSON 数据通过 MQTT 协议上报到云平台。数据流大致是传感器 → STM32 ADC/GPIO 采集 → 数据处理 → 本地显示 继电器输出 → UART 发给 ESP8266 → WiFi 上云。整套系统硬件结构很紧凑STM32 最小系统板一块、DHT22 一个、GP2Y1010 粉尘传感器一个、ESP8266-01S 一个、2 路继电器模块一个、OLED 显示屏一个再加一个 12V 转 5V 的 DC-DC 电源模块给传感器和 ESP8266 供电风机直接接 220V 交流电通过继电器通断控制。功能上除了自动控制还预留了一个手动模式——通过按键切换成人工开关风机。这个设计在调试阶段非常有用因为纯自动模式一旦传感器读数异常你很难判断是传感器的问题还是继电器的问题切到手动模式直接按按键就能验证执行机构是否正常。1.2 关键器件选型与取舍理由主控选了 STM32F103C8T6这是最经典的 STM32 芯片32 位 ARM Cortex-M3 内核72MHz 主频64KB Flash20KB SRAM。做这个项目的资源占用大概只用了三分之一余量很足。选它的核心原因有三个一是资料极其丰富无论你卡在哪一步几乎都能搜到现成案例二是标准库和 HAL 库都被验证过无数次稳定三是价格低一片几块钱一个最小系统板也就十几块。同级别的替代品还有 GD32F103 和 APM32F103管脚基本兼容代码可以直接烧但没必要冒险原厂芯片最省心。温湿度传感器是 DHT22也叫 AM2302精度为温度 ±0.5°C湿度 ±2% RH测量范围能覆盖仓库环境的绝大多数场景。DHT11 虽然更便宜但湿度精度只有 ±5% RH在控制逻辑里很容易导致“该除湿的时候测出来湿度不够不该除湿的时候又超过阈值”这种误判。如果你只是做室内简单测量DHT11 也能用但做自动控制传感器读数的稳定性直接决定系统的可靠性所以我宁可多花几块钱上 DHT22。粉尘传感器用夏普 GP2Y1010AU0F这是一颗光学式粉尘传感器利用红外 LED 照射空气中的颗粒物通过光电二极管接收散射光输出与粉尘浓度成正比的模拟电压。它的成本低、功耗小、外围电路简单适合嵌入到这种离线控制场景。缺点是需要 PWM 脉冲驱动 LED而且输出特性受颗粒物成分影响。相比之下攀藤 PMS5003 是激光散射式精度更高、能输出 PM2.5/PM10 数值但价格是 GP2Y1010 的三四倍而且功耗和体积都大。仓库环境监测不需要实验室级精度GP2Y1010 够用了。ESP8266-01S 负责联网。这颗模块虽然只有 8 个引脚但通过串口 AT 指令就能完成 WiFi 连接和 MQTT 通信对 STM32 侧来说就是一个“透明传输管道”主控唯一要做的就是在 UART 上按格式发指令、收响应。选它还有一个原因功耗比 ESP32 低对仓库这种常年通电的场景更友好而且 AT 固件非常成熟发 ATRST 就能恢复默认配置调试起来几乎没有门槛。继电器选的是 2 路 5V 低电平触发模块。这里要特别说明市面上大多数继电器模块都是“低电平触发”即 IO 引脚输出低电平时继电器吸合。原因在于模块内部的光耦隔离电路设计输入侧低电平导通而不是很多人直觉认为的“高电平触发”。接线前务必看模块背面的跳线说明否则控制逻辑会跟你想的完全相反。1.3 为什么选择这种方案对比纯物联网方案比如直接用 ESP8266 接 DHT22这套系统坚持把核心控制和传感器采集放在 STM32 上并不是多此一举。主要考量是可靠性和解耦。ST 芯片的 GPIO 电平、ADC 参考电压、定时器精度都更可控而且在断电重启后STM32 的启动速度远快于 ESP8266 的 WiFi 重新连接时间。换句话说就算 WiFi 暂时断开本地控制逻辑还能正常工作通风除湿不会因为网络问题而罢工。另一个考虑是扩展性。仓库环境控制不只是温湿度和粉尘后面如果还要接烟雾报警、红外入侵检测、甚至多个仓库节点组网STM32 的外设资源只要规划好都能轻松扩展。ESP8266 的方案适合单点传感器快速上云但要做本地联动控制还是需要一个像 STM32 这样的主控来承载逻辑。2. 硬件接线与核心细节解析2.1 电源分配与最小系统搭建硬件如果只追求“能跑”随便飞线都能跑但要做到“稳定跑一个月”电源分配才是最值得花心思的地方。这套系统的电源分两条路径12V 输入经 DC-DC 降压到 5V供 DHT22、GP2Y1010、ESP8266、OLED 和继电器模块的输入侧STM32 最小系统板上有 AMS1117-3.3直接从 5V 降压得到 3.3V给主控芯片本身供电。需要注意的是ESP8266 在 WiFi 发射瞬间的电流尖峰能达到 300mA 左右如果和模拟传感器共用一个 LDO可能会把 3.3V 电压拉出毛刺影响 ADC 采样精度。所以 ESP8266 的电源必须直接从 5V 通过独立的 AMS1117-3.3 给不能和 STM32 的供电共用同一个 3.3V 输出。粉尘传感器的 LED 驱动也需要 5V 供电它的 V-LED 引脚要接一个限流电阻典型 150Ω再接到 IO 口因为内部 LED 正向电流约 20mA不能直连 3.3V 的 GPIO。模拟输出引脚 V0 输出范围是 0.9V 到 3.6V 左右直接进 STM32 的 ADC 引脚理论上没问题但稳妥起见还是串一个 1kΩ 电阻再加一个 0.1μF 滤波电容防止高频噪声影响采样。接线顺序也有讲究先把 GND 全部连通再接电源最后接信号线。很多新手的系统不稳定不是器件坏了而是地线回路没接好导致传感器参考电位漂移。另外继电器模块的 JD-VCC 跳线帽如果是接上的意味着继电器线圈电源直接取自模块的 VCC 输入这时候 5V 侧的地会和 220V 侧通过光耦隔离但如果跳线帽拔掉、外接独立电源隔离效果更好。做仓库这种长期运行项目建议直接拔掉跳线帽外接 5V 给继电器线圈。2.2 DHT22 单总线时序与读取要点DHT22 使用单总线协议一根数据线既传输数据又提供通信时序所以 STM32 读取它的时候GPIO 需要反复切换输入输出方向。这里用到的三个核心数据格式是主机起始信号拉低至少 1ms然后释放、传感器响应信号拉低 80μs 然后拉高 80μs、以及 40 位数据帧湿度高 8 位、湿度低 8 位、温度高 8 位、温度低 8 位、校验和 8 位。实际编码中每一位的“0”和“1”是靠高电平持续时间区分的——26~28μs 的高电平表示 070μs 左右的高电平表示 1。这个时序用 STM32 的定时器输入捕获来做最稳但用 delay 延时配合 GPIO 读取也完全可行前提是中断别来打扰。很多人在读取的时候遇上定时器中断导致时序被拉伸或压缩读出来的数据就全是 0xFF。解决办法是读取传感器时序的这段代码放在临界区或者用一个专门的定时器期间屏蔽其他中断。校验逻辑务必写上四个字节相加取低 8 位如果和校验字节不一致这一帧直接丢弃。丢弃后不要立刻重读要至少间隔 1 秒。DHT22 本身采样周期最长 2 秒读取太频繁反而拿不到新数据。2.3 GP2Y1010 粉尘传感器的 PWM 驱动与 ADC 采样GP2Y1010 的驱动方式很容易踩坑。它内部的红外 LED 不是常亮的而是需要通过 IO 口输出脉冲方波点亮脉冲周期 10ms高电平脉宽 0.32ms。在 LED 点亮后的 0.28ms 左右光电二极管的输出达到峰值这时候 ADC 采样才能得到与粉尘浓度相关的电压。采样点太早或者太晚读出来的电压都会严重偏低。我在项目里用 STM32 的定时器输出 PWM频率固定 100Hz占空比 3.2% 左右正好满足 10ms 周期、0.32ms 脉宽的要求。然后在一个 ADC 采样完成中断里通过定时器比较寄存器判断当前 PWM 输出状态等到脉宽达到 0.28ms 时触发 ADC 转换。这样实现的采样窗口精度可以控制在微秒级。到这一步就需要注意换算公式了GP2Y1010 的输出电压和粉尘浓度近似线性关系典型公式是浓度μg/m³ (Vout - 0.6) × 1000具体系数因传感器个体差异略有不同。当然这个公式只是估算粉尘成分不同、温度不同都会有偏差。如果需要准确数值建议找一个标准粉尘源做单点标定反向修正公式的斜率和截距。对自动控制来说更重要的是浓度的变化趋势而不是绝对精度所以只要确保传感器在粉尘超过阈值时输出电压有明显抬升控制逻辑就不会出错。ADC 配置也别偷懒STM32F103 的 ADC 是 12 位参考电压接 VREF 也就是 3.3V所以 ADC 读数除以 4095 再乘以 3.3V 就是实际电压。如果传感器输出经过分压或滤波记得在代码里反向补偿不然浓度换算会偏。2.4 继电器驱动与风机安全控制控制风机这类交流负载安全第一。STM32 的 GPIO 输出电流最大只有 20mA 左右直接驱动继电器线圈不够所以必须通过继电器模块上的三极管或光耦做电流放大。低电平触发意味着 GPIO 输出低电平时三极管导通继电器线圈得电吸合触点闭合后风机启动。自动控制逻辑里也要加保护风机启动和停止之间要设置一个最小间隔不要因为传感器数据抖动导致继电器在几秒内频繁吸合。继电器机械寿命一般标称 10 万次听起来很多但如果系统每秒判断一次、反复触发开和关几天就能把一个继电器折腾坏。这个问题在第 3 章控制策略里有专门解决方案。3. 下位机软件实现与控制逻辑3.1 工程结构与任务调度整个下位机程序用了标准库开发结构上分三层驱动层、逻辑层、应用层。驱动层封装了 DHT22_Read()、GP2Y1010_Read()、ESP8266_UART_Send() 这些基础函数逻辑层实现数据滤波、阈值判断、风机控制状态机应用层是主循环和定时器回调负责把各模块串起来。任务调度用了一个 100ms 的 SysTick 时基主循环里按时间片轮询每 1 秒读一次温湿度每 2 秒读一次粉尘浓度每 5 秒刷新一次 OLED每 10 秒向 ESP8266 发送一次上云数据。这样设计的好处是各个任务的执行频率不互相干扰也不会因为某一项任务阻塞时间过长导致其他任务卡死。代码里要注意一个经典坑DHT22 读取一次的阻塞时间接近 5ms如果这 5ms 正好碰上 UART 接收数据尾字节串口中断的接收缓冲可能溢出。解决方法是把 UART 接收改用 DMA 空闲中断或者把 DHT22 的读取放在主循环的一个专用标志位里保证读传感器的同时绝对不碰串口。3.2 阈值加回差的自动通风除湿策略自动控制逻辑是本系统的核心不能只做简单的“湿度大于 70% 就开风机小于 70% 就关风机”。原因很好理解传感器总有一点噪声如果阈值设在 70%实际值在 69.5% 和 70.5% 之间抖动继电器就会在开和关之间反复切换既伤继电器也造成风机频繁启停。解决办法是引入回差机制。我设定两组阈值湿度开风机的阈值是 70%关风机的阈值是 65%粉尘浓度开风机的阈值是 150μg/m³关风机的阈值是 100μg/m³。也就是说当湿度升到 70% 以上时启动除湿要等湿度回落到 65% 以下才停止粉尘浓度升到 150 以上时启动排尘要等浓度降到 100 以下才停止。这中间 5 个点的差值就是回差它把继电器的动作次数从“每分钟好几次”降到“每小时几次”。风机控制的优先级上我设计成“粉尘优先级高于湿度”。原因很直接粉尘含量高的时候必须先排尘否则灰尘会附着在货物表面而除湿需要的空气流动反而可能把沉积的灰尘重新扬起来。所以状态机里有三个状态正常、排尘、除湿。任何一个状态满足关闭条件都会先检查另一个指标是否还需要动作再决定是否完全停机。3.3 粉尘浓度数据滤波处理GP2Y1010 这类光学传感器的输出噪声不小尤其在风机启动之后气流扰动会让读数跳变。如果直接拿原始值做阈值判断误报率会很高。我用的是一阶低通滤波公式是当前滤波值 上次滤波值 × 0.7 当前原始值 × 0.3。这个系数换算成时间常数大约是几秒既能跟得上浓度突变又能抑制短时尖峰。相比之下滑动平均滤波我也试过窗口取 10 个点效果类似但要额外维护一个数组代码复杂度更高。在仓库这种低频变化的环境里一阶低通已经足够而且参数调整特别直观想让系统反应更灵敏就增大原始值权重想让读数更平滑就减小。有一点要提醒滤波后的数据会比真实值滞后。做阈值判断的时候宁可滞后两秒也不要让风机因为一个异常尖峰误启动。所以滤波系数偏保守是更安全的选择。3.4 本地显示与手动模式OLED 显示用的是 0.96 寸 I2C 接口四根线VCC、GND、SCL、SDA。在主循环里每 5 秒刷新一帧数据显示当前温度、湿度、粉尘浓度和风机状态。I2C 通信速率设成 400kHz 就行不要太高因为 OLED 控制器SSD1306对时序的兼容性中规中矩太快反而容易花屏。手动模式是通过按键切换的短按按键在自动/手动之间切换长按按键直接开关风机。这个功能我在调试阶段帮了大忙——最初自动模式频繁误触发的时候靠手动模式验证了继电器和风机本身没问题这才锁定到传感器数据抖动上。这个经验在后面问题排查里还会再提。4. ESP8266 上云与数据链路4.1 ESP8266 AT 指令初始化流程ESP8266 的 AT 固件版本不同指令集有差异。拿到模块后第一件事是发 ATGMR 看固件版本推荐 2.x 版本以上的 AT 固件因为它原生支持 MQTT 指令省去自己透传组包的麻烦。初始化过程分四步测试 AT 通信、设置 WiFi 模式、连接路由器、配置 MQTT 参数。对应的指令如下串口波特率默认 115200AT ATCWMODE1 ATCWJAP你的WiFi名,你的WiFi密码每条指令发送后要等待返回 OK 或 ERROR。这里有一个容易卡死的地方ATCWJAP 连接路由器可能需要 5~10 秒期间模块不响应任何其他指令如果你的代码在发完指令后立刻死等 OK就可能超时。所以连接 WiFi 的指令要单独设置一个较长超时比如 15 秒然后循环轮询串口接收缓冲直到收到 OK 或者 WIFI CONNECTED 关键字。由于我踩过这个坑太多次这里单独说一下不要用那种“发一条指令然后 while 循环里不停发 AT 等 OK”的老写法。正确做法是发完指令后用状态机记录当前等待哪个指令的响应收到响应后再切换状态。这样即使某条指令没响应也能通过看门狗复位来恢复不会让整个系统陷入死循环。4.2 通过 MQTT 接入云平台的具体配置上云平台用的是国内常用的 OneNET 物联网平台免费额度足够个人项目测试。在平台侧需要先创建产品然后在产品下创建设备拿到三组凭证产品 IDProductID、设备名称DeviceName、设备密钥DeviceSecret。这三组数据相当于设备的身份证MQTT 连接时用来做身份认证。新固件的 AT 指令配置方式很清晰ATMQTTUSERCFG0,1,clientId,username,password,0,0, ATMQTTCONN0,mqtt.heclouds.com,1883,1MQTTUSERCFG 的第二参数 1 表示使能 MQTT 功能clientId 填设备名称username 填产品 IDpassword 填设备密钥不同平台规则略有差异以官方接入文档为准。MQTTCONN 的最后一个参数 1 表示开启干净会话这样模块重连的时候不会保存旧的订阅关系避免消息堆积。连接成功后上报数据用 ATMQTTPUBATMQTTPUB0,$dp,1,0,{\temp\:26.5,\humi\:62.3,\pm\:128,\fan\:1}这里的主题是平台默认的数据上报主题payload 是 JSON 格式。1 表示 QoS 级别为 1平台收到数据后会回 ACK0 表示非保留消息。QoS 选 1 是因为仓库这种场景不追求极低延迟但要求数据不能丢。4.3 数据格式约定与心跳保活上云数据的格式我定成了一个 JSON 对象包含四个字段温度 temp、湿度 humi、粉尘浓度 pm、风机状态 fan。为了方便在手机端查看趋势还额外加了一个时间戳字段 ts。时间戳由 STM32 侧维持一个 RTC用 DS3231 模块或者直接用内部 RTC 都行因为 ESP8266 本身不做时间同步云端如果收到带时间戳的数据绘图会方便很多。MQTT 的心跳保活是另一个关键点。ATMQTTCONN 指令里默认的 keepalive 时间是 120 秒也就是说如果 120 秒内没有任何数据收发模块会自动发送 PINGREQ 报文维持连接。我的设计里每 10 秒上报一次数据心跳自然不是问题。如果未来数据上报间隔改成 5 分钟甚至更长一定要把 keepalive 参数调大或者单独发送 PING不然云平台会判定设备离线重新连接又要经历完整的 TCPMQTT 握手过程。WiFi 断线自动重连的方案也值得提前做好ESP8266 的 AT 固件支持 ATCWAUTOCONN1模块上电自动连接上次的路由器。但如果在运行中断线需要在 STM32 侧定时检查 ESP8266 的 WiFi 状态一旦检测到断开就重新执行 ATCWJAP 连接。这个检查我用的是 ATCWJAP? 查询指令每 30 秒查一次不额外占太多串口资源。5. 实测数据与效果分析5.1 连续运行监测记录系统搭好后在朋友的仓库里连续运行了 72 小时采集到一组比较有代表性的数据。仓库面积约 200 平方米大门朝西下午有两个小时左右光照会照进来仓库货物主要是纸箱包装的五金件和少量电子料。实测数据如下取每天几个关键时间点时间温度(°C)湿度(%RH)粉尘(μg/m³)风机状态第1天 08:0024.368.287关第1天 14:3029.171.5132开除湿第1天 19:2026.863.498关第2天 09:1025.673.8115开除湿第2天 15:4028.769.1176开排尘第3天 10:3026.266.9108关从数据看系统运行是符合预期的。第一天下午湿度突破 70% 后启动除湿风机运行大约 2 小时间歇动作把湿度拉回 65% 以下。第二天下午粉尘浓度有明显上升推测是隔壁车间在抛光作业排尘逻辑及时响应。第三天整体指标稳定在阈值以内风机没有误动作。5.2 上报数据与本地数据一致性这套系统同时具备本地显示和云端上报所以顺带验证了 ESP8266 传输的数据有没有丢失或乱码。用手机端云平台查看历史数据和 OLED 上本地显示的数据对比72 小时一共上报了大约 25000 条数据没有丢包也没有出现一条乱码记录。这里要表扬一下 QoS 1 级别的 MQTT 消息可靠性。理论上 QoS 0 可能会因为 WiFi 瞬时波动丢几条QoS 1 会在模块和平台之间做确认重传实际体验确实更稳。代价是模块的 Flash 写入稍微频繁一些但 ESP8266-01S 的 Flash 寿命在这个数据量下可以忽略不计。5.3 功耗与稳定性小结整套系统常年通电的运行功耗实测大约是 1.8WSTM32 传感器 ESP8266 待机风机启动时额外增加约 80W以 220V 排气扇计算。风机不会一直转每天累计运行时间约 3~4 小时一个月的电费成本可以忽略。稳定性方面72 小时连续运行期间STM32 看门狗没有触发复位ESP8266 只断线重连过一次发生在路由器凌晨自动重启时整体可靠性达到预期。如果需要在无人值守环境下长时间运行建议供电端加一个 UPS 或者至少用带断电恢复功能的电源模块避免突然断电导致传感器状态异常。6. 常见问题排查与避坑经验6.1 高频故障速查表做这类项目最耗时间的不是写代码而是排查各种“看起来莫名其妙的故障”。我把实际遇到和同事反馈过的典型问题整理成一个速查表方便索引。症状可能原因排查步骤与解决办法温湿度读数一直为 0xFF 或 0DHT22 时序被中断干扰 / 接线错误检查数据线是否接对引脚读取时序段屏蔽其他中断确认上拉电阻 4.7kΩ 已接粉尘浓度读数永远接近 0V-LED 没有收到 PWM 脉冲 / LED 引脚悬空用示波器或万用表检查 IO 口是否输出 0.32ms 脉冲确认 V-LED 串了 150Ω 限流电阻继电器一开机就频繁吸合阈值回差设置太小 / 传感器数据毛刺增大回差到 5% 以上接一阶低通滤波检查 ADC 采样是否取了滤波后的值ESP8266 发送 AT 无响应串口波特率不匹配 / 模块没进入 AT 模式重新上电确认 STM32 和 ESP8266 的波特率一致推荐 115200检查 GPIO0/CH_PD 引脚电平数据能上报但云端很久不更新心跳保活超时 / WiFi 断线未重连检查 keepalive 参数确认开启 CWAUTOCONN在 STM32 侧加定时 WiFi 状态查询OLED 显示花屏I2C 速率过高 / 电源纹波大降低 I2C 到 400kHz 以下在 OLED 的 VCC 和 GND 之间加 10μF 电解电容湿度超过 90% 但读数一直卡住不变化DHT22 传感器老化或受潮更换传感器检查数据线是否氧化仓库潮湿环境容易导致接触不良6.2 几个印象深刻的排查经历第一个值得说的是 ESP8266 恢复出厂设置后进入死循环的问题。有次调试时发 ATRESTORE然后代码里立刻用 while 循环轮询串口等“OK”结果模块复位后重新启动要很长时间而且重启后 AT 响应波特率可能恢复到默认的 115200如果和 STM32 侧波特率配置不一致就会永远等不到这个“OK”。正确做法是发完恢复指令后直接延时 3~5 秒然后重新发送 AT 初始化序列不能有“连续等待”的心态。第二个是 GP2Y1010 的采样时间窗口问题。最初我把 ADC 采样放在 PWM 中断里立刻读取发现浓度读数只有真实值的五分之一左右。查了数据手册才发现传感器内部光电二极管的响应需要时间LED 点亮后 0.28ms 左右才是信号峰值采样太早相当于在信号还没建立起来的时候拍了一张照片。后来改成延时到 0.28ms 再转换读数立刻正常。这个点如果只靠网上流传的示例代码很难意识到但在实际项目中影响非常大。第三个是继电器误动作问题。第一版代码没有做回差只用单一阈值判断结果那天仓库里有人在门口扫地粉尘瞬间飙升到 200风机启动等粉尘回落到 90 的时候又是粉尘阈值又启动一次。一天下来继电器动作了 30 多次听起来不算多但一个月下来就是上千次传感器的数据只要稍微抖一下继电器就容易“跳开关”。这个问题在加了一阶低通滤波和 5% 回差之后就彻底解决了继电器一天动作次数降到个位数。还有一个关于上云的小技巧如果用的是便宜的 ESP8266-01S注意它只有 1MB FlashAT 固件升级到最新版本会占用大量空间导致 OTA 升级空间不足。所以量产或长期运行阶段固定一个稳定版本的 AT 固件不要频繁升级。模块在仓库环境里工作温度高、湿度大放置的时候尽量远离风机出风口否则震动和热量会加速模块老化。最后说一点我对这个项目后续扩展的想法。当前这套系统只监测了温湿度和粉尘如果要进一步升级可以在同一块 STM32 上增加烟雾传感器和声光报警器实现火警联动或者把单台设备改成 Modbus 总线连接多个从站节点实现多仓库集中管理。ESP8266 也可以升级成 ESP32局域网内直接用 ESP-NOW 通信这样即便外网断了设备之间依然能协同工作。本文这套“STM32 主控 ESP8266 上云”的架构本质上是一个可复用的框架后面换传感器、换执行器都只是改驱动层核心逻辑不用动。