STM32+腾讯云IoT：烘干车间远程控制实战

简介：这份PDF面向嵌入式开发学习者与物联网项目实践者，围绕基于STM32F103RCT6的烘干车间远程控制系统展开，解决温湿度与空气质量监测、加热通风联动及远程操控等实际问题。资源为单个PDF文件，压缩包约41.81MB，内容以图文文档形式呈现，涵盖硬件选型、电路连线、通信协议、STM32完整代码与调试流程，并详细讲解腾讯云IOT平台的产品与设备开发、物模型配置、MQTT主题订阅发布，以及微信小程序远程监控的对接方法。读者可从中获得从传感器采集、继电器控制、ESP8266联网到云端交互的完整实现思路，包括自动与手动模式切换逻辑、阈值报警机制和LCD本地显示方案，适合作为课程设计、毕业设计或智能工厂改造的参考范本。目前已有204人学习，具备较强的工程借鉴价值。

1. 烘干车间的远程控制，为什么值得用 STM32 加腾讯云 IoT 重做一遍

烘干车间是个很典型的工业现场：温湿度直接决定产品合格率，但车间往往粉尘大、噪音高、人员进出频繁，让工人守在机器旁边手动调温调湿，既不现实也不安全。传统做法是用本地 PLC 加一块触摸屏，操作员站在设备前看数、按键，出了问题只能靠人巡检发现。这套方案能跑，但有两个绕不过去的痛点：一是数据出不了车间，管理者在办公室看不到实时曲线；二是报警滞后，等巡检的人闻到焦糊味，一批料可能已经废了。

把 STM32 和腾讯云 IoT 组合起来，解决的正是这两个问题。STM32 负责在现场采集温湿度、控制加热和风机，腾讯云 IoT 做设备接入、数据转发和远程指令下发，中间用 MQTT 协议通信。这样一套系统，硬件成本可控，开发门槛对做过单片机的工程师来说不算高，而且云端能力是现成的，不用自己搭服务器。它适合谁？适合做工业控制、智能农业、仓储环境监控方向的嵌入式工程师，也适合想从纯本地控制转向「设备上云」的开发者练手。下面我按实际落地的顺序，把选型、接线、代码、云端配置和踩过的坑一条条讲清楚。

2. 系统架构与硬件选型：从传感器到云端的数据链路怎么搭

2.1 为什么是 STM32 + MQTT + 腾讯云 IoT 这个组合

先讲选型逻辑，不然后面接线和写代码都是盲目的。主控选 STM32，最常见的是 STM32F103 系列，原因很实际：资料多、价格低、外设够用。烘干车间需要采集的模拟量有温湿度，需要输出的控制量有加热继电器、风机继电器，可能还要一个蜂鸣器做本地报警。F103 的 ADC、GPIO、USART 完全覆盖这些需求，跑 FreeRTOS 或者裸机都行。

通信方式选 MQTT，而不是 HTTP。HTTP 是请求-响应模式，设备要主动轮询才能拿到云端指令，实时性差、流量浪费大。MQTT 是发布-订阅模式，设备订阅一个指令主题，云端一发指令，设备立刻收到，同时设备也能把传感器数据发布到另一个主题。腾讯云 IoT 的物联网通信平台原生支持 MQTT，设备接入、权限管理、规则引擎都是现成的，省掉自建 broker 的麻烦。

网络模块这块，常见做法是两种：一是 STM32 通过串口接 ESP8266 或 ESP32，由 Wi-Fi 模块跑 MQTT 协议栈；二是直接用带以太网的 STM32 型号加 W5500 这类硬件协议栈芯片。烘干车间如果 Wi-Fi 信号覆盖不好，优先考虑以太网，稳定性高一个档次。我下面以 ESP8266 走 AT 指令的方式讲，因为这是最多人手上有的模块。

2.2 硬件清单与接线要点

把需要的器件列成表，方便对照采购和接线。

接线上有几个点必须注意。DHT22 的数据脚要接一个 4.7k 到 10k 的上拉电阻到 3.3V，否则读出来的数据会随机跳变，这个坑我后面还会提。ESP8266 的 TX 接 STM32 的 RX，RX 接 STM32 的 TX，电平是 3.3V，别直接接 5V。继电器模块如果是低电平触发，GPIO 初始化时要默认输出高电平，否则上电瞬间加热管会误动作，这在烘干车间是能烧坏东西的。

2.3 数据链路与主题设计

数据从传感器到云端，再反向从云端到执行器，整条链路要提前把主题规划好。腾讯云 IoT 的主题格式一般是产品ID/设备名/自定义，我一般会设计成下面这样：

• 上报温湿度：$thing/up/property/产品ID/设备名
• 下发控制指令：$thing/down/property/产品ID/设备名
• 设备属性上报的 JSON 里带temperature、humidity两个字段
• 控制指令的 JSON 里带heater、fan两个布尔字段

主题名不要用中文，不要用空格，大小写要严格一致，云端和设备的主题必须完全匹配，差一个字符就收不到消息。这个在调试阶段最容易翻车，建议把主题字符串定义成宏，两边引用同一个宏。

3. STM32 端代码实现：传感器采集、MQTT 上报与指令解析

3.1 温湿度采集与数据滤波

先解决数据源。DHT22 是单总线时序，对延时敏感，用 HAL 库的HAL_Delay精度不够，我一般用定时器做微秒级延时。下面是一个可复用的读取函数框架：

// dht22.c #include "dht22.h" // 微秒级延时，基于 SysTick 或 TIM static void delay_us(uint32_t us) { uint32_t start = DWT->CYCCNT; uint32_t ticks = us * (SystemCoreClock / 1000000); while ((DWT->CYCCNT - start) < ticks); } // 读取一次温湿度，成功返回 0 uint8_t DHT22_Read(float *temp, float *humi) { uint8_t buf[5] = {0}; // 主机拉低至少 1ms 发起通信 HAL_GPIO_WritePin(DHT_GPIO_Port, DHT_Pin, GPIO_PIN_RESET); HAL_Delay(2); HAL_GPIO_WritePin(DHT_GPIO_Port, DHT_Pin, GPIO_PIN_SET); delay_us(30); // 等待 DHT22 响应，超时则返回错误 if (HAL_GPIO_ReadPin(DHT_GPIO_Port, DHT_Pin) == GPIO_PIN_SET) return 1; while (HAL_GPIO_ReadPin(DHT_GPIO_Port, DHT_Pin) == GPIO_PIN_RESET); while (HAL_GPIO_ReadPin(DHT_GPIO_Port, DHT_Pin) == GPIO_PIN_SET); // 逐位读取 40 位数据 for (int i = 0; i < 40; i++) { while (HAL_GPIO_ReadPin(DHT_GPIO_Port, DHT_Pin) == GPIO_PIN_RESET); delay_us(40); if (HAL_GPIO_ReadPin(DHT_GPIO_Port, DHT_Pin) == GPIO_PIN_SET) buf[i / 8] |= (1 << (7 - (i % 8))); while (HAL_GPIO_ReadPin(DHT_GPIO_Port, DHT_Pin) == GPIO_PIN_SET); } // 校验和 if (buf[4] != (buf[0] + buf[1] + buf[2] + buf[3])) return 2; *humi = (buf[0] << 8 | buf[1]) / 10.0f; *temp = ((buf[2] & 0x7F) << 8 | buf[3]) / 10.0f; if (buf[2] & 0x80) *temp = -*temp; return 0; }

这段代码的关键在时序。delay_us用 DWT 周期计数器实现，比空循环准。读取每一位时，先等低电平结束，延时 40 微秒后采样，高电平持续时间长代表 1，短代表 0。校验和不过就丢弃这次数据，不要用。实际使用中，我建议连续读三次取中间值，或者做滑动平均，因为烘干车间气流扰动大，单次读数会有 ±0.5 度的跳动。

3.2 ESP8266 的 AT 指令联网与 MQTT 接入

ESP8266 出厂固件支持 AT 指令，但默认固件不一定带 MQTT 指令集。常见做法是烧录带 MQTT AT 固件的版本，或者让 STM32 自己跑 MQTT 协议栈、把 ESP8266 当透明传输。后者更灵活，但代码量大。我下面用 AT 指令方式，因为上手快。

// esp8266.c 片段：连接 Wi-Fi 并建立 MQTT 连接 void ESP_Init(void) { SendAT("AT+RST\r\n", 2000); // 复位模块 SendAT("AT+CWMODE=1\r\n", 500); // 设为 Station 模式 SendAT("AT+CWJAP=\"SSID\",\"PASS\"\r\n", 8000); // 连 Wi-Fi SendAT("AT+MQTTUSERCFG=0,1,\"NULL\",\"设备名\",\"密钥\",0,0,\"\"\r\n", 500); SendAT("AT+MQTTCONN=0,\"产品ID.iotcloud.tencentdevices.com\",1883,1\r\n", 5000); } // 订阅下行控制主题 void ESP_Subscribe(void) { SendAT("AT+MQTTSUB=0,\"$thing/down/property/产品ID/设备名\",1\r\n", 1000); }

AT+MQTTUSERCFG里的参数依次是连接号、方案、客户端 ID、用户名、密码、证书相关。腾讯云 IoT 的设备名和密钥在控制台创建设备时会生成，密钥只显示一次，务必保存。AT+MQTTCONN的地址格式是产品ID.iotcloud.tencentdevices.com，端口 1883 是非加密的，正式环境建议用 8883 加 TLS，但 STM32 跑 TLS 对资源要求高，很多项目会加一个带硬件加密的模组或者走网关。

3.3 上报 JSON 的拼装与下行指令解析

上报数据要拼成 JSON，腾讯云的数据模板对格式有要求。下面是一个拼装和发送的函数：

// 上报温湿度到云端 void Report_Data(float temp, float humi) { char json[128]; char cmd[192]; // 拼装属性上报 JSON snprintf(json, sizeof(json), "{\"method\":\"report\",\"params\":{\"temperature\":%.1f,\"humidity\":%.1f}}", temp, humi); // 通过 MQTT 发布，主题为属性上报主题 snprintf(cmd, sizeof(cmd), "AT+MQTTPUB=0,\"$thing/up/property/产品ID/设备名\",\"%s\",0,0\r\n", json); SendAT(cmd, 1000); }

下行指令的解析要处理两种情况：一是云端主动下发的控制指令，二是设备影子同步。解析时不要用strstr直接找关键字就完事，因为 JSON 里字段顺序不固定。稳妥做法是找"heater"后面的true或false，并且判断这个字段确实在params对象里。解析到指令后，立刻操作 GPIO，并且把执行结果再上报一次，形成闭环。如果解析失败，不要静默丢弃，把原始报文通过串口打印出来，方便排查。

4. 腾讯云 IoT 平台配置：产品、设备、数据模板与规则引擎

4.1 创建产品与定义数据模板

登录腾讯云物联网开发平台，新建一个产品，品类选「环境监测」或「工业设备」都行，通信方式选 MQTT。产品建好后，进入「数据模板」页面，定义两个属性：temperature和humidity，数据类型选浮点，读写权限选「可读」。再定义两个布尔型属性heater和fan，权限选「可读可写」，这样云端才能下发控制。

数据模板定义完，平台会自动生成上下行主题。注意，属性上报和事件上报的主题不一样，别混用。属性上报走$thing/up/property/，事件上报走$thing/up/event/。如果你只是周期性上报温湿度，用属性上报就够了。

4.2 设备注册与密钥管理

在产品下「设备调试」或「设备管理」里新建设备，设备名自己定，比如dryer01。创建成功后，平台会给出设备密钥，这个密钥在设备端做 MQTT 连接时当密码用。密钥泄露等于设备被冒用，所以不要硬编码在开源代码里，量产时建议一机一密，通过安全芯片或加密存储保存。

设备三元组是产品 ID、设备名、密钥。这三个值在 STM32 代码里对应AT+MQTTUSERCFG和AT+MQTTCONN的参数。调试阶段可以先用明文，正式部署时把密钥放到外部 Flash 的加密区，或者用 STM32 的读保护功能防止被读出。

4.3 规则引擎转发与告警配置

数据到了云端，如果只是存着没意义，要让它产生动作。腾讯云 IoT 的规则引擎可以把设备上报的数据转发到其他云服务，比如转发到消息队列、写入数据库、或者触发云函数。烘干车间最实用的场景是超限告警：当温度超过设定阈值，规则引擎触发一个云函数，云函数调用短信或邮件接口通知管理员。

配置规则时，SQL 语句类似SELECT * FROM '$thing/up/property/产品ID/设备名' WHERE temperature > 60。注意主题里的$和引号要写对，SQL 对大小写敏感。规则建好后，可以在「规则日志」里看到触发记录，调试阶段靠这个确认数据有没有正常流转。

5. 联调避坑：从数据跳变到指令丢失的排查记录

5.1 温湿度读数随机跳变甚至读不出

现象：串口打印的温湿度偶尔是 0 或者 85，或者干脆校验失败。原因通常是上拉电阻没接、延时不准、或者传感器供电不足。DHT22 在转换期间电流会瞬间拉高，如果和继电器共用一路 5V 且走线细，电压会被拉低导致复位。解决：数据脚加上拉电阻，传感器单独走一路 LDO 供电，读取间隔不要小于 2 秒。如果换成 SHT30 走 I2C，这类问题会少很多，预算允许建议直接上 SHT30。

5.2 MQTT 连上就断，或者频繁重连

现象：设备显示在线，但过几十秒就掉线，日志里看到MQTTCONN反复执行。原因一般是心跳间隔设置不合理，或者 AT 指令发送太快，模块还没返回就发了下一条。ESP8266 的 AT 指令必须等上一条返回OK再发下一条，中间要有超时判断。另外，腾讯云对同一设备名的并发连接有限制，如果调试时多个串口工具同时连，会互相踢下线。解决：加状态机管理 AT 指令收发，心跳设 60 秒，确保同一设备名只有一个连接。

5.3 云端下发指令设备收不到

现象：在控制台点「下发」，设备端串口没有任何反应。原因有三个常见方向：主题写错、订阅没成功、JSON 格式不对。先检查订阅主题和云端下发主题是否完全一致，包括$thing/down/property/前缀。再确认AT+MQTTSUB返回的是OK而不是ERROR。最后看云端下发的 JSON 里字段名是否和数据模板定义的一致，heater写成Heater就解析不到。解决：把订阅和接收的原始报文都打印出来，逐字节比对。

5.4 继电器误动作导致加热管上电即启动

现象：设备一上电，加热继电器就吸合，温度飙升。原因是 GPIO 初始化默认电平是低，而继电器是低电平触发。解决：在 GPIO 初始化之后、使能输出之前，先把引脚置高；或者选用高电平触发的继电器模块。这个坑在调试阶段可能只是吓一跳，在真实车间就是事故，务必在硬件上电前用万用表确认继电器状态。

5.5 数据上报频率过高导致云端限流

现象：设备上报正常，但运行一段时间后云端收不到数据，规则引擎也不触发。原因是腾讯云对单设备的消息上报频率有配额，免费版通常限制在每秒几条。如果代码里在主循环里不加延时地疯狂上报，很快就会被限流。解决：上报周期设成 5 到 10 秒一次，变化不大时可以更长；紧急告警走事件上报，不要和属性上报混在一起刷。

6. 进阶技巧：用设备影子做断网续传与状态同步

设备影子是腾讯云 IoT 里一个很实用的功能，但很多人只把它当缓存用，没发挥出真正价值。烘干车间的网络不一定稳定，如果设备断网期间云端下发了「关闭加热」的指令，设备恢复后应该知道这个指令存在，而不是继续按断网前的状态跑。设备影子就是解决这个问题的：云端维护一份设备最新状态，设备上线后主动拉取影子，对比本地状态，有差异就执行。

具体做法是，设备端在 MQTT 连接成功后，订阅影子相关主题$shadow/up/property/产品ID/设备名，然后发布一条拉取请求。影子返回的 JSON 里包含desired和reported两个对象，desired是云端期望的状态，reported是设备上次上报的状态。设备对比这两个对象，如果desired里的heater是false而本地是开着的，就关闭加热并更新reported。

// 拉取设备影子并同步状态 void Sync_Shadow(void) { char cmd[160]; // 发布空消息到影子更新主题，触发影子下发 snprintf(cmd, sizeof(cmd), "AT+MQTTPUB=0,\"$shadow/up/property/产品ID/设备名\",\"\",0,0\r\n"); SendAT(cmd, 1000); // 影子数据会通过订阅的主题下发，在回调里解析 desired }

解析影子回调时，重点看desired对象。如果里面有你支持的字段，就执行对应动作，然后把执行后的状态通过reported上报回去。这样即使设备重启、断网重连，状态也能自动对齐，不需要人工干预。这个机制在多点控制的场景下尤其有用：办公室的管理员改了设定，现场设备恢复网络后自动跟随，不会出现两边状态打架的情况。

还有一个技巧是本地缓存最近一次的有效指令。STM32 的 Flash 或备份寄存器可以存几个字节，把加热和风机的目标状态存进去。上电初始化时先读缓存，再连网拉影子，两者取最新。这样即使云端暂时连不上，设备也能按最后一次已知的合理状态运行，不至于完全失控。我一般会在 Flash 里划一页专门存这些运行参数，写入前先擦除，写入后做校验，避免掉电写坏。

最后说一个我自己的习惯：每次改完云端数据模板或者主题，一定先在串口把完整的 MQTT 报文打印出来，和云端日志逐字对一遍。这个动作花不了两分钟，但能省掉大量「明明配置一样却收不到」的玄学排查时间。烘干车间这类项目，稳定比功能多更重要，把断网续传和状态同步做扎实，比堆一堆花哨的云端大屏有价值得多。希望帮到你。

本文还有配套的精品资源，点击获取