RS-485电动窗帘中控协议解析：帧结构、CRC校验与联调实现

简介杜亚管状电机开合帘485协议文档面向智能家居集成商、电动窗帘控制开发者和中控调试人员聚焦管状电机与外部设备之间的RS-485通讯规则与数据格式。内容围绕波特率9600bps、8位数据位、1位停止位、无校验等参数展开说明以0x55为起始码的帧结构、设备地址与功能码定义并给出打开、关闭、停止、百分比、删除行程、恢复出厂及情景模式等控制命令和CRC16/MODBUS校验方式附有通讯示例便于排查组网、地址分配与指令下发问题。压缩包共1个PDF文件约303KB适合作为协议速查与联调参考。已有1615人学习对需要对接杜亚开合帘电机、梳理485中控指令的读者具有较高实用价值。1. 给一套电动窗帘做中控方案绕不开 RS-485 这条老总线主机是自研的智能控制板末端挂各家管状智能电机中间只有一份十几页的接口协议。开合帘这个负载看着简单无非打开、闭合、停在中途可 32 台挂到同一条总线上细节全冒出来——地址怎么规划、全控为什么没有回帧、没设行程时百分比命令为什么石沉大海、CRC 从起始码算到哪一字节。这套 A3 版通用开合帘对外接口协议就是一份能直接照着写的电动窗帘中控协议下面按帧结构、命令体系、主机侧实现、联调避坑、验收用例一路拆开适合做窗帘中控对接、拿它当毕设课设里的通信模块或者需要一份可交付协议实现方案的人。2. 报文结构拆解七字段定长帧与 9600-8-N-1 的链路约束协议本身不复杂复杂的是它把「变长」藏在了看起来定长的壳子里。刚拿到协议的人容易照着第一页字段表写一个固定偏移的解析器然后在读命令的返回帧上翻车——返回帧的第 4 个字节是数据长度不是数据地址同一个位置在请求帧里代表的东西完全不一样。所以在动手写代码之前先把链路参数、地址语义、数据域的两种形态和分帧规则这四件事定下来后面所有命令都建立在这四件事上。2.1 串口参数与字符时间9600-8-N-1 为什么动不得协议把物理层钉死在四个参数上波特率 9600、数据位 8、停止位 1、无奇偶校验。这组参数不是建议值是电机固件里写死的主机侧改了任何一项收到的全是乱码而不是报错排查起来非常费劲。9600bps 下一位的时长是 1/9600 ≈ 104.17 微秒一个 8N1 字符含 1 位起始、8 位数据、1 位停止共 10 位约 1.042 毫秒。记住这个数后面算超时、算轮询周期、算半双工方向切换延时都靠它。半双工 RS-485 上还有一个容易被忽略的时序主机把一帧数据交给收发器之后最后一位还在移位寄存器里往外吐此时如果立刻把方向控制脚切到接收总线上的最后一个字节会被截断从机算出来的 CRC 永远对不上而抓包软件看到的发送帧却是完整的。通常的做法是等串口的「发送完成」标志位而不是「发送缓冲区空」标志位再把 DE/RE 拉低用 USB 转 485 模块又不方便读标志位时就发完手动延时 1 到 2 个字符时间也就是 12 毫秒再切接收。还有一点这条总线上所有设备共用一对差分线主机发送期间从机不能应答从机的应答窗口靠协议里的「收到即回」来隐含约定。这意味着一问一答必须严格串行不能一口气把 32 条控制命令全推出去否则从机同时应答会在总线上打架读回来的数据半截是 A 设备的、半截是 B 设备的。2.2 帧头三件事0x55 起始码、双字节地址、功能码一帧完整数据从左到右是七个字段起始码 1 字节、设备地址 2 字节、功能码 1 字节、数据域 n 字节、CRC 校验 2 字节。起始码固定为 0x55它的作用不是「标识这是本协议的帧」而是给接收方一个字节对齐的锚点——总线上电、插拔、干扰之后接收缓冲区里第一个字节未必是帧头解析器要一直丢弃字节直到遇到 0x55 再尝试组帧。字段长度取值说明起始码1 字节固定 0x55字节对齐锚点ID_L1 字节0x010xFE本设备地址ID_H1 字节0x010xFE上级设备地址兼作组号功能码1 字节0x01/0x02/0x03/0x04读、写、控制、请求数据域n 字节见各命令地址、长度、数据信息CRC_L1 字节低字节从起始码算到数据域末字节CRC_H1 字节高字节低字节先发双字节地址的语义是这套协议里设计得最巧也最容易用错的部分。ID_H 为 0 且 ID_L 为 0 是广播地址总线上所有设备都执行且都不返回数据ID_H 不为 0 而 ID_L 为 0 是群控同属一个 ID_H 组的设备一起执行同样不回数据两个字节都不是 0 才是单机寻址设备收到后立即回一帧。协议没有定义「ID_H 为 0 但 ID_L 不为 0」这种组合实现时别自己发明主机侧组帧时把它当非法参数直接拒绝掉比让它上总线产生不确定行为要安全。地址的合法范围是 0x010xFEID_H 和 ID_L 都不能取 0x00 和 0xFF。出厂默认地址是 0xFEFE恢复出厂设置之后设备地址会退回这个值。同一条总线上的地址不允许重复重复了不会立刻报错而是在群控或者广播之后的单机应答里出现两帧几乎同时到达的情况表现为主机偶尔读到莫名其妙的校验错——这类问题在后面避坑那一章还会展开。2.3 数据域的两种形态无长度字段的控制帧与带长度的读写帧数据域是变长的而功能码决定了它长什么样。控制命令 0x03 的数据域是「数据地址 可选数据」没有长度字段读命令 0x01 的请求帧是「数据地址 数据长度」返回帧却是「数据长度 数据」写命令 0x02 的请求帧是「数据地址 数据长度 数据」返回帧又只有「数据地址 数据长度」不包含写入的值。四种形态摆在一起看帧类型功能码数据域结构示例控制请求0x03数据地址 可选数据55 12 34 03 01 .. ..读请求0x01数据地址 数据长度55 12 34 01 02 01 .. ..读应答0x01数据长度 数据内容55 12 34 01 01 1E .. ..写请求0x02数据地址 长度 数据55 12 34 02 03 01 01 .. ..写应答0x02数据地址 数据长度55 12 34 02 03 01 .. ..这张表值得打印出来贴在显示器边上。写应答不回显写入值是很多人第一次对接时最不能接受的一条——主机发了「设置方向为反向」设备回了帧但回帧里没有那个 0x01于是有人怀疑是不是没写进去反复重发。正确做法是写完立刻跟一条读命令做二次确认而不是指望写应答回显。控制帧没有长度字段这件事直接决定了解析器不能靠固定偏移取数据。同样是 0x03 功能码打开、关闭、停止三条命令的数据域只有一个字节数据地址百分比命令有两个字节数据地址 百分比值设置情景模式也是两个字节。解析时先读功能码再读数据地址然后根据数据地址去查「这条命令该不该有后续数据」是唯一稳妥的路径。2.4 分帧规则1.5 倍与 3.5 倍字符时间具体怎么卡协议规定两个字符之间的间隔不能超过 1.5 倍字符传输时间如果间隔超过 3.5 倍字符传输时间就认为上一笔数据已经接收完毕新的一笔开始。按 2.1 算出来的字符时间1.5 倍约 1.56 毫秒3.5 倍约 3.65 毫秒。接收侧一般直接用 3.5 字符空闲作为帧尾判据但实际工程里我建议把接收超时放到 5 毫秒以上。原因很现实USB 转 485 模块内部有批量上传机制一帧 8 个字节经常被拆成两次上报给上位机两次之间的间隔轻松超过 4 毫秒按 3.65 毫秒判帧尾会把一帧劈成两半两半都校验不过表现为「通信成功率一半一半」。发送侧的约束是字节之间不能有超过 1.5 字符的停顿这条用软件实现起来就是一次 write 把整帧写进串口不要一个字节一个字节地写、更不要在字节之间插入日志打印或者 sleep。3. 命令体系设计四类功能码如何覆盖开合帘的全部动作四类功能码里0x03 控制命令承担了全部动作0x01/0x02 读写真承担了参数配置0x04 请求命令只有一个用途——从机主动请求主机给它分配地址。这套划分方式的好处是动作和配置彻底分开主机侧可以写成两个互不干扰的模块一个负责开合停一个负责参数读写。不好的地方是控制命令的数据地址表特别长而且同一条命令在不同行程状态下返回值不一样得逐条理清楚。3.1 控制命令 0x03九个数据地址覆盖开合停与行程管理控制命令的数据地址一共九个前面六个管动作和行程后面三个管情景数据地址内容附带数据说明0x01打开无支持群控0x02关闭无支持群控0x03停止无支持群控0x04百分比0x000x64掉电后无行程会失效0x07删除行程无删除后百分比不可用0x08恢复出厂设置无地址回 0xFEFE行程清除0x09设置情景模式0x010x14每台最多 20 组0x0A运行情景模式0x010x14未设置的情景不执行0x0B删除情景模式0x010x14支持群控百分比命令是这里唯一的连续量。0x00 表示完全关闭0x64十进制 100表示完全打开中间线性对应。设备正常情况下会把收到的值原样回一帧但如果设备当前没有行程回帧的数据内容会变成 0xFF并且电机不动作。这一条在实际现场出现的频率极高新装的电机没做过行程学习、设备掉电后重新上电丢了行程、刚执行过删除行程或恢复出厂这三种情况下百分比命令都是静默失效的主机侧如果只看「有没有回帧」就判断成功会得到一个完全错误的结论。恢复出厂这条命令要当成危险操作对待。执行之后设备地址回到 0xFEFE所有保存数据被清除行程删除方向、手拉使能、外接开关类型全部回默认值。主机侧最好把它做成需要二次确认的操作并且在执行完之后立刻更新本地的地址表和状态缓存否则接下来发的所有单机命令都会因为地址对不上而超时。3.2 情景模式20 组预置位与返回 0xFF 的三个前置条件每台电机最多存 20 组情景情景号 0x01 到 0x14。设置情景的做法是先把窗帘运行到想要的位置再用 0x09 命令把当前位置存进某个情景号运行情景就是 0x0A 加情景号设备会自己跑回那个位置。这个设计和主机侧常见的「一键离家」「观影模式」正好对得上所以实际项目里情景模式用得比百分比还多。问题在于它有前置条件而且是三个叠在一起设备当前没有设置行程、或者情景号压根没设置过、或者设备掉电重上电之后行程丢了这三种情况下设备都返回 0xFF 表示拒绝电机不动。设置情景、运行情景都会踩这个坑删除情景倒是宽松一些。工程上的处理方式是把「行程是否有效」当成一个独立状态来维护而不是等命令失败再去猜。主机侧在设备上线之后先读一次当前位置数据地址 0x02返回值落在 0x000x64 之间说明行程有效返回 0xFF 说明没行程把结果缓存下来后续凡是涉及百分比和情景的命令先查缓存无效就先下发一次打开或关闭命令让电机完整跑一趟把行程找回来再发百分比或情景。这套自动纠偏逻辑看着多余能省掉现场一大半的电话。3.3 属性读写0x01/0x02 的属性表与只读边界读写命令只对单台设备有效广播和群控下不响应。属性表如下数据地址属性取值范围权限0x00ID_L0x010xFE可写0x01ID_H0x010xFE可写0x02当前位置0x000x640xFF 表示无行程只读0x03电机默认方向0x00 默认0x01 反向可读写0x04手拉启动使能0x00 开启0x01 关闭可读写0x05电机状态0x00 停0x01 开0x02 关0x03 设置中只读0x27无源外接开关类型0x010x04可读写0x28强电外接开关类型0x000x02可读写0xFE协议版本0xA3只读方向这一项值得单独说。新装的电机有可能电机本体方向和布帘的开合方向是反的表现为主机发「打开」、窗帘却往闭合方向跑。这时候不是控制命令错了而是方向配置不对。做法是先读 0x03 拿当前方向再写入相反的值之后打开命令就会和电机实际运行方向一致。这一条在协议里写得很清楚但现场很多人第一反应是去改控制命令的语义把打开和关闭反过来调结果换了另一批电机又不对了。电机状态 0x05 是 A3 版才有的属性读一次就能知道电机在停、在开、在关还是在设置状态比靠「刚发过什么命令」去推断靠谱得多。主机侧的界面状态建议直接以这个属性为准命令下发只作为期望值实际状态靠轮询刷新两者对不上就说明有异常。3.4 地址分配从机 0x04 请求与 10 秒握手的完整时序新设备地址是 0xFEFE挂到总线上和别的设备重地址就麻烦了所以有一套从机主动请地址的流程设备通电按住电机上的设置键约 5 秒指示灯闪两次后松手从机以默认地址 0xFEFE 主动发一帧请求内容形如55 FE FE 04 01 .. ..主机收到后在 10 秒内下发写地址命令由于此时还不知道设备的新地址这帧用广播地址发55 00 00 02 00 02 ID_L ID_H CRC_L CRC_H写入成功设备指示灯连闪 5 次并按新地址回一帧写应答写入失败地址保持原样不变。这里有两个细节。写入命令里的数据顺序是先 ID_L 后 ID_H和帧头里的地址字节顺序一致别搞反广播帧发出去之后设备是按新地址回帧的所以主机的接收端不能只等广播地址的应答得改成「收到任何一帧 0x02/0x00 功能的应答都当成成功」再拿帧头里的地址去更新本地地址表。分配之前的地址规划我一般会按「ID_H 当组号、ID_L 当组内序号」来定同一层楼或同一个房间的窗帘用同一个 ID_H组内从 01 开始编号。这样做的好处是群控直接复用这套编号发一帧 ID_H 非零、ID_L 为零的广播就能整组联动不用主机侧维护一张组员列表逐台下发。分配完成后建议读一遍 0xFE 协议版本既能确认设备在线也能确认对端确实是 0xA3 版本避免新旧版本混挂时行为不一致。4. 主机侧实现CRC-16 校验、组帧与收发状态机协议看懂了落到代码上还有三件事要处理校验算法得写对帧的组装和拆解要能区分四种数据域形态广播和单机的收发路径不能混在一起。这一章给的是可以直接改参数拿去用的 Python 实现跑在树莓派或者工控机上都行换成 C 也只是照着翻译。4.1 CRC-16/MODBUS 的落地写法与一次自校准校验用的是 CRC-16/MODBUS宽度 16 位多项式 0x8005初值 0xFFFF从起始码一直算到数据域的最后一个字节不含校验本身。0x8005 在反射实现里写作 0xA001结果不做最终异或低字节先发。def crc16_modbus(data: bytes) - int: CRC-16/MODBUS: poly0x8005(反射写法 0xA001), init0xFFFF, 无最终异或 crc 0xFFFF for byte in data: crc ^ byte for _ in range(8): if crc 0x0001: crc (crc 1) ^ 0xA001 # 多项式反射值 else: crc 1 return crc 0xFFFF这个函数是整个实现里唯一不能出错的地方出错了所有命令都会失败而且失败得很均匀——每一帧都错看起来像是接线问题。建议写完先拿一帧真实报文做一次自校准随便发一条读版本号的命令55 12 34 01 FE 01 .. ..把设备回帧的前 6 个字节含功能码和数据域丢进这个函数看算出来的两个字节是否等于回帧的最后两个字节。对不上先别怀疑代码用串口助手手动发同一帧再看回帧。协议文档里印的示例帧校验值和按标准算法自算的结果有出入是常有的事尤其早期文档以设备实际返回的帧为准是最省时间的做法。校准通过之后把这一组「输入字节 → 期望校验值」写进单元测试以后谁动了这段代码都能第一时间发现。4.2 组帧与解析把字节流拆成命令对象组帧很简单把起始码、地址、功能码、数据域拼起来算校验追加在后头。def build_frame(addr_l: int, addr_h: int, func: int, payload: bytes b) - bytes: addr_l/addr_h 都为 0 是广播addr_h 非 0 且 addr_l 为 0 是群控 assert func in (0x01, 0x02, 0x03, 0x04), 功能码非法 body bytes([0x55, addr_l, addr_h, func]) payload crc crc16_modbus(body) return body bytes([crc 0xFF, crc 8]) # 低字节先发解析比组帧麻烦因为要按功能码走不同分支。读应答的数据域是「长度 数据」写应答是「地址 长度」且不含写入值控制应答是「地址 可选数据」三种结构各不相同用一个通用解析器去套必然错位。def parse_frame(frame: bytes): 返回 dict校验失败或帧不完整返回 None if len(frame) 6 or frame[0] ! 0x55: return None crc_calc crc16_modbus(frame[:-2]) crc_recv frame[-2] | (frame[-1] 8) if crc_calc ! crc_recv: return None func frame[3] result {addr_l: frame[1], addr_h: frame[2], func: func} if func 0x01: # 读应答: 长度 数据 length frame[4] result[data] frame[5:5 length] elif func 0x02: # 写应答: 地址 长度, 无数据 result[reg] frame[4] result[length] frame[5] elif func 0x03: # 控制应答: 地址 可选数据 result[cmd] frame[4] result[data] frame[5:-2] # 打开/关闭/停止时为空 elif func 0x04: # 从机请求分配地址 result[req] frame[4] return resultresult[data] frame[5:-2]这一行是控制帧的通用处理打开、关闭、停止这类命令切出来是空 bytes百分比和情景命令切出来是一个字节调用方按cmd判断要不要读。这是我在几种写法里试下来最不容易出错的一种比在每个分支里硬编码偏移量好维护。接收侧还要处理粘包和断帧。串口读到的是一段字节流可能半帧、可能一帧半、也可能两帧粘在一起。做法是维护一个缓冲区不断往里面追加然后循环做三件事找到第一个 0x55 之前的字节全部丢弃从 0x55 开始按功能码推算这一帧应该有多长长度够了就切出来交给parse_frame不够就等下一批数据。读应答的长度是动态的得先读到第 5 个字节才知道整帧多长所以「推算长度」这一步本身也要分两步走。4.3 广播与群控没有回帧时的超时策略协议明确规定全控时设备不返回数据群控同样不回。这一条如果没在代码里体现最典型的后果是主机的发送队列被广播帧堵住——每发一条广播就等 50 毫秒超时、重试两次一次整组联动要卡掉一两百毫秒界面上看就是按钮按下去半天才有反应。def send_command(link, addr_l: int, addr_h: int, func: int, payload: bytes b, timeout: float 0.05) - bool: frame build_frame(addr_l, addr_h, func, payload) link.write(frame) if addr_l 0 and addr_h 0: # 广播: 协议规定无应答, 直接算成功 return True if addr_l 0 and addr_h ! 0: # 群控: 同样无应答 return True reply link.read_frame(timeout) # 单机才进入等待 if reply is None: return False parsed parse_frame(reply) return parsed is not None超时值 50 毫秒是按 2.1 的字符时间推出来的一问一答最多十几个字节传输时间不到 20 毫秒再算上从机的固件处理延时50 毫秒足够。低于 20 毫秒容易误判超时高于 100 毫秒会让轮询周期长得没法用。单机命令失败时重试两次是我一般会保留的容错连续三次失败就把这台设备标记为离线界面上给个灰显别让它继续拖慢整轮轮询。4.4 轮询节奏32 台电机的状态刷新怎么排时间片状态刷新靠读 0x05 电机状态和 0x02 当前位置两条命令一问一答。算一笔账项目数值单帧字节数8 字节9600bps 下传输时间8 × 10 / 9600 ≈ 8.3 毫秒一问一答传输约 17 毫秒加上主机处理与帧间隔按 30 毫秒/台估32 台一轮约 0.96 秒也就是说全量轮询一轮接近 1 秒这个频率对窗帘来说完全够用但前提是中间不能有设备超时。32 台里有 1 台掉线每轮多花 3 次重试 × 50 毫秒 150 毫秒2 台掉线就接近 1.3 秒3 台以上界面就开始明显卡顿。所以掉线设备一定要从轮询队列里摘出去隔几轮再探一次探到了再加回来。另外别在轮询里穿插广播。广播虽然不等待回帧但它占用总线时间而且从机执行动作期间可能不响应读命令混在一起会让轮询的成功率变得很难看。我的习惯是控制走控制通道、轮询走轮询通道中间用一把锁串起来保证同一时刻总线上只有一件事在跑。5. 联调避坑五类现场翻车点的现象、原因与解法协议实现完之后第一次接实物没有一次是顺利的。下面这五条是这类项目里出现频率最高的按链路层、业务层、状态层分了三组每条都按「现象 → 原因 → 解决」写遇本文还有配套的精品资源点击获取