企业官网建设流程全解析

1. 这条链路到底有多长：从温湿度传感器到客户端界面，数据走了哪些关卡

想做一个基于STM32、华为云IoT和Qt的跨平台智能家居控制系统，真正劝退人的不是单片机开发、不是云平台注册、也不是Qt界面，而是把这三层串起来的那条链路。我最早调试的时候，传感器数据在平台后台已经能看到，但Qt客户端界面永远是空的；等命令下发的按钮终于有反应了，继电器却又纹丝不动。这种半死不活的状态，几乎每个做物联网项目的人都会经历。

这篇文章就把整个项目的关键环节完整复盘一遍：硬件怎么选型、平台怎么配置、通信怎么设计、固件和客户端怎么写，以及联调时最容易踩的坑都在哪。适合两类人：一是课程设计或者个人项目需要快速落地的学生，二是有传感器和单片机基础、想把手里的设备做远程化改造，但还没理清整体架构的嵌入式开发者。

1.1 三个端各自扮演的角色

硬件端、平台端、客户端这三者的分工其实非常清楚：STM32负责“感知和执行”，它接传感器、读数据、控继电器，把物理世界变成结构化的数字信息；华为云IoT负责“连接和流转”，设备接入鉴权、Topic管理、消息转发、命令下发全都交给平台，我们不需要自建服务器，也不需要维护MQTT Broker；Qt则负责“展示和操作”，把设备的状态实时画在桌面上，把用户的操作变成一条条云平台指令发回设备端。

这三个角色缺一不可。如果没有STM32这一层，传感器数据只能依赖现成的联网模组直接上云，调试方便，但学不到单片机层面的采集和时序控制；如果没有云平台这一层，设备和客户端就得在同一个局域网里通信，一旦换网络、换路由器，或者人在外面，系统直接用不了；如果没有Qt这一层，控制入口就只能停留在AT指令和裸日志上，谈不上“控制系统”。

1.2 数据上行与控制下行的完整路径

上行链路的完整路径是这样的：DHT22温湿度传感器把温度和湿度变成单总线时序信号，STM32用GPIO模拟时序读出数值；BH1750光照传感器通过I2C总线返回一个16位的lux数据；这些数据在STM32里组装成JSON格式的payload，通过UART传给ESP8266模块；ESP8266以透传方式把数据发往华为云IoT的MQTT端口；平台收到设备消息后，会把它推送给所有订阅了对应Topic的客户端；Qt端MQTT客户端收到推送，解析JSON，刷新界面的设备卡片和曲线。

下行链路的方向刚好反过来：用户在Qt界面上点击开关按钮，客户端向平台发布一条命令下发消息；平台把命令路由到目标设备对应的命令Topic，并且带上一个request_id作为本次命令的会话标识；ESP8266收到数据后通过+IPD格式把内容交给STM32；STM32解析出JSON里的字段，拉高或拉低GPIO，继电器动作，灯亮或者风扇转；执行完毕后再主动回一条命令响应，平台把它返回给下发方Qt。这条链路看起来很长，但本质上就是“设备读值上报、界面下发执行”两件事，云平台只是替你在公网上做了一个稳定的中转站。

1.3 为什么选这个组合而不是别的方案

从工程角度来看，这个组合的每一项都是经过权衡的。STM32F103系列在性价比、例程丰富度、资料数量上是嵌入式入门最稳的选择，用到的GPIO、UART、I2C、定时器这些外设，在后续任何一个MCU项目里都能复用。华为云IoT的价值在于把设备接入、鉴权、Topic、命令下发这些物联网的脏活累活都包掉了，个人项目要的是快速打通，而不是先花两周搭一套自己的MQTT服务。Qt则是C++图形界面里跨平台最成熟的方案，同一套代码在Windows、Linux、macOS甚至树莓派上都能编译运行，做桌面控制台非常合适。

也有人会问：为什么不用ESP32直接连云？那样确实能省掉一个MCU，但整个项目的学习重心会从STM32外设编程变成纯粹的ESP-IDF开发，结构上少了一层，反而少了很多可以讲清楚的知识点。为什么不直接用网页端？网页端做数据展示可以，但要长时间维持实时连接、做桌面级的多设备管理和历史曲线，还是Qt这种桌面客户端更顺手。

2. 硬件选型与接线清单：STM32最小系统、传感器模块和Wi-Fi模组的搭配方案

2.1 器件清单与选型理由

硬件部分的选型不需要追求高端，重点是要稳、要资料全、要接线简单。我用的这套组合可以作为参考：

选继电器时要特别注意避开不带光耦的纯机械继电器模块。那种模块在吸合瞬间会产生比较大的反向干扰，如果布线再不合理，主控很容易被拉死或者复位。光耦隔离虽然贵几块钱，但省心太多。

2.2 引脚分配与接线注意事项

我的引脚分配如下表，这几根线是整套系统的基础，接线错了后面所有软件调试都会变得很痛苦：

接线里有几个细节值得单独说。UART2的TX要接ESP8266的RX，RX接TX，这是交叉连接，接成同向的话数据永远收不到。ESP8266模块如果板载了电平转换，可以直接和STM32的3.3V串口连接；如果用的是裸模块，就要确认电平匹配。所有模块的GND必须连到同一个地，否则串口通信的电平参考点不一致，表现出来就是数据乱码、偶发收发错误。

提示：ESP8266发射瞬间电流很大，建议单独供电，不要直接从STM32的3.3V引脚取电。否则Wi-Fi一激活，板载稳压器跌压，STM32直接复位。

2.3 供电与信号调理容易被忽略的细节

继电器模块如果是低电平触发，程序初始化时要先把引脚置为高电平，避免单片机上电瞬间引脚电平不确定导致继电器误动作。HC-SR501上电后会有一段预热时间，期间会输出一次高电平，这是模块自检，不代表真的有人，程序里最好忽略上电后前5秒的输入。

DHT22有个非常容易踩的坑：连续两次读取间隔必须大于2秒，否则读回来的数据可能全是0或者固定值。调试时最典型的怪现象就是“每隔一次读到的数据才正确”，基本都是在循环里反复读而不做间隔控制。

BH1750默认工作在连续高分辨率模式，一次读两个字节；但在强光下数值可能溢出到65535，程序里要识别这个饱和值并切换量程。ESP8266的AT固件版本也影响很大，建议拿到模块先刷到较新的AT版本，旧固件里CIPSEND的时序和返回格式和新版本不一致，很容易造成发送长度不匹配。

3. 华为云IoT平台配置顺序：产品模型、设备注册与接入信息从哪来

3.1 先建产品还是先创建设备：产品模型的定义顺序

平台侧的第一步不是注册设备，而是先创建产品。所谓产品，就是同一类设备的抽象，它决定了你的设备用什么格式上报、平台怎么校验、命令怎么定义。顺序一般是：创建产品 → 在产品下添加服务属性和命令 → 注册设备 → 在设备详情里查看接入信息。顺序一旦乱了，后面可能要反复返工。

创建产品后，要在产品模型里给平台一份“数据字典”。比如我定义了一个名叫sensor的服务，里面添加temperature属性，类型是小数，单位是°C；再添加humidity、light_intensity、human_present这些属性；另外添加一个power_switch属性，布尔型，表示继电器开关状态。平台会根据这套字典校验设备发上来的报文，字段名不一致、单位不在枚举范围内，都会被识别为非法消息。

3.2 设备注册后的三个关键接入参数

设备注册完成后，最重要的三样信息会出现在设备详情里：

1. 设备ID：平台生成的逻辑标识，很多Topic和接入参数里都要用到，可以理解成设备在云端的身份证号。
2. 设备密钥：接入时当作密码使用的一串字符串，泄露之后别人可以冒充你的设备，不要提交到公开仓库。
3. 接入地址和端口：平台控制台会给出MQTT和MQTTS对应的接入域名和端口，这是ESP8266发起TCP连接的目标地址。

还有一个容易被忽视的是产品ID。部分Topic的组包和接入模板里会用到，建议一起存进配置文件备用。这些信息不要散落写在代码各处，最好统一放一个device_config.h，联调时改一处就够了。

最保险的方式是从控制台的“设备调试”页面复制官方给出的MQTT接入模板。不同版本、不同接入方式的ClientId、Username、Password生成规则可能不一样，自己手拼很容易错在细节上，个人项目完全没必要自己搓这套参数。

3.3 平台信息在代码里的对应关系

平台侧的信息和代码侧的用途是一一对应的，把这个对应关系想清楚，写代码时就不会迷路：

一个核心原则是：硬件端和客户端要共用同一套设备配置，字段名、单位、服务ID必须完全一致。很多联调问题最后查出来都是“硬件端改了字段名，Qt端没同步改”，两边各改一半，消息格式对不上，问题表现还很隐蔽。

4. 端云通信方式的设计取舍：为什么我放弃了AT指令里的现成MQTT

4.1 ESP8266的两种用法对比

ESP8266的AT固件实际上自带MQTT相关指令，理论上可以直接用AT+MQTTCONN接入MQTT Broker。但我最后没有走这条路，原因有三个。第一，华为云IoT的Topic结构带有平台前缀，命令下发还区分request_id，AT指令模式下要在有限的命令行里维护订阅和发布逻辑，调试起来非常痛苦。第二，AT固件版本差异太大，换一个固件版本，MQTT指令的细节就可能变。第三，AT指令模式把网络细节都藏起来了，出了问题根本不知道是协议问题还是参数问题。

所以我最终把ESP8266降级成纯Wi-Fi透传管道：TCP连接用AT+CIPSTART建立，之后所有MQTT报文都由STM32自己构造。STM32端只需要实现最小化的MQTT客户端，真正用到的报文类型其实就四种：CONNECT（连接）、PUBLISH（发布）、SUBSCRIBE（订阅）、PINGREQ（心跳），再加上收到数据时的报文类型解析。这个取舍的价值在于：设备端的所有逻辑都集中在C代码里，可以通过串口日志一条一条看到发出的报文，再和平台后台的消息流转记录对比，问题能快速定位到协议层还是平台层。

4.2 Topic的获取与最经济的订阅方式

关于Topic，我只有一个建议：从平台控制台里复制，不要自己手敲。上行数据用的设备消息上报Topic在代码里是一条完整的字符串，发布消息就发到这个Topic上。下行命令订阅要复杂一点，平台通过动态request_id区分不同的命令会话，所以订阅命令路径时要用一种能让所有request_id都落到同一个订阅里的方式，而发布命令响应时则要回填原始的request_id。具体怎么填，以设备调试页面给出的模板为准。

这里有个非常实用的技巧：先把桌面MQTT调试工具当“替身”把平台链路完全测通，再把同样的参数搬到STM32固件里。固件调试时一旦直接上板子，问题就会混在一起：分不清是平台拒绝、Topic写错、JSON解析失败，还是ESP8266串口问题。用MQTTX先跑通一遍，相当于把链路切成两段，问题半径瞬间缩小一半。

4.3 数据格式约定：JSON字段、单位与整数传输

设备消息的Payload我统一使用JSON，上报格式大概是这样的：

{ "services": [ { "service_id": "sensor", "properties": { "temperature": 21.5, "humidity": 60.2, "light_intensity": 300, "human_present": 1 } } ] }

这里有个很关键的点：service_id和属性名必须以平台产品模型里定义为准，大小写都不能错。平台校验不过的时候，后台日志只会告诉你“数据格式错误”，不会告诉你具体哪个字段错了，排查起来很费时间。

嵌入式端用printf组JSON的时候，浮点格式化非常占资源和栈空间。我用的方案是整数传输：温度上报215就表示21.5°C，湿度上报602表示60.2%，Qt端收到后统一除以10。这样既避开了嵌入式浮点打印的麻烦，也减少了平台侧做数据类型判定时的意外。建议在项目一开始就约定好单位和小数位，而不是等联调出问题了再回头改协议。

4.4 QoS选择背后的语义

MQTT的QoS选择不是越小越好，也不是越大越好。数据上报我用QoS0或1都行，因为平台不是最终消费方，偶尔丢一条，下个采集周期又会补上；但Qt端订阅设备消息时建议用QoS1，避免平台推送时丢一条导致界面数据断档。命令下发订阅也建议QoS1，因为命令执行这种操作，丢包带来的影响比数据丢失严重得多。QoS2在大多数物联网场景下没有实际意义，平台支持也有限，尽量不要用。

还有一个容易被误会的点：设备离线时，平台对命令下发可能会走缓存策略，设备重新上线之后才把命令推过去。所以联调时如果改了固件、重启设备，有可能突然收到重启前下的旧命令。这不算bug，是平台正常行为，要把“命令到达时间和下发时间不一定一致”这个前提写进设计里。

5. STM32固件开发实录：采集调度、JSON组包与命令执行的代码骨架

5.1 工程结构：CubeMX初始化加一个清晰的主循环

工程基于STM32CubeMX生成，配置时钟72MHz，UART1用作调试日志，UART2接ESP8266，I2C1接BH1750，PB0、PB1、PA4配置成GPIO，PA1作为DHT22的单总线数据口。调试日志和业务数据分两个串口，这个习惯非常重要，否则日志和数据混在一块，排错时候的精力会被浪费一大半。

主循环里用一个20ms的心跳节拍做任务调度：

• 每2秒读一次DHT22
• 每1秒读一次BH1750和HC-SR501
• 每20秒组装一次JSON并发布数据上报
• 每50ms检查一次串口接收缓冲，解析MQTT收包

这样一个超级循环加状态机的结构就够了，整套逻辑跑起来很稳定，完全不需要引入RTOS。项目规模不大时，RTOS带来的任务切换、信号量同步反而会让代码复杂度失控。

5.2 DHT22读取与数据采集

DHT22读取代码的骨架如下。它的协议很简单：主机拉低总线20ms作为启动信号，然后释放总线等待DHT22响应，之后连续读取40位数据，每1位数据用高电平持续时间来区分0或1。

uint8_t dht22_read(int16_t *temp_x10, int16_t *hum_x10) { uint8_t data[5] = { 0 }; // 启动信号：拉低20ms再释放 HAL_GPIO_WritePin(DHT_GPIO_Port, DHT_Pin, GPIO_PIN_RESET); HAL_Delay(20); HAL_GPIO_WritePin(DHT_GPIO_Port, DHT_Pin, GPIO_PIN_SET); // 等待DHT22拉低应答，并读取40位数据 // 每一位：先等低电平结束，再测高电平宽度 // 高电平宽度>40us为bit1，否则为bit0 // 40位依次存入data[0]~data[4] // 校验 data[0]+data[1]+data[2]+data[3] == data[4] // 温湿度高位在前，分别转成十进制后输出 ... }

这块代码的关键是微秒级延时，不能用HAL_Delay来做，它精度不够。要么用定时器，要么用DWT计数器。另一个容易忽略的点：DHT22的引脚要配置成开漏输出并加上拉电阻，让总线空闲时保持高电平；用推挽输出模拟单总线，应答时序很容易读不对。

5.3 数据上报的组包与发布

上报数据的组装我放在一个函数里，用整数方式免去浮点问题：

char payload[128]; snprintf(payload, sizeof(payload), "{\"services\":[{\"service_id\":\"sensor\",\"properties\":{" "\"temperature\":%d,\"humidity\":%d,\"light_intensity\":%d,\"human_present\":%d}}]}", temp_x10, hum_x10, light, human_state); // 通过ESP8266发送： // AT+CIPSTART=0,"TCP","<平台IP>",1883 // 等返回CONNECT后再执行 AT+CIPSEND=0,<payload长度> // 发送payload内容，等待SEND OK

如果ESP8266的AT固件不支持在CIPSTART里直接填域名，就先执行AT+CIPDOMAIN把平台域名解析成IP，再在CIPSTART里用IP连接。否则老固件会直接报错。这个细节看起来小，但第一次联调时最容易卡在这里。

5.4 下行命令解析与执行

ESP8266在非透传模式下，收到的TCP数据会包在+IPD格式里。STM32在串口接收中断里按状态机收集数据，等到一个完整的+IPD块之后，先判断是不是MQTT PUBLISH报文：解析固定头部得到剩余长度，再跳过Topic字符串，最后读Payload里的JSON。提取power_switch字段后执行GPIO控制，再把命令响应回发到平台的命令响应Topic上。

MQTT报文解析最容易出错的地方是“剩余长度”字段：前128字节时它只有1个字节，超过128字节就要处理进位，如果不处理直接按一个字节读，整个包的解析位置就全错了。我的项目里命令包一般不超过几十字节，没踩到这个坑，但解析器设计时还是建议把multi-byte length处理进去，避免后续扩展时莫名奇妙的错位。

5.5 串口状态机：+IPD粘包问题的代码级处理

串口收包的状态机本身不复杂，核心是按+IPD后面的长度字段收满指定的字节数再提交解析：

typedef enum { WAIT_HEAD, WAIT_LEN, WAIT_DATA } ParserState; // UART2中断里每收到一个字节，按状态机推进 // 发现 '+' 进入WAIT_HEAD，识别到"+IPD,"后读长度len // 然后进入WAIT_DATA，收集满len字节后提交一帧给MQTT解析器 // 不足len就留在缓冲区继续等，不能提前提交

如果不按长度收满就处理，一条TCP报文被拆成两个+IPD时，第二个半包会被当成独立帧解析，结果就是乱码、执行了不能理解的“幽灵指令”，或者协议解析器直接卡死。这个状态机虽然简单，但它是设备端稳定性的地基。

6. Qt跨平台客户端：QWidget界面方案、MQTT封装与多设备卡片刷新

6.1 界面框架选择：QWidget还是QML

Qt端的界面方案，我在QWidget和QML之间选了QWidget。原因很务实：设备卡片、表格、曲线图这些桌面控制台的基础元素，QWidget都有现成控件，文档多、调试简单、资料充足。QML的动画和视觉效果确实更好，但设备列表这种高频刷新场景下，QML的状态管理并不比QWidget省心。

Qt版本建议用5.15 LTS或者6.x，构建系统用CMake。跨平台这件事，最大的坑反而不是Qt本身，而是代码里顺手写的路径分隔符、换行符、本地绝对路径。只要把这些东西都通过API处理，Windows、Linux、macOS上的表现就基本一致。

6.2 MQTT客户端封装与多设备管理

Qt端的MQTT我使用的是成熟的QMQTT库，也可以直接用QTcpSocket自己包一层MQTT协议，逻辑和设备端非常类似。工程上建议封装一个DeviceClient类，把连接、发布、订阅、消息解析都收进类内部：

class DeviceClient : public QObject { Q_OBJECT public: DeviceClient(const QString &deviceId, const QString &secret, const QString &brokerAddr, quint16 port); void connectToPlatform(); void publishCommand(bool powerOn); signals: void sensorUpdated(const QString &deviceId, float temp, float hum, int light, int human); void connectionStateChanged(const QString &deviceId, bool online); private: QMQTT::Client *m_client; };

多设备管理我采用了一个设备一个DeviceClient实例的做法，由DeviceManager统一持有。分开连接的好处是每个设备独立鉴权、独立断线重连，Topic冲突完全不存在。坏处是多占几个TCP连接，但对个人项目来说，几十台设备没有任何压力。

6.3 消息回调与界面刷新的线程关系

QMQTT的消息回调在默认情况下不是主线程，不能直接在回调里操作控件，否则界面偶发崩溃。正确做法是DeviceClient解析完消息之后emit一个信号，由Qt的信号槽机制切回主线程执行界面更新。

我最开始图省事，直接用了lambda接住回调刷新界面，结果运行一段时间后偶尔闪退，查了半天才意识到是跨线程操作UI。后来老老实实走信号槽，问题就消失了。这里不建议用其它捷径，Qt的信号槽做线程切换是这个框架最可靠的设计。

6.4 配置文件和日志面板

设备列表放在JSON配置文件里，路径用QStandardPaths::AppDataLocation获取。这个API在Windows和Linux下返回的是各自规范的目录，天然跨平台。界面右侧加一个只读日志面板，QTextEdit就够用，所有上下行消息都带时间戳打进去。联调复盘时，日志面板是排查问题的第一现场，也是做演示时的底气。

7. 联调实测：五类高频问题的完整排查链路

7.1 设备一直连不上平台：先放弃固件，用桌面调试工具复现

现象：ESP8266能连上路由器，AT+CIPSTART也返回CONNECT，但MQTT就是连接失败或者反复断开。

排查链路：第一步，先用MQTTX这类桌面工具，用同一套设备ID和密钥连平台。MQTTX能连上，说明平台的设备参数没问题，问题大概率出在STM32组装的CONNECT报文或者ClientId/Password处理上；MQTTX也连不上，那就回头检查设备ID是否复制完整、设备是否被禁用、密钥是否正确。第二步，如果连上了但一上报就断，多半是发送了格式非法的报文被平台主动断开。用串口日志抓一次实际发送的数据，重点看十六进制里有没有把字符串结尾的0x00一起发出去。

最后我查到的问题是设备ID里混进了一个换行符。这种不可见字符光看代码是发现不了的，必须用日志或调试工具把参数原样dump出来。

7.2 数据上报成功但Qt端收不到

现象：平台消息跟踪里能看到设备上报记录，但Qt订阅的Topic始终没反应。

排查链路：先在平台侧确认消息流转成功。如果上报记录正常，问题就在订阅侧。对比Qt端的订阅Topic和设备上报Topic是否完全一致，设备ID、路径分隔符都不能有差异；再确认Qt订阅的是不是同一个设备的Topic，多设备项目里把设备ID拼错一位的情况非常常见。最后检查上报Payload的字段和服务ID是否符合产品模型，平台校验失败时消息可能不会正常广播。

这类问题最快定位的方式，是在MQTTX里同时扮演客户端角色订阅设备上报Topic，看能不能收到。MQTTX能收到而Qt收不到，问题就在Qt代码；MQTTX收不到，问题在Topic或平台规则。

7.3 命令下发石沉大海：request_id与命令Topic匹配关系

现象：平台下发命令状态显示成功，设备端却什么都没收到。

排查链路：第一步，确认设备端确实订阅了命令下发Topic，而不是只做了数据上报。很多代码里只写了发布，没写订阅，命令自然下不来。第二步，检查命令下发Topic是否带request_id。平台发的命令地址通常带动态request_id，如果固件订阅的是不带通配的静态完整Topic，命令到达时路径对不上就直接丢了。第三步，确认设备是否在线，离线时平台可能缓存命令，设备重启后才会收到，这时候界面应及时显示“离线”而不是让用户以为发出去了。

解决了订阅问题之后，还要确认收到命令后回发的响应Topic同样带着原始request_id。响应内容和request_id不匹配，平台会一直显示命令等待状态。

7.4 ESP8266数据错乱导致的“幽灵指令”

现象：没有点击任何按钮，继电器偶尔自己动作；或者同一条命令被执行了两次。

排查链路：打开串口日志，发现同一条MQTT报文被拆成了多个+IPD块，而状态机没有按len字段收满就提前进入解析，把残片当成了新帧。+IPD后面的长度是TCP载荷的真实长度，但串口中断一次不保证全部字节同时到达，必须用状态机收集满len字节之后再提交解析，不足就继续留在缓冲区等。

解决之后我把调试日志和业务数据彻底分开：UART1只做日志，UART2只走ESP8266数据。这样MCU认为自己在做什么、网络上实际发生了什么，对一眼就能看清楚，不再混在一起猜。

7.5 界面显示在线但设备实际离线

现象：平台设备状态是“在线”，命令却长时间无响应，重启设备之后又恢复正常。

排查链路：这种情况基本都是TCP底层已经断开了，但设备端没有感知，应用层心跳没有生效。Wi-Fi模块在弱网环境里可能一直停在错误状态，TCP连接断开后不会有主动通知。解决办法是给MQTT加上PINGREQ心跳，周期设在30到60秒之间；平台超过保活时长收不到任何包，会自动释放连接。设备端还要加一个应用层看门狗：如果超过一段时间没收到任何报文，主动重新发起CIPSTART和MQTT CONNECT。

从这以后，我把“设备定期发心跳、客户端定期刷新在线状态”作为标配逻辑写进项目，而不是只在连接成功时更新一次界面状态。

8. 系统跑通之后的进阶路径与一些工程习惯

8.1 从Demo到可用的三个改造点

这套系统跑通之后想真正作为日常工具用起来，至少要补三个能力。第一个是掉线重连：设备每隔一段时间检查心跳，断开就自动重新CIPSTART，再重发MQTT CONNECT，重连间隔按1秒、2秒、4秒指数退避，避免断网恢复时所有设备同时冲击平台。第二个是本地状态留痕：把最近的操作记录和异常状态写进STM32片内Flash，没有网络时也能翻看设备端最后几次执行的指令，对排查问题帮助很大。第三个是多控制端协同：利用平台规则引擎把设备消息复制转发给多个订阅方，Qt端一台、手机App一台，互不干扰；规则引擎配好后，订阅Topic的粒度决定了你看到的设备范围。

8.2 代码分层与调试习惯

固件侧的代码，至少拆成app、transport、parser三层：app管业务逻辑，transport管ESP8266和MQTT收发，parser管JSON和+IPD解析。Qt侧把DeviceClient和界面彻底解耦，UI那一层只处理信号槽。日志是所有收发消息都要打方向和时间戳，格式统一成一行一个事件：TX到平台、RX自平台，拿到平台后台的消息跟踪记录一对比，基本没有查不出来的问题。

加日志这件事，我自己的体会是永远不要省。做成套系统时总觉得日志占空间、占时间，等出了联调问题再补，代价更大。先日志、后功能，是这类项目能按时交付的关键。

8.3 最后说点个人体会

这个项目最大的坑从来不是某个算法，而是“两边都认为自己发了消息”。解决的办法只有一个：把日志做透。设备端一行、客户端一行、平台后台一行，三行对在一起，任何问题都会现出原形。

另外一个特别想说的是，先连通线再写功能。我第一次做的时候，Qt、固件、平台三个都各自写得差不多了才开始联调，连不上时根本不知道是谁的问题，整整折腾了两天。后来我先用MQTTX把平台链路完整打通，再回头写固件和客户端，联调过程基本一天就完成了。STM32+华为云IoT+Qt这套组合打通之后，换传感器、换家电设备，其实都只是改产品模型和报文字段的事，底层的链路和工程骨架可以一直复用下去。