1. 先拆需求：这套仓库环境控制系统到底要做什么
前段时间帮一个朋友的物料仓库做了一套环境控制系统。仓库不大，但堆放的全是怕潮怕尘的电子元件和纸质包装，前阵子因为返潮，一批货直接报废，损失够买好几套自动化设备了。当时他找我的需求很简单：把温湿度盯住，粉尘浓度盯住，该通风通风、该除湿除湿，人不用天天跑现场，手机上能看到实时数据就好。
选型几乎没有悬念——STM32做主控、ESP8266上云，这是同类项目里最经典、资料最多、性价比也最高的组合。做完之后我发现，这套系统的价值不只是"能测能控"，而是把监测、控制、远程感知三条链路串成了一个闭环。文章主要写给正在做类似毕设、课程设计，或者想给自己仓库、地下室、机房做环境改造的朋友；如果你已经能点灯、会串口收发，那整篇内容可以直接照着抄。
1.1 三个核心能力：测得到、控得住、看得见
拆开标题看，这个系统本质上是三件事。
第一是"测"。仓库环境里最影响物品状态的就是温湿度和粉尘。温度高了加速老化，湿度高了直接发霉短路，粉尘浓度过高，轻则影响设备散热，重则存在安全隐患。所以监测模块要有温湿度传感器和粉尘传感器，采集频率不需要太高，几秒一次完全够用。
第二是"控"。光有数据没有动作，那只是个高级温度计。系统的价值在于自动联动：温度超了开风扇，湿度超了开除湿机，粉尘浓度超了启动排风。这个环节的核心不是"能不能开"——继电器控制风扇开关非常容易——而是"什么时候开、什么时候关、怎么避免频繁启停"。我在后面专门讲回差控制，这是整个项目里最容易被忽视但最重要的逻辑。
第三是"上云"。仓库一般不是常驻人的地方，跑一趟成本很高。通过ESP8266把数据传到云平台，手机端就能看实时温湿度、历史曲线，配合平台的推送功能还能做超阈值报警。这是整个项目最能体现"物联网"价值的部分，也是答辩时最好讲清楚的部分。
1.2 仓库场景的特殊性：为什么不能直接拿温度计凑合
有人会问，我买个带WiFi的温湿度计插在仓库里不行吗？还真不行。一是普通温湿度计没有控制输出，不能驱动风机和除湿机；二是粉尘监测比温湿度麻烦得多，几十块的检测仪没法把数据开放出来给单片机用；三是你需要的是一套"可编程、可改逻辑"的系统，而不是厂家写死的APP。STM32的价值就在这里——你想让它在湿度超过70%时同时打开两台风机，或者在粉尘超标且温度低于5℃时只开加热不开排风，这些规则都能自己改。
另外，仓库这种场景对稳定性要求比较高。无人值守意味着出了问题不会有人第一时间发现，所以系统要能"自我恢复"。我在主程序里加了独立看门狗，万一程序跑飞，自动复位重启，而不是死在那里等着人去断电。这在普通桌面实验里无所谓，但在工程项目里是基本要求。
1.3 功能分层与资源规划：先保证闭环，再谈体验
我给自己的规划分了三个优先级：
- 第一优先级：实时采集温湿度、粉尘浓度，本地串口或OLED显示；继电器控制通风、除湿；阈值自动启停。
- 第二优先级：ESP8266联网上云，云端查看数据。
- 第三优先级：报警推送、历史记录、多节点组网、控制策略远程下发。
做项目最忌讳一上来就把功能堆满。我的建议顺序是：先把采集和控制跑通，形成本地闭环；再上云；最后折腾报警和远程控制。STM32F103C8T6的资源（64KB Flash、20KB RAM、3个UART、2个ADC）做这个项目绰绰有余，但如果你同时想接LCD屏幕、多个传感器、多个ESP8266，就要重新算IO和中断资源了。我下面给的IO分配表，就是基于"C8T6最小系统板 + 一个ESP8266 + 两路继电器 + 两个传感器"这个典型配置来的。
2. 硬件选型与接线：模块怎么挑、引脚怎么分、电源怎么处理
硬件选型是整个项目的地基。很多同学喜欢追新传感器，但实际上仓库环境控制这种场景，技术栈应该优先选"资料多、坑少、便宜、好买"的。我最终确定的方案是：STM32F103C8T6最小系统板 + DHT11（或BME280）+ 夏普GP2Y1010AU粉尘传感器 + 两路继电器模块 + ESP8266-01S。
2.1 传感器选型对比：DHT11/BME280、GP2Y1010AU的取舍
先看温湿度传感器。市面上最容易买到、资料最多的是DHT11和DHT22，以及BME280、SHT30这类数字I2C传感器。我做了个对比表：
| 传感器 | 接口 | 精度（温度/湿度） | 价格 | 稳定性 | 适合场景 |
|---|---|---|---|---|---|
| DHT11 | 单总线 | ±2℃ / ±5%RH | 约3元 | 一般，时序敏感 | 毕设、低成本演示 |
| DHT22 | 单总线 | ±0.5℃ / ±2%RH | 约15元 | 较好 | 要求不高的工程应用 |
| BME280 | I2C/SPI | ±0.5℃ / ±3%RH | 约8元 | 好，附带气压 | 推荐首选 |
| SHT30 | I2C | ±0.2℃ / ±2%RH | 约10元 | 好 | 更精确的场景 |
DHT11的精度只能说够用，胜在便宜、教程铺天盖地。如果你要做毕业设计，我建议直接用BME280，数字I2C接口配合标准库读起来其实并不复杂，代码也不比DHT11长多少，而且数据稳定得多。我自己调试的时候，DHT11在环境湿度接近饱和时读数会明显不准，这对"控制除湿机"这个动作来说很要命。如果手头只有DHT11也没关系，下面代码我两种都给了思路。
粉尘传感器我们用的是夏普GP2Y1010AU，这是经典的光学粉尘传感器。很多文章会推荐攀藤PMS5003这类激光粉尘传感器，它直接输出PM2.5浓度数字值（UART接口），精度确实好很多，但价格是GP2Y1010AU的五六倍，功耗也大。GP2Y1010AU输出的是模拟电压，需要STM32的ADC去采集。精度上它不是"实验室级"，但对于判断"仓库粉尘是否超标、要不要开排风"完全够用，关键是学会正确的驱动和采样方法——这个我在第三章展开讲。
2.2 联网与执行：ESP8266-01S和继电器模块
ESP8266我选的是ESP8266-01S模块，原因很简单：便宜、体积小、带板载天线，引出引脚足够用。它只是承担"透传"角色——STM32通过串口给它发AT指令，它负责连接WiFi、连接云平台、收发MQTT消息。注意ESP8266-01S的高电平触发引脚和GPIO0、GPIO2在启动时有模式选择作用，所以STM32这边只需要用到它的UART TX/RX和RST引脚，其它引脚不要乱接。
继电器模块我用了两路：一路控制排风扇，一路控制除湿机。如果还要控制加热器，就再加一路。市面上的继电器模块分为高电平触发和低电平触发，很多默认是低电平触发，买的时候一定要看清，接反了表现就是"单片机一上电继电器就吸合"，非常冤枉。模块上一般有跳线可以切换触发方式，我建议全部设为高电平触发，这样逻辑上更直观：引脚输出高电平 = 设备启动。
2.3 IO分配：一张表说清楚，但注意两处冲突
一套能直接开工的IO分配如下，以STM32F103C8T6为标准：
| 外设 | 引脚 | 说明 |
|---|---|---|
| 温湿度（DHT11） | PB0 | 单总线数据，需外接4.7k-10k上拉电阻 |
| 温湿度（BME280） | PB6/PB7 | I2C1：SCL/SDA，地址0x76或0x77 |
| 粉尘传感器LED | PA1 | TIM2_CH2输出PWM，频率100Hz、占空比3.2% |
| 粉尘传感器Vout | PA0 | ADC1_IN0，模拟输入 |
| 继电器1（排风扇） | PA4 | 高电平触发 |
| 继电器2（除湿机） | PA5 | 高电平触发 |
| 继电器3（加热器） | PA6 | 预留 |
| ESP8266 TX/RX | PA2/PA3 | USART2，连接ESP8266的RXD/TXD（交叉） |
| 调试串口 | PA9/PA10 | USART1，连接USB转TTL |
两个必须避开的冲突点要说清楚。第一，PA13/PA14/PA15是JTAG/SWD调试引脚，很多人做调试器的时候占用了这些脚，然后发现自己没法下载程序了，要在代码里调用GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);把JTAG关掉、只留SWD，才能自由使用PA13/PA15等引脚。第二，PA2/PA3接了ESP8266之后，就不能再拿去做按键或者接其它串口设备了；如果对UART引脚有特殊需求，可以利用AFIO做重映射（比如UART2可重映射到PD5/PD6），但在C8T6这种小封装上可用的引脚不多，规划阶段就要留好余量。
2.4 电源与地线：ADC怕什么、继电器怕什么
电源设计是这类项目翻车最多的地方，比代码里出错难查多了。我整理了几个关键原则：
- STM32的3.3V由板载LDO提供，一般没问题；传感器模块我单独用5V供电，避免和MCU抢电流。
- GPIO2Y1010AU的LED驱动需要5V，同时它的Vout输出范围包含0-3.6V，接到STM32的PA0前最好串一个1k电阻做保护，避免超过3.3V时灌入ADC引脚。
- ESP8266-01S的峰值电流能到300mA以上（WiFi发射瞬间），如果和STM32共用同一个3.3V稳压源，WiFi一发射就会把电压拉低，导致单片机复位。我的做法是ESP8266用单独的5V转3.3V模块供电，或者至少在主电源上并联一个470μF以上的电解电容。
- 继电器模块的供电最好和MCU供电分开，只共地。继电器吸合瞬间线圈电流突变，会在电源线上产生很大的尖峰，如果共用同一个电源轨，单片机极易复位。这个坑我在第六章详细扒。
3. STM32端采集代码：温湿度时序、粉尘脉冲驱动与ADC滤波
硬件接线完毕，接下来是软件。工程我用标准库写的，一是这类传感器和AT指令控制逻辑基本不依赖HAL的高级抽象，标准库代码更直接；二是网上绝大多数现成驱动都是标准库，抄起来省事。用CubeMX生成HAL工程的朋友也不用担心，思路完全一样，只是初始化代码的写法不同。
3.1 DHT11读取：单总线时序的关键代码和常见翻车点
DHT11和STM32之间用的是单总线协议，只有一根数据线，靠严格的时序区分0和1。整个读取流程是这样的：主机先把总线拉低至少18ms发起读取，然后释放总线；DHT11响应时先把总线拉低80μs，再拉高80μs；接着连续发送40位数据（8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和）。每一位数据的区分标准是看高电平时长：26-28μs的高电平代表"0"，70μs的高电平代表"1"。
核心的读位函数是这样的：
uint8_t DHT11_ReadBit(void) { uint8_t retry = 0; while (GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == 0) { if (++retry > 200) return 0xFF; // 超时保护，防止死等 delay_us(1); } delay_us(40); // 等待40us，进入判别窗口 if (GPIO_ReadInputDataBit(DHT11_PORT, DHT11_PIN) == 1) return 1; // 40us后仍是高电平，说明是长脉宽 -> 1 else return 0; }这里有几个最容易翻车的点。第一，单总线对微秒级延时要求很严格，如果延时函数用的是普通循环并且恰好在读取过程中被中断打断，就会读到错误的位，所以我建议在DHT11读取期间关闭可屏蔽中断，或者至少不要让高频率的中断在这段时间触发。第二，一定要加超时退出机制，不要写成死等循环——如果传感器接线掉了或者上拉电阻漏焊，程序会永久卡在读位函数里，这在无人值守设备上是灾难。第三，DHT11两次读取间隔至少要1秒以上，它内部采样周期就是1秒，你读快了它根本不更新数据，拿到的永远是上一次的缓存。
如果你用BME280，代码反而简单得多：I2C读取校准系数，配置过采样，读原始数据，套官方补偿公式计算出温湿度和气压。BME280的补偿公式一长串，建议直接移植现成的bsp库，但要注意I2C地址：SDO引脚接地时地址是0x76，接高电平时是0x77，跟OLED屏幕（通常0x3C）不一样，别搞混。
3.2 GP2Y1010AU粉尘传感器：为什么LED要脉冲驱动
GP2Y1010AU的内部结构是：一个红外LED、一个光电二极管、一个信号处理电路。红外LED发出的光穿过空气后，被光电二极管接收，粉尘颗粒越多，接收到的光强变化越大，输出模拟电压也随之变化。但它的LED不是让你一直点亮，而是必须用脉冲驱动——这点是绝大多数新手栽跟头的地方。
看数据手册会发现，它要求的LED驱动信号是：周期10ms（100Hz）、脉冲宽度0.32ms。为什么？有两层原因。第一，红外LED连续点亮会让光电二极管产生一个很强的直流偏置，粉尘浓度导致的微小光强变化被淹没在直流信号里，输出信号信噪比很差。第二，这个传感器本身就是按照脉冲模式设计的，连续点亮导致LED过流发热，寿命急剧下降，几小时后读数就开始漂移。
所以驱动LED的正确做法是让STM32的定时器输出PWM波形，周期10ms、占空比3.2%。用TIM2的通道2输出到PA1：
// 假设定时器时钟为72MHz，分频720，计数频率100kHz TIM_TimeBaseStructure.TIM_Period = 999; // 10ms TIM_TimeBaseStructure.TIM_Prescaler = 719; // 72MHz / 720 = 100kHz TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); TIM_OCInitStructure.TIM_Pulse = 32; // 0.32ms TIM_OC2Init(TIM2, &TIM_OCInitStructure); TIM_OC2PreloadConfig(TIM2, TIM_OCPreload_Enable); TIM_Cmd(TIM2, ENABLE);简单理解：PA1上会产生一个"每10ms闪一次、每次闪0.32ms"的信号，驱动粉尘传感器的LED，就像拿着手电筒每隔一会闪一下看一眼，而不是一直照着你。Vout引脚输出的就是每次"闪光"时检测到的电压峰值高度，这个高度和粉尘浓度正相关。
3.3 ADC同步采样与滑动滤波：从电压到浓度的换算
Vout接到PA0（ADC1_IN0），接下来要解决一个时序问题：什么时候去采样最准确？理想情况下，应该在LED脉冲点亮后约0.28ms的位置采样，也就是脉冲中后段。两种实现方式：
第一种是同步采样，用PWM定时器的比较事件来触发ADC注入采样，保证每一次采样都刚好落在LED点亮窗口内。这种方法精度最高，但配置复杂，不建议新手一开始就用。
第二种是我实际采用的方法：ADC连续快速采样，取最大值。因为Vout的电压变化和LED脉冲是同步的，脉冲出现时Vout会冲高到一个峰值，脉冲结束后回落。只要在采集周期内连续采样几十到上百次，必然能"撞上"峰值，取最大即可：
uint16_t ReadDustPeak(void) { uint16_t max_v = 0; uint16_t v; for (int i = 0; i < 100; i++) { ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET); v = ADC_GetConversionValue(ADC1); if (v > max_v) max_v = v; } return max_v; }采样完成后，数据还需要滑动平均滤波。粉尘信号本身波动比较大，直接用单次峰值做控制判断，可能导致继电器频繁误动作。我维护一个长度为20的环形缓冲区：
#define DUST_WINDOW 20 uint16_t dust_buf[DUST_WINDOW]; uint8_t dust_idx = 0; uint32_t dust_sum = 0; void Dust_Update(void) { uint16_t peak = ReadDustPeak(); dust_sum -= dust_buf[dust_idx]; dust_buf[dust_idx] = peak; dust_sum += peak; dust_idx = (dust_idx + 1) % DUST_WINDOW; }滤波后的ADC码值dust_sum / DUST_WINDOW就是本次有效读数。电压和浓度之间的换算，我不建议用网上流传的那些固定系数，因为GP2Y1010AU不同批次、不同电路的零点电压差异很大。稳妥做法是：先在洁净环境下记录底噪电压作为零点，再参照典型灵敏度（0.5V对应的粉尘浓度约为0.1mg/m³）做线性换算。如果条件允许，用一支标准粉尘仪做一次现场标定，把系数修正到你自己的电路上。对绝大多数场景来说，看相对变化趋势已经足够判断"该不该开排风"了。
4. 自动控制策略：回差控制、继电器驱动与看门狗兜底
采集到可靠数据后，控制逻辑就变成了"用数据做决策"的问题。这一章是整个系统的灵魂——因为决策逻辑如果写不好，硬件再稳定，效果也是恼人的。
4.1 为什么要回差控制：一次继电器误动作引发的思考
我最早写的逻辑非常简单：湿度大于70%就开除湿机，小于70%就关掉。上电测试第一天就露馅了——湿度在69%和71%之间来回跳，继电器"咔咔咔"跟着不停吸合释放，几分钟后继电器模块烫得能煎鸡蛋。
原因是传感器数据总有噪声，环境本身也有微小的波动。当设定值正好落在测量值抖动范围内时，系统就会在"开"和"关"之间反复切换。解决思路叫回差控制（滞回控制）：把开机点和关机点分开，中间留一个缓冲区。比如设定湿度超过70%时启动除湿机，等湿度降低到62%时才关闭。这样中间差了8个百分点，除非环境剧烈波动，否则不会出现临界点抖动。
这个思路和烧水壶的温控开关一个道理：水烧到指定温度断电，但不会在断电瞬间又立刻通电，因为温度要降下去一段才会重新接通。对继电器这种机械触点设备，回差控制不只是逻辑上的优化，更是保护执行机构、延长寿命的刚需。
4.2 控制逻辑实现：阈值表和代码
我最终的项目控制规则如下：
| 条件 | 动作 |
|---|---|
| 温度 ≥ 32℃，或粉尘浓度 ≥ 0.1mg/m³ | 打开排风扇 |
| 湿度 ≥ 70%RH | 打开除湿机 |
| 温度 ≤ 28℃ 且 粉尘浓度 ≤ 0.06mg/m³ | 关闭排风扇 |
| 湿度 ≤ 60%RH | 关闭除湿机 |
代码上用一个简单状态机来管理，避免那种又长又臭连续if else：
void Control_Task(void) { if (temp >= 32.0f || dust >= 0.10f) Relay_Set(RELAY_FAN, ON); else if (temp <= 28.0f && dust <= 0.06f) Relay_Set(RELAY_FAN, OFF); if (hum >= 70.0f) Relay_Set(RELAY_DEHUMIDIFIER, ON); else if (hum <= 60.0f) Relay_Set(RELAY_DEHUMIDIFIER, OFF); }注意每个控制动作都放在主循环里周期执行，而不是用阻塞式延时。主循环跑一圈大概是几百毫秒，加上回差区间，继电器根本不会频繁动作。如果将来要接多个设备，还可以给每台设备单独加"最小动作间隔"（比如继电器吸合后至少保持5秒），进一步保护机械触点。
4.3 继电器与看门狗：无人值守的两个保命措施
继电器驱动在电气上要单独说清楚。STM32的GPIO最高只能输出约3.3V/8mA左右，而5V继电器的线圈需要50-70mA电流，直接驱动会烧引脚。正确方案是中间加一级驱动：用NPN三极管（如S8050）或ULN2003达林顿管，再配合线圈两端的续流二极管。如果你买的是现成的继电器模块，模块上已经集成了驱动三极管和续流二极管，直接用模块就好，但一定要确认模块的"触发端"能否被STM32的3.3V高电平可靠触发。部分模块对输入高电平要求接近5V，STM32给3.3V时继电器不动作或动作不可靠，这种情况下要把模块的触发方式换到低电平触发，或者用光耦隔离驱动板做中转。
如果直接从零搭继电器电路，关键元件是这样的：GPIO → 1kΩ限流电阻 → NPN三极管基极；三极管集电极接继电器线圈一端，线圈另一端接5V；线圈两端反向并联一个1N4148或1N4007续流二极管（负极接5V）。这样gpio给高电平，三极管导通，继电器吸合；断电瞬间续流二极管把线圈感生电流泄放掉，不会反向击穿三极管。
单片机的保命手段则是一句"看门狗"。我用独立看门狗（IWDG），超时设定2秒，主循环每转一圈喂一次狗。万一某个函数陷入死循环或者传感器读取卡住，看门狗会自动复位单片机，系统从异常状态恢复到可控状态。无人值守场景下，这比任何复杂报警都管用。
5. ESP8266上云：AT指令链路、巴法云MQTT接入与数据帧设计
本地闭环打通后，最后一环是把数据送上网。这块内容多且杂，我把自己的实践过程拆开讲。
5.1 上云路线怎么选：AT+TCP、AT+MQTT、还是ESP8266独立干活
ESP8266有三种主流的干活方式：
第一种，ESP8266刷AT固件，STM32通过串口发AT指令控制它联网。这是最简单、最适合STM32主导系统的方案，也是我用的方案。STM32采集传感器数据，通过AT指令把JSON数据包直接发布到云平台MQTT，逻辑清晰，排查问题也方便。
第二种，ESP8266刷Arduino或MicroPython固件，由ESP8266自己连传感器再上云。这种方案等于ESP8266独立成为一个物联网节点，STM32就失业了。对仓库环境控制这种需要本地模拟量采集、继电器控制、看门狗守护的场景来说，没必要把控制权从STM32手里交出去。
第三种，也是很多教程喜欢但不推荐的：让ESP8266发HTTP请求到云平台API。这个方案链路简单，但HTTP包头开销大，云端响应慢，断线重连逻辑还得写在AT指令循环里，后期维护比较痛苦。MQTT比HTTP更适合这种低功耗、频繁上报的传感器场景。
5.2 巴法云MQTT接入实战：AT指令完整链路
云平台我选了巴法云，原因是它对国内用户友好，MQTT接入免费，创建主题后在控制台能看到所有平台的接入示例，而且自带小程序和微信推送，做完了手机端立刻有东西可以看。
接入之前先确认ESP8266的AT固件版本支持MQTT指令。官方AT固件1.7以上才有AT+MQTTUSERCFG这一组命令，我默认用的是官方AT 2.x固件。如果手头的ESP8266模块是老固件，先用AT+GMR查看版本，太老就先烧录新固件。整个接入流程如下：
AT // 测试模块是否响应，返回OK AT+CWMODE=1 // 设置为Station模式 AT+CWJAP="你的WiFi名字","你的WiFi密码" // 连接路由器 AT+MQTTUSERCFG=0,1,"NULL","你的UID","你的UID",0,0,"" AT+MQTTCONN=0,"mqtt.bemfa.com",9501,1 AT+MQTTPUB=0,"你的设备主题","{\"temp\":25.3,\"hum\":60.5,\"dust\":45.2}",1,0这里面的"UID"就是巴法云控制台里的设备私钥，相当于你在这个平台的唯一身份标识；"设备主题"是你在控制台创建的topic ID。STM32侧把这些AT指令封装成函数：
void ESP8266_SendCmd(UART_HandleTypeDef *huart, char *cmd) { UART_SendString(huart, cmd); UART_SendString(huart, "\r\n"); // 所有AT指令必须以\r\n结尾 }需要注意的是，AT+CWJAP连接路由器、AT+MQTTCONN连接云端这些操作耗时较长（1-3秒不等），STM32发完指令后不能只做固定延时，要加上"接收成功标志"状态判断。我的做法是：发完AT指令后，每50ms检查一次串口接收缓冲区，如果超时3秒还没收到"OK"或"ERROR"，就重新发送该指令，最多重试3次。这套机制在离线环境下尤为重要，否则WiFi断了系统就直接卡死在等待里。
5.3 JSON数据帧设计与断线重连
上报的payload我用了最简单的JSON格式：
{"temp":25.3,"hum":60.5,"dust":45.2,"fan":1,"dry":0}包含温湿度、粉尘浓度以及当前两个继电器的状态。把执行状态也上报上去，好处是在手机端能看到"系统判断该通风了，而且真的打开了风扇"，而不是只能看到一堆传感器数据。
断线重连的策略我放在主循环里：定期用AT+MQTTSTAT查一次连接状态，如果返回的不是正常状态，就按顺序重新执行AT+MQTTCONN。时间上有个技巧，云平台一般要求客户端定期发心跳包，否则会自动断开连接；巴法云这边我每60秒重新发布一次最新数据，既完成了数据更新，也顺便当心跳。如果你的传感器变化慢，完全可以把上报周期拉长到2分钟、5分钟，省流量也省电。
5.4 迁移到OneNET/阿里云要改哪些东西
如果答辩老师或项目需求要求用OneNET或阿里云，核心改动只有三个：MQTT服务器地址、端口、ClientID/用户名/密码这几个鉴权参数。OneNET的MQTT接入用的通常是产品ID、设备ID、APIKey这套体系，你只要在产品控制台创建好产品设备，把鉴权参数填进AT+MQTTUSERCFG和AT+MQTTCONN里，topic改成产品/设备的格式，其余代码基本原样复用。阿里云IoT平台的鉴权稍微复杂点，ClientID、UserName和Password里包含用设备Secret做HMAC-SHA1签名计算出的密钥，这部分需要预先在PC上算好再固化到STM32代码里，不建议在板子上跑完整签名算法，既占资源又难调。我的建议是：先用巴法云把整条链路跑通，再根据平台差异逐个替换——协议是MQTT的时候，换平台只是换参数，不伤筋动骨。
6. 五天调试实录：掉过的坑和根因，都整理在这了
写代码的时间其实只占一小半，大头全花在调试上。我把自己踩过、且很多同学大概率也会踩的五个坑列出来，每个都给根因和解决方案。
6.1 ESP8266恢复出厂后AT无响应：别在"OK"上死等
我第一次上电时想恢复出厂设置，发送AT+RST后立刻在循环里等"OK"返回。程序卡了好几分钟，怎么都不出来。原因很简单：AT+RST之后模块会重启，重启过程需要一两秒甚至更久，此时串口上没有任何返回；而我的循环在等"OK"，模块重启完成后输出的是乱码或启动日志，根本不含"OK"，然后循环就假死了。
正确做法是：AT+RST发送后先延时2秒，再发送AT并等待"OK"。而且任何AT指令的响应接收都不能用死等，必须带超时计数，超时就重发。这个改完以后，后面接WiFi、接MQTT我再也没卡过死循环。
6.2 DHT11偶发读失败：延时精度与单总线冲突
现象是DHT11偶发返回错误数据，读到的湿度和温度突然变成255。排查下来有一个隐蔽原因：我在系统里用了SysTick做delay_us，但ESP8266的UART接收中断频率很高，DHT11在读位等待高电平的过程中，如果恰好发生中断，延时会多出几十微秒，导致"0"被误判成"1"。
解决方案是DHT11读取期间关闭全局中断，读取结束后再打开：
__disable_irq(); DHT11_ReadData(); __enable_irq();这里也有个教训：单总线传感器虽然便宜，但它对微秒级时序的敏感程度远超想象。你需要先确认项目的整个中断环境是否复杂，如果中断多且频繁，直接换BME280这类I2C传感器能省掉至少半天调试时间。
6.3 ADC采样值漂移：根因在粉尘LED的供电
粉尘传感器刚接上时，我发现读数一直在漂，关了继电器也漂。先用万用表量5V电源轨，发现电压在4.7V到5.1V之间跳。GP2Y1010AU的Vout和它的LED供电直接相关，电源电压不稳，模拟输出自然跟着抖。
根因是LED驱动和MCU共用了一个5V稳压源，LED脉冲导通瞬间拉低了电压。解决方法很土但有效：在粉尘传感器的5V供电引脚旁边并一个100μF电解电容和一个0.1μF陶瓷电容，靠近模块放置；同时确认LED驱动PWM的地线、传感器地线、STM32地线在一点汇聚，不要形成环路。电容并上之后，ADC读数稳定了不止一个数量级。
6.4 继电器吸合瞬间单片机复位
这是最诡异的一个现象：程序跑得好好的，风扇一开，STM32就重启。用示波器量3.3V引脚，发现继电器吸合瞬间3.3V被砸出一个大坑，掉到2.5V以下。
原因在电源配置上：继电器模块、MCU最小系统板、ESP8266全部挤在面包板上，用同一个5V输入供电。继电器线圈吸合瞬间电流冲击很大，5V被瞬间拉低，板上LDO输出3.3V跟着跌穿MCU复位电压。解决方法是：继电器模块独立供电（单独一路5V电源，或者干脆用12V继电器配12V电源），所有模块只共用参考地线，不共用电源轨。这个改动之后，开关继电器时单片机再没复位过。
6.5 PA2/PA3被占用：UART与GPIO的引脚冲突
项目后期想加一个按键做本地手动切换模式，随手选了PA2，然后发现ESP8266数据全部错乱。查了半天才反应过来，PA2是USART2_TX引脚，ESP8266的数据线正挂在上面。这种低级错误本质上是引脚利用率规划不仔细——我一开始做IO分配表的时候，就把所有复用功能引脚一起列出来对比，而不是"用到哪个查哪个"。
教训是：设计阶段就把所有外设需要的引脚画成图，标出USART、SPI、I2C、ADC、PWM这些复用通道的默认位置，再做功能叠加，否则后面每加一个外设都要挪引脚，挪完还有可能忘了改初始化代码。
整套系统从画原理图到云端看到第一条数据，前后大约一周。中间最花时间的不是代码本身，而是排查电源和时序这两个"看不见摸不着"的问题。做完之后我的一个强烈感受是：这种环境控制系统的难点根本不在单片机能做什么，而在传感器数据能不能信、控制动作会不会误触发。把回差控制、滑动滤波、看门狗这些基础功夫做扎实，远比堆功能重要。如果你也想做类似项目，建议先用手头的传感器跑通采集和本地控制，再谈上云——顺序反了的话，排错的时候会非常痛苦。
