干了几年嵌入式，我慢慢形成一个习惯：凡是做联网设备，板子端只是开始，真正要打通的是“端、云、端”的整条链路。这个项目就是我自己完整走下来的一套实战——用STM32做设备端的数据采集与控制逻辑，接入华为云IoT平台，再写一个基于Qt的跨平台客户端，最终拼出一个能远程看数据、能反向控制设备的智能家居控制系统。标题里的“STM32、华为云IoT、Qt”三个词，对应了硬件端、云平台、应用端三条线，缺一环这条链路都不完整。
我会把这套系统的完整链路逐步拆开，包括硬件选型与接线、STM32固件逻辑、华为云IoT平台的物模型配置、设备鉴权、Qt客户端的界面与API对接，以及联调时我实际踩过的坑。想学嵌入式设备上云全流程的开发者，或者已经在搞STM32但不知道怎么跟云平台对接的朋友，都可以直接参考这套思路。整体难度控制在“入门到进阶”之间，你不需要一开始就懂全部细节，跟着链路走一遍自然就通了。
1. 项目全景：一个智能家居控制系统是怎么被拆解的
1.1 为什么选这三件套
这类项目常见的组合很多，比如纯ESP8266/ESP32 + 某云平台，或者树莓派 + Node-RED。但我最终还是选了STM32 + 华为云IoT + Qt，主要原因是每一层都想拿一个“有代表性”的工具来练手。
STM32代表的是资源受限的MCU端开发，它不直接跑Linux，也没有完整网络协议栈，所以你要学会怎么用UART外挂Wi-Fi模块、怎么在裸机上处理传感器时序、怎么拼装JSON报文。这些能力是后面做任何嵌入式产品都躲不掉的。
华为云IoT平台承担的是设备接入、数据存储、命令下发这类脏活。选它不是因为“只能选它”，而是它的设备接入协议和物模型建模方式很规范，基本能代表物联网平台的主流玩法。在这里你能学到产品、设备、服务、属性、命令这些概念，以后换其他平台理解成本也很低。
Qt则是客户端UI层面最稳的选择之一。Windows、Linux、macOS一套代码编译三份，界面逻辑全用C++写，跟嵌入式端还能共用一部分数据结构和JSON处理的思路。做上位机工具、调试助手、甚至产品的正式控制面板，Qt都够用。
1.2 端到端的数据流长什么样
这个系统的核心数据流其实只有两条，理解它们后面的代码就是往这两个方向填东西。
第一条是设备上报链路：STM32读传感器得到温度和湿度等数据，通过串口交给Wi-Fi模块，Wi-Fi模块以MQTT协议发布到华为云IoT平台。平台把最新状态存进设备影子，Qt客户端通过HTTP API定时查询设备影子，把实时数据渲染到界面上。这条链路解决的是“远程看数据”。
第二条是命令下发链路：用户在Qt界面点击“打开继电器”按钮，Qt调用华为云IoT的平台接口下发命令，平台把命令推送给你绑定好的STM32设备，STM32收到命令后翻转GPIO，控制继电器通断。这条链路解决的是“远程控设备”。
两条链路共同构成了“云管端”的闭环。很多教程只教你单向上报或者单向控制，但实际上双向跑通之后，你才会对设备联网的本质有感觉：数据不是目的，数据驱动设备动作才是目的。
2. 硬件端：STM32与传感器执行器的搭配细节
2.1 元器件清单与接线思路
我用的主控是STM32F103C8T6，也就是大家常说的“蓝丸”。之所以选它，是因为例程多、引脚够用、价格也便宜，拿来做智能家居控制端完全够用。
其余元器件大致分三类：
- 传感器类：DHT11温湿度传感器、BH1750光照强度传感器。DHT11用单总线协议，BH1750走I2C，两者都很有代表性。
- 执行器类：一个5V继电器模块，用来模拟控制灯光或者风扇的开关。智能家居嘛，最终都得落到开关控制上。
- 联网模块：ESP8266-01S，通过串口与STM32通信。它刷AT固件之后，STM32只需要发送AT指令就能让它连接Wi-Fi和MQTT服务器，不用去折腾TCP协议栈。
接线方面，我建议DHT11的数据脚接PA0，BH1750的SCL和SDA接PB6和PB7（也就是STM32的I2C1引脚），继电器控制脚接PA1。ESP8266的TX和RX分别接STM32的USART2的RX和TX，注意是交叉连接。电源部分建议STM32和ESP8266分开供电，或者用一个可靠的5V/3.3V稳压模块，否则Wi-Fi模块发射瞬间的电流抖动容易让MCU复位。
提示：DHT11上拉电阻要接，这算是经典坑了。我第一版没加上拉电阻，读出来的湿度数据偶尔是255，查了半天才发现是信号线电平不稳导致的。
2.2 传感器采集与继电器控制的固件逻辑
STM32端固件说白了就是一个循环状态机：定时采样传感器，打包成JSON，通过USART2发给ESP8266；同时监听USART2接收缓冲区，一旦收到平台下发的命令就解析并执行。
DHT11读取时序在代码里写起来比较啰嗦，关键点是主机先发开始信号，然后释放总线，等待DHT11的80us低电平和80us高电平，再一位一位读数据。每一位的“0”和“1”区分方式是看高电平持续的时间：约26-28us算0，约70us算1。我用一个us级别的延时函数配合GPIO读取实现，核心逻辑可以概括成这样：
uint8_t dht11_read_data(uint8_t *humidity, uint8_t *temperature) { uint8_t buf[5] = {0}; // 主机拉低18ms开始信号后释放 DHT11_OUT_LOW(); delay_ms(18); DHT11_OUT_HIGH(); delay_us(30); DHT11_IN_MODE(); // 等待响应信号 if (DHT11_READ() == 0) { while (DHT11_READ() == 0); while (DHT11_READ() == 1); // 读取40bit数据 for (int i = 0; i < 40; i++) { while (DHT11_READ() == 0); uint32_t start = get_us_tick(); while (DHT11_READ() == 1); uint32_t duration = get_us_tick() - start; if (duration > 50) { // 高电平超过50us视为1 buf[i / 8] |= (0x80 >> (i % 8)); } } // 校验后赋值 if ((uint8_t)(buf[0] + buf[1] + buf[2] + buf[3]) == buf[4]) { *humidity = buf[0]; *temperature = buf[2]; return 0; } } return 1; }BH1750就简单多了，标准I2C协议，读两个字节转成光照值，直接在main循环里调用底层I2C读取函数即可。
继电器控制我设计为PA1输出高电平吸合，低电平断开。收到平台命令后，解析JSON里的switch字段，等于1就拉高，等于0就拉低。解析JSON我建议用一个轻量的cJSON库，RAM占用不大，STM32F103完全跑得动。
2.3 ESP8266的AT指令上云流程
STM32本身没有网络协议栈，所以要把“上云”这件事外包给ESP8266。我用的ESP8266-01S默认带AT固件，通过串口发AT指令就能完成动作。
连接流程大致是：
AT+CWMODE=1 // 设为Station模式 AT+CWJAP="你的WiFi名称","你的WiFi密码" // 连接路由器 AT+MQTTUSERCFG=0,1,"clientId","username","password",0,0,"" AT+MQTTCONN=0,"接入地址",1883,1这几个AT指令你要特别注意。MQTTUSERCFG里面的clientId、username、password不是随便填的，它们是从华为云IoT平台生成并经过签名计算得到的，具体计算方式我在下一章讲。AT+MQTTCONN里面的接入地址，就是你创建产品后控制台给你的MQTT接入地址，端口默认1883。连接成功之后，上报数据就发这一条指令：
AT+MQTTPUB=0,"$oc/devices/设备ID/sys/properties/report",\"报文内容\",0,0STM32端只需要在采样周期到了之后，拼接好JSON字符串，再组成完整的AT指令通过串口发出去就行。为了不让指令拼接出错，我建议先用一个缓冲区把AT指令整体格式化好，再一次性写入串口，别一个字符一个字符地挤。
3. 华为云IoT平台：物模型和设备接入的底层逻辑
3.1 创建产品与设备时的关键设计
进入华为云IoT平台控制台后，第一件事是创建产品。产品名可以叫“智能家居控制终端”，所属行业选“智慧家居”，联网方式选“MQTT”，数据格式选“JSON”。
创建产品之后，平台会分配一个产品ID，后面设备接入时要用。接下来是添加服务，这个步骤很多人会跳过，但它才是物模型的核心。我定义了这样两个服务：
| 服务ID | 属性或命令 | 数据类型 | 说明 |
|---|---|---|---|
| Environment | temperature | float | 温度上报 |
| Environment | humidity | float | 湿度上报 |
| Environment | light | int | 光照强度上报 |
| LightSwitch | switch | int | 继电器开关状态 |
| LightSwitch | SetSwitch | int | 命令：设置开关状态 |
服务ID在后续报文里会反复出现，必须和上报JSON里的service_id字段完全一致，否则平台会报“数据格式不符”。这一点我在联调时吃过亏，后面常见问题里详细说。
创建完产品后，在“设备”页面注册一个真实设备。注册成功后会生成设备ID和设备密钥，密钥只在注册时完整显示一次，一定要立刻保存。后面MQTT连接的密码需要用密钥现场计算，不保存就只能重置设备了。
3.2 设备鉴权参数到底怎么算
华为云IoT的设备接入不同于普通MQTT的账号密码直连，它的密码是用设备密钥对clientId做HMAC-SHA256运算后生成的。这里的clientId也不是随便写的，固定格式是：
{设备ID}_0_0_{时间戳}其中第一个字段是平台生成的设备ID，第二个字段固定填0表示不校验时间，第三个字段0保留，第四个字段是当前Unix时间戳。username就是设备ID本身。password生成伪代码：
import hmac import hashlib import base64 client_id = "{设备ID}_0_0_1700000000" secret = "设备注册时保存的密钥" password = base64.b64encode( hmac.new(secret.encode(), client_id.encode(), hashlib.sha256).digest() ).decode()STM32端不具备Python环境，所以我在固件里用mbedtls的HMAC-SHA256函数做了同样操作。你可以提前在电脑上算好一组固定的clientId和password，烧进固件里做联调，也可以写一个简单的MCU端HMAC函数。前者适合起步，后者适合产品化。
注意：如果你在MQTT调试软件里直接拿设备密钥当密码填，大概率会报鉴权失败。我第一次就是踩了这个坑，后来才意识到HMAC签名这层。
3.3 上报数据报文与命令下发的topic规律
华为云IoT的设备侧MQTT topic格式是固定的，掌握了规律就不用死记：
- 属性上报：
$oc/devices/{设备ID}/sys/properties/report - 属性设置：
$oc/devices/{设备ID}/sys/properties/set/# - 命令下发：
$oc/devices/{设备ID}/sys/commands/# - 命令响应：
$oc/devices/{设备ID}/sys/commands/response/request_id={请求ID}
上报payload的JSON嵌套结构比较严格，正确的格式是这样：
{ "services": [ { "service_id": "Environment", "properties": { "temperature": 27.5, "humidity": 68, "light": 320 } } ] }平台命令下发的payload是这样的：
{ "object_device_id": "{设备ID}", "command_name": "SetSwitch", "service_id": "LightSwitch", "paras": { "switch": 1 }, "request_id": "abc123" }STM32订阅$oc/devices/{设备ID}/sys/commands/#之后，收到这条消息就解析paras.switch字段。处理完成后，按平台要求要向命令响应topic回一条消息，不然平台侧会一直显示命令超时。我后来为了验证这条链路，直接用MQTT.fx订阅命令topic，然后再手动发一条测试命令，5秒钟内就能在MQTT.fx里看到原始下发报文，排查问题非常方便。
4. Qt客户端：跨平台控制面板的完整落地
4.1 Qt工程结构与MQTT和HTTP的关系
Qt端我用了Qt 6.2 + CMake构建。工程结构分成三层：网络层负责跟华为云IoT平台通信，数据层负责解析JSON并维护状态，界面层只做展示和用户交互。
这里要澄清一个容易混淆的点：Qt客户端并不是直接连设备MQTT，而是通过华为云IoT平台的应用侧接口来获取数据和下发命令。原因很简单，设备上报的数据经过平台处理后存放在设备影子中，客户端走HTTP API查询是最规范和通用的方式；命令下发也必须通过平台的API发起，平台才知道推给哪个设备。
所以Qt端主要用到两个东西：QNetworkAccessManager发HTTP请求，QJsonDocument解析返回结果。如果你要实时性强一些，也可以让Qt订阅平台数据转发的消息通道，但那种方案需要额外搭建流转服务，这里先用最轻的定时查询方案。
4.2 获取IAM Token的代码实现
华为云应用侧API请求头需要携带一个有效token。首次调用前，先向IAM接口发POST请求获取token。
// 伪代码简化：实际需要拼JSON body并解析响应头X-Subject-Token QNetworkRequest request(QUrl("https://iam.myhuaweicloud.com/v3/auth/tokens")); request.setHeader(QNetworkRequest::ContentTypeHeader, QStringLiteral("application/json")); QByteArray body = R"({ "auth": { "identity": { "methods": ["password"], "password": { "user": { "name": "IAM用户名", "password": "IAM密码", "domain": { "name": "账号名" } } } }, "scope": { "project": { "name": "cn-north-4" } } } })"; reply = m_manager->post(request, body); // 响应头中的 X-Subject-Token 就是我们要的 token token = reply->rawHeader("X-Subject-Token");拿到token后，后续查询和下发接口都把它塞进Authorization请求头。要注意IAM接口返回速度通常不慢，但是token有有效期，我在代码里做了缓存，还剩十分钟时自动刷新，避免用户操作到一半突然请求401。
4.3 查询设备影子和渲染实时数据
查询设备影子接口的路径格式是：
GET /v5/iot/{project_id}/devices/{device_id}/shadow请求头带Authorization。返回JSON里有一个设备影子数组，其中reported字段就是设备最近一次上报的全量属性。我定时3秒拉一次，然后刷新UI上的温度、湿度、光照和开关状态。
界面渲染我用了QML，状态面板通过信号绑定更新。IO密集操作和UI更新必须注意线程问题，我的习惯是QNetworkAccessManager放主线程，异步信号里直接更新QML属性。实测这种轻量级刷新完全不会卡界面。
void Dashboard::onShadowReceived(const QJsonObject &obj) { const auto reported = obj.value("reported").toObject(); const auto services = reported.value("services").toArray(); for (const auto &svc : services) { QString sid = svc.toObject().value("service_id").toString(); auto props = svc.toObject().value("properties").toObject(); if (sid == "Environment") { m_temperature = props.value("temperature").toDouble(); m_humidity = props.value("humidity").toDouble(); m_light = props.value("light").toInt(); } else if (sid == "LightSwitch") { m_switchState = props.value("switch").toInt(); } } emit dataChanged(); }4.4 下发控制命令的接口封装
下发命令走的是创建命令接口，路径大概是：
POST /v5/iot/{project_id}/devices/{device_id}/commands请求体里要指定service_id、command_name和paras。以继电器开为例：
{ "service_id": "LightSwitch", "command_name": "SetSwitch", "paras": { "switch": 1 } }Qt端用QNetworkAccessManager发POST，拿到的HTTP 201就表示命令已经成功投递给平台。这里有个体验细节：下发成功后界面按钮别立刻置成新状态，要等下一次查询设备影子返回的真实状态匹配后再更新界面。不然设备实际没执行成功，你界面却是“已开启”，用户就会被误导。这个习惯帮我在联调过程中发现了不少次设备端执行异常。
另外，如果想让Qt端在断网或平台临时不可用时还能直接控制局域网内的设备，可以再加一条“本地直连”逻辑，比如让设备同时监听一个局域网TCP端口。但核心演示以云端链路为主，这条作为扩展提一下。
4.5 跨平台打包的几个注意点
Qt的跨平台能力不是“编译一次到处跑”，而是“一套源码到处编译”。Windows上我用MSVC2019_64编译，Linux上换GCC，macOS上换Clang，代码本身不需要大改。
但有几个工程级问题需要提前规避。路径分隔符用QDir::separator()或者/，别手写\\。文件读写用QFile别用标准C库，避免不同平台编码问题。MQTT或者TLS证书文件如果存在项目里，建议用Qt资源系统编译进可执行文件，而不是用相对路径去磁盘找。我一开始图省事直接读相对路径，结果从Windows拷到Linux后程序启动就崩，查了半天发现是证书文件没带过去。
5. 联调实录：平台和设备对接的真实排坑记录
5.1 设备一直离线，问题出在鉴权参数
第一次把ESP8266接上MQTT服务器时，设备始终上不了线。用AT指令查询连接状态，一直返回+MQTTDISCONNECTED。后来逐步排查，发现不是Wi-Fi的问题，而是MQTT密码计算错误。
我当时在电脑上跑Python脚本生成HMAC密码，把clientId里面的时间戳顺手填错了。而且我没意识到clientId的格式必须跟ESP8266的AT指令里设置的一模一样。后来把MQTT.fx作为标准客户端连接同样的参数，总算在日志里看到“password error”的提示，才定位到签名问题。
排查这类问题，我建议养成的习惯是：先在PC端用MQTT.fx连接同样的设备参数，把平台日志里弹出的错误码当作第一手依据。华为云IoT控制台提供设备日志查询功能，上报和连接失败会有错误码记录，这个功能很值得一看。
5.2 数据上报成功但平台看不到具体值
有一段时间设备显示在线，属性也在更新，但控制台里看到的属性值永远是空的。仔细检查上报JSON发现，我把服务ID写成了EnvironmentTest，而产品里定义的是Environment，对不上。平台校验的时候发现服务ID不匹配，直接丢弃了那一条服务数据，但不会断开连接，所以设备在线状态正常。
这个问题很隐蔽。排查手段是在平台日志里查看原始报文，或者干脆在MQTT.fx里面用发布功能手动发一条标准JSON，再对比自己的报文就能看出差异。我后来写了个校验脚本，每次改固件报文格式后先本地校验一遍JSON结构再烧录。
5.3 命令下发总是超时
命令超时通常是两种原因。第一种是设备没有订阅sys/commands/#这个topic，平台把命令推下来设备根本没收到。第二种是设备收到了命令，但执行完后没有回命令响应报文，平台等到超时就判定失败。
针对第一种，我在STM32上电初始化时强制订阅这个topic，并且打印订阅结果是+MQTTSUB: 0,0,1才能确认成功。针对第二种，我在命令处理函数末尾拼装命令响应topic，替换掉request_id后重新发布，确保每次命令都有一个明确的“回执”。联调到后面，我在Qt端配置了命令状态显示，能区分“平台已接收”和“设备已执行”，排查效率一下子高了很多。
5.4 Qt端编译和运行时常见问题
Qt端我自己遇到最典型的坑是证书和网络库的静态链接问题。在Windows上开发时一切正常，打包到Linux虚拟机后发现HTTPS请求全部失败，日志显示TLS初始化不了。原因是我打包时只拷贝了Qt的core模块和network模块的动态库，漏掉了加密库和相关证书插件。解决办法是把Qt编译目录下的tls插件、OpenSSL动态库一起拷到可执行文件旁边的platforms同级目录里。后来我干脆写了CMake的INSTALL规则来自动收集依赖，不再纯手工拷贝。
6. 从Demo走向产品，我的一些扩展想法
这套系统跑通之后，你会发现它其实已经是一个“标准物联网产品”的最小完整形态。再往下走，还有几个方向值得补。
安全方面，演示用的是1883明文端口，真正上线建议走8883 TLS加密通信。华为云IoT平台支持设备侧TLS接入，STM32端可以用mbedtls做证书校验和加密通道搭建。这个改动会明显增加固件复杂度，但安全性提升是必须的。
断线重连和掉线告警方面，Demo阶段ESP8266断网后基本靠手动复位。产品化时可以在STM32端加一个状态机检测网络空闲时间，超过阈值就主动重启Wi-Fi模块或者重新执行MQTT连接。平台侧也可以配置设备离线告警规则，把离线事件推送到你的通知渠道。
数据存储和可视化方面，设备影子的历史数据默认保留时间有限，长期做能耗分析的话，要把设备消息通过规则引擎转发到时序数据库或对象存储，再用图表库做历史曲线。Qt端未来也可以换成Web端或者手机端，只要还是调用同一套应用侧API，上层界面重写成本并不高。
多设备联动方面，可以考虑增加一个“家庭网关”，把多个STM32子设备统一接入，由网关负责上报和转发命令。这样整体架构会变成“设备 - 网关 - 云 - 客户端”，更接近商用智能家居产品的实际形态。
最后分享一个我自己联调时特别管用的技巧：在Qt端加一个“调试日志”面板，把每次HTTP请求的URL、请求体、响应码和关键响应体都列出来，同时把平台日志里的错误信息也拉下来一并展示。这样不管你后续接什么设备、加什么功能，第一现场都在一个界面上，排错不再需要同时打开三四个窗口来回翻。这个习惯帮我省下了大量联调时间，你可以直接抄走。
