企业官网建设流程全解析

空调开发里真正容易被低估的，是嵌入式通信协议这一层。很多工程师在主控电路、压缩机驱动上花了不少精力，结果联调时发现：板上的传感器读不到数据，室内外机通信失败，Wi-Fi 模块配上网也连不上云平台。最后查下来，多数不是核心算法的问题，而是协议没理清楚——I2C 地址冲突、SPI 极性和相位不对、串口波特率不一致、RS485 接线反了、MQTT 的心跳和 Topic 字段对不上。

这篇文章围绕“从板级到云端”这条主线，把空调开发中常见的嵌入式通信协议按层次拆开。适合刚接触空调控制器开发、智能家电联网、暖通设备协议对接的开发者和做整机联调的嵌入式工程师。最值得关注的点不是记住每种协议的细节，而是搞清楚每一层解决什么问题、选型依据是什么、联调时从哪里查起。

1. 空调开发里谈通信协议，先分清四层链路

1.1 空调内部到底有哪些通信场景

一台空调从硬件结构上看，不是只有一个单片机在跑。主控 MCU 要采集温度、湿度、电流、压力，要控制压缩机、电子膨胀阀、风机，要处理显示面板和按键，要接收红外遥控信号，还要和一个或多个无线通信模块交互。

把这些通信点列出来，至少包含这几类：

• 主控 MCU 与传感器、存储芯片、显示驱动、IO 扩展芯片之间的板级通信。
• 主控 MCU 与 Wi-Fi、蓝牙模块之间的模块通信。
• 室内机控制器与室外机控制器之间的设备级通信。
• 空调通过遥控器、手机 App、智能音箱形成的无线控制链路。
• 设备把运行状态上报平台，再从平台接收命令的云端链路。

很多“联调失败”的根源，是把这些不同层级的通信混在一起排查。板级通信问题表现为数据读不到或显示异常；设备级通信问题表现为内外机状态不同步；云端问题表现为 App 能看到在线但控制不生效。

我建议开发时先按层级拆开，每一层单独验证，再拼成整机链路。否则一段原始字节流从传感器一路传到平台，中间任何一个转发点出错，定位都会非常困难。

1.2 不同层级的协议不是在同一个平面上，选型要先看距离和实时性

嵌入式通信协议经常被列举成 I2C、SPI、UART、RS485、Modbus、CAN、MQTT 这些名称。但严格来说，它们不在同一个协议层次。

I2C、SPI、UART 通常指物理接口和链路层的基础通信方式，传输距离基本限制在同一个电路板或同一个设备内部。RS485 是一种物理层总线标准，常搭配 Modbus 这类应用层协议用于设备间的中长距离通信。CAN 本身包含物理层和数据链路层，可以做到多节点、抗干扰、优先级仲裁。MQTT 是运行在 TCP/IP 之上的应用层协议，设备必须已经有了网络连接才能使用。

选型时看三个条件：

• 通信距离：几厘米到几米，用 I2C、SPI、UART 都合理；几十米以上，普通 UART 就不可靠，要考虑 RS485、CAN 或网络通信。
• 节点数量：只有两个设备通信，UART 简单直接；多个设备共享总线，就要考虑地址机制、仲裁机制或主机轮询机制。
• 实时性和可靠性：控制命令如果丢失，可能造成压缩机不停机或风机不动作，这类数据需要强的校验和重发机制。

下面这张表是我在实际选型时常用的参考，不是绝对标准，具体方案要看整机硬件平台和成本要求。

1.3 先跑通最小链路，不要一次铺完整套方案

空调整机涉及的通信点太多，最容易犯的错误是“所有模块同时调试，出问题不知道先看哪里”。

我更推荐把项目拆成三个最小闭环。

第一个闭环，主控单独跑通板级外设。能读到传感器数据，能往 EEPROM 写入，能控制显示屏。这个闭环验证的是 MCU 本身的驱动和引脚配置。

第二个闭环，跑通主控与通信模块的链路。不管用的是 Wi-Fi 模块、蓝牙模块还是 4G 模块，先用串口或 SPI 确保主控能向模块发数据，模块能返回有效数据。

第三个闭环，才去连云。设备端先不管复杂的业务逻辑，只把一条带时间戳的温度数据上报到平台，看平台能不能收到，收到后能不能再下发一条控制命令回来。

这三个闭环都稳定，再叠加故障处理、批量上报、OTA 升级这些功能。很多项目工期紧，想一次把所有通信都跑完，最后反而花更多时间在定位问题上。

2. 板级通信：先把传感器、存储、显示和通信模块驱动调稳

2.1 I2C 调通很简单，最容易错的是地址和上拉

空调主板上用 I2C 的地方通常不少。温湿度传感器挂在 I2C 总线上，EEPROM 保存故障码和运行参数，IO 扩展芯片也可能挂在同一组引脚上。I2C 的优点是需要很少引脚，多设备可以共用一条总线。

调 I2C 常见的两个坑是设备地址冲突和总线卡死。

设备地址不是随便定的。很多 I2C 芯片会有地址选择引脚，比如把引脚拉高或拉低来改变地址。如果硬件原理图设计时把两个同型号器件的地址引脚接得一样，I2C 总线上就会冲突。软件上看起来是两个设备都能被扫描到，但实际上读写时会互相干扰。

排查这类问题时，我一般会写一个简单的 I2C 地址扫描程序。把总线上所有可能的地址轮询一遍，能 ACK 的地址记录下来。如果扫描结果里出现了没预料到的地址，就先去查硬件地址引脚和器件型号，不要急着改代码。

上拉电阻也容易被忽略。I2C 的 SDA 和 SCL 引脚通常需要外部上拉电阻，阻值太大会导致信号上升沿过慢，传输速度上不去；阻值太小会增大功耗。具体阻值要按供电电压、总线电容和通信速率来定。很多开发板默认能跑，不代表所有批次的板子都能跑，批量生产时要留意器件批次带来的电容差异。

还有一类问题表现为主控读不到数据，但用示波器看 SCL、SDA 都有波形。这种情况优先检查电平是否匹配。如果 MCU 是 3.3V，外设是 5V，直接连接不但逻辑电平可能不满足要求，时间久了还可能损坏引脚。

2.2 SPI 更快，但时钟极性和相位必须对上

SPI 常用于读写 Flash、驱动 LCD 屏幕、连接部分高速传感器。它比 I2C 吞吐量大很多，适合保存日志、字库、开机画面这类需要频繁搬运数据的场景。

SPI 有四根关键信号：SCLK、MOSI、MISO、CS。主控通过 CS 片选来选中某个从设备，同一总线上多个从设备共享时钟和数据线，但同一时间只能有一个设备被片选。

调 SPI 时的第一检查项是 CPOL 和 CPHA，也就是时钟极性和采样相位。主从双方必须在“空闲时时钟电平”和“数据采样边沿”上保持一致。如果主控认为上升沿采样，而 Flash 认为下降沿采样，读出来的数据就会错位。

常见的现象是：写进去的数据能成功，但读出来全是 0xFF；或者读出来的数据整体偏移了一位；又或者某些批次的显示屏幕花屏。出现这些问题时，先不要怀疑芯片坏，把逻辑分析仪接上，对比 SCLK 空闲电平和 CS 拉低期间的数据变化，能很快确认模式是否一致。

SPI 调试还有一个经验：多设备共用 SPI 总线时，CS 的控制时序很重要。如果 CS 没有正确拉低拉高，设备之间的数据会串扰。特别是上次通信结束后 CS 没有释放，可能导致同一个从设备被重复选中，其他设备无法正常工作。

2.3 串口 UART 是所有模块通信的公共语言

虽然 I2C 和 SPI 在板级很常用，但空调主控与 Wi-Fi 模块、蓝牙模块之间，通常会优先选 UART。原因很简单：UART 结构简单、资源占用少、模块厂商的固件普遍支持。

UART 调试时，最基础也最容易出问题的就是参数一致性。波特率、数据位、停止位、校验位必须完全一致。MCU 端配置成 115200, 8, N, 1，模块端或电脑串口助手也必须相同。如果出现收到字符但内容乱码，优先查波特率；如果偶尔丢字节，优先查中断接收和缓冲区处理。

做 UART 通信时要注意共地。主控和模块之间只接 TX、RX 两根线是不够的，双方必须保证参考地一致。很多开发者在实验板上用同一个 USB 供电，忽略共地问题；到了整机里，主控板和通信模块由不同电源供电，如果之间没有共地，通信就会时好时坏。

主控与模块的接线是交叉的。模块的 TX 接主控的 RX，模块的 RX 接主控的 TX。不少人第一次连接时会把两个 TX 直接接在一起，结果全无数据或烧毁引脚。

还有一个容易被低估的问题：怎么从 UART 数据流里切分出一条完整的报文。空调主控给 Wi-Fi 模块发数据，如果每次都只发几个字节，直接按接收中断一帧一帧处理问题不大。但如果一次发 200 字节，MCU 的接收中断会被触发多次，程序需要靠帧头、帧尾、长度字段或超时机制把数据进行组包。

我一般建议在协议里加帧头、命令字、长度、数据区和校验字段。比如：

帧头 0xA5 0x5A 命令字 0x01 数据长度 2字节 数据区 CRC16校验

不要直接用“每收到一个字节就当成完整指令”的处理方式。板级和模块通信很容易拼接错包。

2.4 板级通信验证要有固定的判断步骤

板级通信跑通，可以用几个简单方法验证：

• I2C：读固定寄存器，看能否返回预期值。
• SPI：写一个已知数据到 Flash 或传感器寄存器，再读回比较。
• UART：将模块的发送端和接收端短接，做自发自收测试。
• 使用示波器或逻辑分析仪看波形，确认时钟、数据线电平有实际翻转。

如果波形正常但数据不对，问题基本在软件配置或协议字节序。比如多字节数据有大端小端区别，EEPROM 或 Flash 读取时地址发送顺序也可能不同。拿到错误数据后，先看十六进制字节流，不要把重点放在“十进制结果不对”上。

3. 设备级互联：室内外机通信为什么常走 RS485、Modbus 或 CAN

3.1 板间与设备间通信的物理层差异

空调不是把主控放在一块板上就能解决所有问题。家用分体机通常有室内机和室外机，室内机负责检测环境温度、接收用户操作，室外机负责压缩机和风机的运行控制。部分中央空调系统还要连接多个内机、外机、线控器。

室内外机之间如果只用普通 UART 单端信号，距离稍长就容易受干扰。空调外机附近有压缩机、风机电机、变频功率器件，启动瞬间会产生很强的电磁干扰。一旦外部干扰叠加到单端信号线上，接收端就会把噪声电平误判成数据。

RS485 这类差分总线就是为解决这个问题出现的常见方案。它的基本原理是用两根线之间的电压差来表达逻辑电平，外部共模干扰同时作用在两根线上时，差模电压不会变化太多，所以抗干扰能力比单端 UART 强很多。

3.2 RS485 总线工程细节：A/B 线、终端电阻、接地

RS485 联调时最直接的问题是收不到数据或数据乱码。常见的硬件问题有几种。

第一，A 和 B 接反。很多终端只有一个简单标记，不同厂商对 A/B 的定义可能一致，但接线端子的丝印可能不同。遇到 RS485 通信完全不通，先交换 A/B 两根线试一下。

第二，总线缺少终端电阻。RS485 总线一般在物理链路两端各接一个匹配电阻。没有匹配电阻时，信号在总线末端会产生反射，导致波形变形。距离越远、波特率越高，反射影响越明显。

第三，参考地问题。RS485 虽然使用差分信号，但不是完全不需要地线。通信双方的 0V 基准如果相差太大，超过收发器的共模输入范围，照样会通信失败。在强干扰环境中，通常会使用带隔离的 RS485 收发器，把通信侧与主控侧隔离开。

对空调项目来说，还要注意线缆屏蔽层的接地方式。屏蔽层一般选择单端接地。两端都接地，如果设备之间存在地电位差，屏蔽层上反而可能流过电流，造成干扰。

3.3 Modbus RTU 的常见实现与排错

有了 RS485 物理层之后，还需要一套应用层协议来规定“谁先说话、数据怎么解释”。很多暖通空调方案会选择 Modbus RTU。

Modbus RTU 是一个主从协议。主机发起请求，从机响应。每个从机有唯一的地址，通常 1 到 247。功能码 03 用于读保持寄存器，06 用于写单个寄存器，也有的方案用 16 功能码写多个寄存器。

如果室内外机或电控板之间走 Modbus，最常见的问题集中在从机地址、寄存器地址和 CRC 校验。

从机地址要确保不冲突。同一个总线上如果两个设备都用地址 1，主机会收到两个设备同时回应的数据帧，总线冲突表现为响应数据时好时坏。寄存器地址映射也必须统一。比如室外机把“设定温度”放在寄存器 0x100，那么主机的请求数据也必须指向 0x100。

CRC 校验更是不能省。Modbus RTU 报文末尾有两个字节的 CRC 校验，低位在前。这段代码看起来繁琐，但现场环境里干扰随时可能出现。没有 CRC，主机可能会把受干扰后的错误数据当成有效指令，导致风机或压缩机误动作。

3.4 CAN 总线的高可靠应用与配置

CAN 总线在汽车和工业控制中很常见，部分多联机空调或功能较多的空调系统也会使用。CAN 的优点是节点可以主动发送数据，不需要主机逐一轮询，总线仲裁机制保证高优先级报文优先传输。

配置 CAN 时最关键的是位定时。多个节点必须使用相同的波特率，而且采样点要尽量接近。CAN 波特率的计算和 MCU 的外设时钟有关，如果 MCU 时钟配置改了，波特率可能也会漂移。出现“所有报文都报错”时，先用 CAN 分析仪确认总线上实际波特率。

CAN 终端电阻同样重要。标准做法是在总线两端各接一个 120 欧姆电阻。测量 CANH 和 CANL 之间的终端电阻，如果只有 60 欧姆左右，说明两端电阻都在；如果是 120 欧姆，可能只接了一端。

很多工程师容易忽略 CAN 控制器接收缓冲区的问题。空调报文如果频繁发送，但主控没有及时读取 FIFO，缓冲溢出后新报文会被丢弃。排查时不要只盯硬件，也要看软件是否有被更高优先级任务阻塞导致长时间不进 CAN 中断处理。

4. 遥控与无线：红外、BLE/Wi-Fi 这一层最容易“装完就崩”

4.1 红外遥控：空调开发绕不开的无线链路

红外在很多开发者眼里是“过时技术”，但在空调产品里，红外遥控器依然是标配。红外属于近距离单向无线通信，载波调制在几十 kHz 量级，数据帧中包含引导码、用户码、数据码和反码。

空调红外遥控开发的难点不是“红外”本身，而是编码格式差异和载波时序。不同遥控器厂商可能会采用不同编码协议，即使同一品牌的不同型号也可能不同。开发时不能只看几份 Demo 代码，要先抓取真实遥控器的波形。

如果主控解码失败，优先检查载波频率是否匹配。遥控器的发射管需要用 PWM 或定时器输出指定频率的载波，载波频率不对，接收头无法正常输出脉冲。解码时也要注意接收头输出电平的逻辑。有的接收头空闲输出高电平，收到信号后产生低电平脉冲；有的反向。代码里如果默认用下降沿触发，遇到反向输出的接收头就会失败。

红外信号很容易受到强光干扰，阳光直射、节能灯频闪都可能造成误码。产测时最好在正常室内光照和强光环境分别测试。挡红外发射管或接收头的测试也要列入回归用例，避免因为某个方向上器件被遮挡导致遥控距离明显缩短。

4.2 Wi-Fi/蓝牙模块接入主控，先验证模块链路再谈配网

空调要接入智能家居，通常会选用 Wi-Fi 模块或蓝牙模块。这类模块的一个共同点是：模块内部已经封装了协议栈，主控 MCU 通过 UART、SPI 或 SDIO 与模块交互。

调试这类模块时，我习惯先不看云端，先把主控和模块之间的链路打通。很多 Wi-Fi 模块支持 AT 指令。先用串口工具直接给模块发 AT，确认返回 OK。如果模块经过主控转发才能收到指令，那就先确认主控串口发送、接收是否正常。

模块固件不同，AT 指令集也会变化。同一种模块，版本升级后指令格式可能改变。不要拿旧工程的 AT 指令直接套到新模块上。落地时以模块厂商的指令手册为准。

主控和模块之间的数据格式，最好分成两段看：

• 主控发给模块的“本地数据”，比如让模块进入配网模式。
• 主控需要模块上报到云平台的“业务数据”，比如温度、模式、风速。

两段数据不要混在同一个处理流程里，否则云端协议调整时，本地链路也要跟着改，后期维护成本很高。

4.3 配网方案怎么选：SoftAP 配网、BLE 配网、扫码配网

智能空调第一次使用需要让设备知道家中的 Wi-Fi 账号和密码，这一过程叫配网。配网方案并不是越多越好，要根据产品使用场景来选。

SoftAP 配网是最常见的方案之一。设备开机后先进入热点模式，手机连接设备发出的热点，通过一个本地页面把 Wi-Fi 信息传给设备。这个方案实现简单、兼容好，但操作步骤多，用户手机会短暂断开原有 Wi-Fi。

BLE 配网适合设备本身就带蓝牙模块的方案。手机通过蓝牙把 Wi-Fi 信息传给设备，设备再连接路由器。用户操作体验好，但硬件成本会增加一个蓝牙模块或双模模块。很多空调自带 Wi-Fi 模块但不一定带 BLE，如果机型原本只有 Wi-Fi 模块，做 BLE 配网要改硬件。

扫码配网通常是设备上生成二维码或印有二维码，手机 App 扫码后获取 Wi-Fi 信息，再通过网络发给设备。这种方案对路由器和云平台环境有一定要求，需要设备已经具备一个可信通道。

配网质量问题往往不是界面上“配网成功”就结束。设备配网后能不能稳定连上路由器、能不能获取到 IP、能不能成功连云，都要分开看。产测时要统计首次配网成功率、配网耗时、失败原因分布，而不是只统计“是否弹窗成功”。

4.4 无线通信质量的判断标准

无线通信“能连上”不代表“能用”。空调 Wi-Fi 模块放在室内机内部，金属外壳、电机、电源板都可能对信号造成衰减。整机测试时要看信号强度，不能只看 App 上是否显示在线。

我自己做整机验证时会关注四个指标：

• RSSI：接收信号强度，信号太弱时通信成功率会明显下降。
• 丢包率：局域网内连续给设备下发 100 次命令，记录未响应次数。
• 重连时间：路由器重启后，设备多久能自动恢复连接。
• 弱网稳定性：把设备放在距离路由器较远或隔墙的位置，观察长时间运行是否出现掉线。

如果设备经常在批量测试中“离线”，先不要急着怀疑云平台。把模块串口日志打出来，看模块本地是否已经断网、是否在重连、重连后是否重新订阅了云端 Topic。很多掉线问题的根源是设备本地网络没有恢复，平台侧看起来就是设备离线。

5. 从主控到云平台：MQTT、HTTP、OTA 与设备身份

5.1 空调上云常见的接入链路和协议角色

空调要上云，并不是让主控直接去写 MQTT 报文。现在的主流方案里，Wi-Fi 模块或蜂窝模块会承担网络协议栈。主控只需要把业务数据通过 UART 或其他接口交给模块，模块再把数据封装成 MQTT 或 HTTP 请求发送到云平台。

所以整个链路存在两段协议：

• 主控与模块之间，通常是私有协议，常见的是二进制帧或 JSON 数据。
• 模块与云平台之间，才是 MQTT、HTTP 这类网络协议。

联调时经常出现这样的事：开发者在云平台看到 App 下发了一条命令，设备却没有任何反应。排查后发现问题可能出在主控与模块的串口数据格式不一致。模块收到云平台消息后，要向主控转发，但如果主控没定义对应字段，或者帧头不对，主控就会丢弃消息。

设计产品时，建议把这两段协议分开维护。设备端定义一套“本地控制协议”，云端模块负责把平台消息翻译成本地协议。以后如果换云平台或换通信模块，可以尽量保住主控侧代码不变。

5.2 MQTT 设计：Topic、QoS、遗嘱和心跳要一起考虑

MQTT 是空调设备接云平台时使用最广的协议。它基于发布订阅模型，设备可以上报数据到某个主题，云平台也要订阅设备发布的消息主题；同时设备订阅命令主题，接收 App 或平台下发的指令。

设计 MQTT 时第一件事是理顺 Topic。不要把所有消息都发到同一个主题上。至少分成属性上报、事件上报、命令回复等几类。比如：

dev/{deviceId}/thing/property/post dev/{deviceId}/thing/command dev/{deviceId}/thing/event/post

Topic 越长，报文开销越大。所以要在可读性和效率之间做平衡。只要业务结构清晰，宁可多建几个主题，也不要在一个主题里混入多种消息类型。

QoS 的选择要看业务语义。

• QoS 0：消息最多发送一次，适合高频温度数据上报，丢了下一周期还能补上。
• QoS 1：消息至少送达一次，适合控制命令和设备状态变动，但可能重复。
• QoS 2：确保消息只送达一次，通信开销更高，设备端用得少。

空调设备接收 App 命令时，最怕命令丢。一般情况下建议命令至少用 QoS 1。应用侧要对重复命令做幂等处理，也就是说，接收到两次“设定 26 度”，第二次不能导致状态反复切换。

心跳保活不能设置得太长也不能太短。太长会导致服务器很久才发现设备掉线，太短会增加功耗和网络流量。更稳妥的做法是结合模块所在网络的特性来设置，比如常见设置在 30 到 120 秒之间。实际值要以模块功耗和平台策略为准。

设备恢复连接后，必须重新订阅 Topic。有些设备网络断开后，TCP 连接本身没有及时断开，主控以为还在线，平台却已经清理了会话。日志里要同时记录“本地 socket 状态”和“平台在线状态”，不能只依赖其中一个。

5.3 HTTP/CoAP 用在哪些业务场景

MQTT 适合长连接、低功耗指令交互。但有些业务不适合用 MQTT，比如设备要下载较大的 OTA 固件包、上传运行日志、获取服务器时间，这时 HTTP 更直接。

HTTP 在空调设备端常见的用途包括：

• OTA 升级包下载。
• 设备启动时获取时间戳。
• 设备主动上报一批本地日志。
• 从平台拉取策略配置。

HTTP 接口设计时要注意请求超时。设备端网络不稳定，如果超时时间设置得过短，大文件下载永远完不成。要注意服务器的响应状态码。文件不存在返回 404，权限问题返回 401/403，不能把“收到了响应”当成“业务成功”处理。

CoAP 主要用在资源受限的物联网设备上，基于 UDP，消息比 HTTP 更轻量。空调主机设备一般不会直接跑 CoAP，但在一些电池供电的传感器节点中会出现。如果做的是楼宇空调的传感器采集节点，遇到 CoAP 不代表要给每台空调都上，要按设备资源情况决定。

5.4 设备身份认证、TLS 证书与 OTA 校验

云平台接入必须考虑设备身份问题，不能把所有设备都烧录成同一个设备密钥。一套空调系统中，每台机器要有唯一的设备标识和密钥。这个标识通常由平台侧分配，并在生产阶段写入设备。

设备与云平台之间通常通过 TLS 加密传输。开发阶段常见的坑有三个：证书过期、证书类型用错、设备时间不对。

TLS 握手会校验证书有效期，而很多物联网设备没有 RTC 电池，断电重启后时间回到出厂值。如果设备时间停留在几年前，即使证书正确，握手也可能失败。所以设备上云前，要先保证时间可以通过 NTP 或其他方式同步。

OTA 升级是特别需要校验的环节。固件包下载完成不等于升级成功。下载后要校验文件长度、校验和或消息摘要，比如把云端提供的 MD5 与本地计算出的 MD5 做比较。这里要提醒一点：很多开发阶段“升级失败”的原因并不是代码有 bug，而是下载到的固件包不完整，或者开发者在平台上传固件时填错了版本号，导致设备下载后判断自身版本和固件版本不兼容而拒绝升级。

设备端还要考虑升级失败后的回滚。不要把唯一可用固件覆盖掉，至少要保留一个可启动版本。升级前记录当前版本号，升级后由主控做自检，如果应用无法正常启动，要能回到上一版本。

5.5 云连接稳定性判断：不能只看“在线”

云平台接入功能做完后，要稳定运行一段时间才能量产。判断连接稳定性不能只看“App 能在用户刚打开时看到在线状态”，要看长时间通信质量。

建议统计以下指标：

• 连接成功率：设备每次重连云平台的成功比例。
• 消息上报成功率：设备端发送 MQTT QoS 1 消息后是否收到 ACK。
• 命令下发延迟：从控制指令发出到设备回复命令响应的时间。
• 离线频率：设备每天发生断线重连的次数。
• 重连恢复时间：断线到恢复业务上报的时间间隔。

这些指标可以在设备端打日志，也可以在平台侧看消息轨迹。排查时先看服务器是否收到了消息，再看设备端日志是否发出。两边日志一起看，才能判断问题出在设备、网络还是平台。

6. 从板级到云端的调试链路和排错顺序

6.1 排错顺序：先分层级，再逐层收缩

空调联调最忌讳一上来就怀疑最外层。比如 App 下发命令没反应，直接翻主控业务代码，这样会浪费很多时间。更可靠的顺序是先把问题锁定到具体层级。

按照下面的顺序排查：

1. 先复现现象，确认是“完全没反应”“偶发失败”还是“状态上报不一致”。
2. 判断问题属于板级、设备级、无线链路、云端接入还是 App 端。
3. 从可能有问题的层级入手，先看输入输出，再看配置和代码。
4. 如果是硬件层不稳定，先用示波器或逻辑分析仪看波形，不要上来改协议。
5. 如果是协议层丢包，先抓完整报文，看帧头、长度、校验和停止位。

比如 App 下发“关机”指令，空调没有反应。

先做一次模块直连云平台测试。用 MQTT 客户端模拟设备接入，如果平台下发指令能正常到达设备端，再确认 WiFi 模块到主控的串口数据是否完整。如果模块已经收到云端消息但主控没有动作，问题大概率在主控侧，再继续查协议字段和解析逻辑。

6.2 一份适合空调开发的通信排查清单

下面这些场景是我在实际项目中反复遇到的。按现象标出优先排查动作和常用工具，可以直接作为联调时的工作表。

6.3 工程落地：把单点测试整理成自动化回归用例

人工联调能解决功能性问题，但很难发现偶发问题。比如某台设备运行 8 小时后突然离线，某条 Modbus 报文在特定干扰下偶尔出现 CRC 错误。这类问题要靠长时间自动化回归去捕捉。

自动化回归不需要一开始就做得很复杂。可以从一条“主控—Wi-Fi 模块—云平台”的链路开始：

• 用脚本每 10 秒发送一条属性上报。
• 云端收到后回复一条命令。
• 设备端收到命令后回一条命令响应。
• 如果 60 秒内没有完成上报和响应，就记录一次异常并保留日志。

跑一轮 24 小时自动化测试，异常次数、重连次数、消息延迟就都有了。

日志格式也要提前设计好。设备端、模块端、平台端的日志时间戳必须统一，否则排查时间序列问题时根本对不上。开发阶段的设备日志建议带以下字段：

时间戳 设备编号 消息类型 消息方向 原始数据 错误码

一个小建议：协议字段不要只留下程序变量名，要在文档和日志里写明含义。空调业务的协议字段经常会变，比如“模式”从 0 表示制冷变成 1 表示制冷，如果只改代码不改文档，到下个版本就会踩坑。嵌入式通信协议开发里最贵的成本不是写代码，而是多个开发人员对同一概念理解不一致。

真正把空调从板级做到云端，你会发现最后拼的不是某个单独协议掌握得多深，而是能不能把每层协议之间的连接点理清楚。板卡驱动没跑稳，后面连云越顺利，越容易把板级问题掩盖到云端日志里；硬件电气接口不合理，软件的容错做得再好，也只是在延长问题暴露的时间。先跑通最小链路，再把批量化、异常恢复和产测补上，遇到问题才不会手忙脚乱。