很多做物联网的工程师，板子能跑、传感器也能读，真正卡住的往往是接云这一步。STM32 外设丰富、资料齐全、成本可控，国内工控和智能硬件里用得很多。阿里云 IoT 平台提供设备接入、规则引擎、数据存储和面板，两者搭在一起，一块普通开发板就能把数据送上云，省掉从零搭后端的工作。
本文以温湿度采集终端为例，拆解从云端注册到 MQTT 上报的步骤，顺带说说选型和调试时容易踩的坑。
一、项目场景与选型
假设某大棚项目要部署 20 个监测节点，每个节点采集空气温湿度和土壤湿度，每 10 秒上报一次。现场用 4G 模组联网，流量和功耗都得算着用。
主控选 STM32F103C8T6，便宜、资料多，采集和运行协议栈够用。通信用支持 MQTT 的 4G 模块。云端选阿里云，主要看这几点：
- 接入方式全，支持 MQTT、CoAP、HTTP，设备端用三元组认证。
- 规则引擎可以直接把数据转发到时序库或消息队列，少写一层自建转发。
- 设备在线状态、消息日志和数据面板都自带，现场排障时可以先在云端确认数据有没有到。
二、在控制台注册设备
- 创建产品，节点类型选直连设备，数据格式选 Alink JSON 或自定义格式。格式定下来后，解析规则都会跟着它走，中途别随意改。
- 在产品下定义物模型，添加温度、湿度等属性。面板和数据解析都依赖它，建议在项目初期定稿。
- 添加设备，平台会生成 ProductKey、DeviceName 和 DeviceSecret，也就是设备三元组。
DeviceSecret 属于敏感凭证，不要明文写进公开代码仓库。量产时更常见的做法是一机一密，或者使用动态注册，省去逐台手工写入密钥的步骤。动态注册依赖产品级密钥，同样需要妥善保管。
三、STM32 端的 MQTT 连接
直连方式下，clientId、username 和 password 需要根据三元组按规则生成。username 一般是 DeviceName&ProductKey 的形式。password 由 DeviceSecret 作为 HMAC-SHA1 的密钥，对按规则拼接的字符串签名得到，DeviceSecret 本身不会直接上传。clientId 后面通常还要带安全模式、签名算法等参数，具体格式以当前版本的官方文档为准，不同版本之间有差异，别凭记忆拼。
固件侧通常分四层：
- 网络层：通过 AT 指令驱动 4G 模组建立 TCP 连接，连接阿里云域名的 1883 或 8883 端口。8883 为 TLS 加密端口，正式环境优先考虑。
- 协议层：移植 Paho MQTT Embedded，或者直接使用阿里云官方提供的嵌入式 SDK。官方 SDK 已经处理了不少连接和重连细节，能少踩一些坑。
- 认证层：三元组拼接和签名在设备端完成。芯片有硬件加密单元就优先使用，没有的话用经过验证的软件 HMAC 实现，不建议自己手写。
- 业务层：定时读取 DHT11 或 SHT30 数据，封装成 JSON，发布到属性上报 Topic。
属性上报的 Topic 格式为 /sys/{productKey}/{deviceName}/thing/event/property/post，消息体示例如下：
{"id":"1","version":"1.0","params":{"temperature":26.5,"humidity":61.2}}调试阶段最常遇到两类问题。第一是时间戳偏差导致签名校验失败，设备时间不准就会出现这种情况。解决办法是先做 NTP 同步，或者从平台时间接口获取时间。第二是 4G 模组在弱信号环境下频繁掉线。代码里需要加入心跳保活和断线重连，而且重连后要重新完成 MQTT 连接和认证，只重连 TCP 是不够的。
四、数据上云后的规则与展示
数据到达平台后，可以用规则引擎做进一步处理。比如温度超过 35 摄氏度时转发给告警服务，或者把全部历史数据写入时序数据库。大棚项目里还配了一条规则：土壤湿度低于阈值并持续三分钟，就自动向灌溉设备下发开启指令。这条规则跑通后，基础的闭环控制就有了。
展示方面，平台自带的数据面板够用时直接用就行。需要接入自建 Web 系统或移动端时，通过 API 获取数据即可。
五、几点体会
- 物模型尽量在量产前定稿。字段一改，解析规则和面板配置都要跟着调整。
- 固件里保留日志输出口，打印连接返回码和关键拼接步骤，定位认证问题会快很多。生产版本记得关掉带敏感信息的日志。
- 上报频率按实际需求定。温湿度每 10 秒一次通常够用，节点多、流量敏感的场景可以考虑在数值变化不大时降低频率。
- 量产前把密钥管理方案定下来，烧录、存储和更换都要提前想好。
STM32 接阿里云本身不算复杂，卡住的多半是协议细节和现场网络。签名参数、时间同步、断线重连这几处想清楚，剩下的基本就是按步骤推进。
