简介：《JK-2020消防主机协议列表_220412》是一份面向消防报警主机集成、调试与维护人员的协议速查资料，系统汇总了蓝天、松江、海湾、北大青鸟、西门子等多个主流厂商数十款主机的通讯协议，涵盖常见国产及进口品牌，解决消防主机对外数据对接时“协议不公开、参数难查”的痛点。压缩包内仅1个PDF文件，大小约260KB，轻量易用，便于离线查找；既适合现场工程师快速查阅，也可作为技术存档与培训资料。内容按厂家、机型逐条列出串口通讯参数（波特率、数据位、停止位、校验位）、通讯故障判定方式（method 0/1/2/3）以及部件地址映射说明，覆盖蓝天5LI、5EI、5SI，松江1501/3101/3208/9108，海湾GST5000、INET03，北大青鸟193K卡，西门子FS720等典型型号；协议版本、接口类型和波特率差异均标注明确，对协议选型、接口连接和故障排查具有很强的实操指导价值。目前已有2796人浏览学习，适合消防维保、楼宇智能化及第三方平台开发人员参考。
1. 消防主机协议列表是什么：一次消防联网对接的起点
做消防联网或楼宇集成时，最尴尬的场面不是你写不出平台，而是报警主机就在机柜里，你却拉不到它的数据。JK-2020消防主机协议列表_220412，就是负责打破这层尴尬的文档。它把火灾报警控制器的串口通讯参数、报文帧格式、点位采集命令、联动控制命令逐条列清楚，让你不依赖厂家驻场，自己就能把火警、故障、联动反馈实时拉到自己平台上。220412这个后缀按惯例是版本整理日期，拿到手第一件事就是确认它和主机固件年代对不对得上，这一点直接影响后面命令码能不能用。这篇文章写给消防维保、弱电集成、平台开发的同行，目标是读完就能照着对接、调试、排错。
2. 读懂220412版本协议列表：串口参数、帧结构与三类命令
拿到协议列表先别急着翻命令表，更别急着写代码。我用十分钟先把前三部分扫完：通讯参数、帧结构、命令码清单。这三样是后面所有工作的地基，漏掉任何一个，调试时都要花几倍时间补课。
2.1 串口参数是协议列表里第一个要核对的信息
协议列表开篇通常是通讯参数页，一般是一张表或一段说明，包含接口类型、波特率、数据位、停止位、校验位、从机地址范围。这些值看起来像标准答案，但真实项目里至少三成对接失败出在这一页：主机面板被人改过设置，你按协议默认值去连，结果收到的全是噪声。我见过一个项目，协议列表写9600 8 N 1，现场主机实际跑的是19200 8 E 1，串口助手挂着半小时没一个完整帧，排查到最后才发现是参数被上一个调试人员改过。
常见的通讯参数配置如下，以你手里的协议列表原文为准，这里列的是消防主机最常见的组合：
| 参数 | 常见值 | 备注 |
|---|---|---|
| 接口类型 | RS232 / RS485 | 看主机背板丝印或接线端子 |
| 波特率 | 9600 或 19200 | 主机系统设置里可改 |
| 数据位 | 8 | 基本固定 |
| 停止位 | 1 | 基本固定 |
| 校验位 | 无 或 偶校验(E) | 最容易翻车的参数 |
| 从机地址 | 1~254 | 多主机联网时每个地址必须唯一 |
拿到参数后，我的习惯是先去主机面板的系统设置或通讯设置页，把当前值抄出来，再和协议列表对照。两边不一致时以主机面板显示为准，因为协议列表代表出厂默认，现场可能被改过。确认完把最终值写进一个对接参数卡，程序里所有串口配置都从这张卡上抄，不要一边调试一边改。
参数对照完，用串口助手做一次最原始的连通性测试：发一条协议列表里最简单的查询命令（通常是查询主机状态或查询版本），看返回是不是一个完整帧。结果分三种：完全没响应、返回乱码、返回完整帧但校验不过。第一种查线序和接口类型，第二种查波特率校验位，第三种才轮到怀疑协议内容。这一步能快速把物理层问题从协议层问题里剥出去。
2.2 数据帧结构：帧头、地址码、命令码、数据区与校验
协议列表第二页左右是帧格式说明，这是整份文档的心脏。虽然各厂商写法不同，但消防报警主机的串口帧基本逃不出一个骨架：帧头、地址、命令码、数据长度、数据区、校验。每一家只是在这个骨架上改改字段长度和顺序。
| 字段 | 常见含义 | 常见长度 | 说明 |
|---|---|---|---|
| 帧头 | 固定起始字节 | 1字节 | 常见 0xAA、0x7E、0xFE 等 |
| 地址 | 主机或回路地址 | 1字节，少数2字节 | 用于多主机并联 |
| 命令码 | 功能编号 | 1字节 | 区分读火警、读故障、校时等 |
| 数据长度 | 数据区字节数 | 1~2字节 | 有的含地址和命令，有的不含 |
| 数据区 | 业务数据 | 不定 | 点位列表、时间、状态等 |
| 校验 | 帧尾校验 | 1~2字节 | 不同机型算法差异很大 |
拿到协议列表后，先把帧头、地址、命令、长度、数据、校验这六个字段的位置和长度用笔圈出来，再单独找校验说明。校验算法在消防主机上最常见的三种：单字节异或、CRC16-Modbus、CRC16-CCITT。单字节异或是逐字节异或后取一个字节放帧尾；CRC16-Modbus低字节在前；CRC16-CCITT则要额外处理初始值和字节序。
怎么确认是哪一种？协议列表的报文示例里通常会给出一个完整帧，把示例帧用三种算法各算一遍，能和示例里的校验字节对上，就是它。这一步花十分钟，省掉后面几百行代码重写的时间。我会把确认后的算法直接写成独立工具函数并固化下来，后面拼任何命令都用它，避免每处拷贝一份逻辑造成不一致。
2.3 命令划分：查询类、设置类与校时类的差别决定调试风险
协议列表中间几页是命令表，每行一条命令，通常包含命令名称、命令码、发送帧示例、响应帧示例和备注。命令按操作性质大致分三类，用法和风险完全不一样，分不清就会出事故。
查询类是日常轮询的主力：读当前火警、读当前故障、读联动反馈、读屏蔽点。这类命令只读不写，调试时随便发，不会影响主机运行，是我最先跑通的一批。设置类命令则要慎重：远程消音、远程复位、联动输出控制，这些会改变主机或现场设备的实际状态，代码写错或误触发，轻则把主机复位一次，重则让现场继电器误动作。我的习惯是，设置类命令封装成独立函数，绝不在自动轮询逻辑里调用，每次调用前还要加明确的确认步骤。
校时类单独拿出来说。主机内部有实时时钟，所有火警记录、故障记录的时间戳都依赖它。如果你的平台每天校时，校时命令格式写错，主机时间会被写成一个错误值，整条报警记录的时间线全乱。协议列表里校时命令的日期时间格式五花八门：BCD码、ASCII码、逐字节拆分都有，组装和解析都必须严格按原文来。我的建议是，先用查询类命令把所有点位跑通，最后再做校时，降低风险面。
3. 按协议列表写第一个读点位脚本：报文组装与响应解析
协议列表读到心里有数，下一步就是写程序。不管你是做平台开发还是做调试工具，思路都一样：先证明能收发，再解析内容。这一章给出一套可以直接拿走的脚本骨架。
3.1 动手前先花5分钟判断：主机是主动上报还是被动轮询
把串口按参数接好，先不写任何代码，用串口助手挂在那里看几分钟。这个观察直接决定你的程序架构是事件驱动还是轮询驱动。
会看到两种现象之一。第一种是串口里不断有主机主动发来的帧，比如火警变化、故障变化、复位确认时，主机会主动推送事件帧，这是新版协议里常见的"主动上报"能力。如果协议列表里能看到"主动上报帧"“事件主动上传"这类字段，说明主机具备主动推送能力，你的平台只要发心跳保活，事件来了主机自己会推过来，轮询压力可以很小。第二种是串口完全安静，必须由外部发查询命令，主机才响一声，这是经典的问答式协议，也是老机型最常见的形态。
就兼容性而言，被动轮询是最稳的方式，能避开不同版本协议里主动上报行为不一致的坑。本文后面的代码示例基于轮询模型来写，这也是大多数第三方平台接消防主机时的默认选择。如果发现你的主机支持主动上报，可以在轮询框架跑通后，再单独加一个监听端口处理事件帧。
3.2 组装读点位命令：一个可直接改的轮询脚本骨架
下面是一段Python骨架，针对"发查询命令、收响应帧、校验、拆数据区"的通用流程。命令码、帧头、校验算法都以你手里的220412版协议列表为准，代码里标了示例值的地方必须替换成真实值。
# 串口参数先按 2.1 节核对结果填写，下面是占位示例 import serial ser = serial.Serial( port="COM3", # Windows下按实际COM口改，Linux下是/dev/ttyUSB0 baudrate=9600, # 以协议列表和主机面板核对结果为准 bytesize=8, parity="N", # 核对结果是偶校验就改成 "E" stopbits=1, timeout=0.5, # 等待主机应答的超时时间，单位秒 ) # 协议常量：必须替换成协议列表里的真实值 FRAME_HEADER = 0x7E # 帧头示例值，以协议列表为准 HOST_ADDR = 0x01 # 主机地址，多主机并联时逐台修改 CMD_READ_FIRE = 0x31 # 读当前火警的命令码示例值 CMD_READ_FAULT = 0x32 # 读当前故障的命令码示例值 def checksum_xor(payload: bytes) -> int: # 单字节异或校验，对从帧头到数据区末尾逐字节异或 chk = 0 for b in payload: chk ^= b return chk def build_frame(addr: int, cmd: int, data: bytes = b"") -> bytes: # 帧结构：帧头 + 地址 + 命令 + 数据长度 + 数据，末尾补校验 body = bytes([addr, cmd, len(data)]) + data frame = bytes([FRAME_HEADER]) + body check = checksum_xor(frame) # 注意校验范围按协议列表定义 return frame + bytes([check]) def query(cmd: int, addr: int = HOST_ADDR) -> bytes: frame = build_frame(addr, cmd) ser.reset_input_buffer() # 清残留字节，防止读到的响应错位 ser.write(frame) return ser.read(128) # 缓冲长度按实际响应帧调整 def verify_frame(frame: bytes) -> bool: if len(frame) < 5: return False check = checksum_xor(frame[:-1]) # 对除校验位外的内容重算 return check == frame[-1]逻辑说明：一个查询请求由三部分组成。先按帧格式拼好帧头、地址、命令、长度、数据，然后用校验函数算出校验字节接在尾部。query函数封装了清空接收缓冲、发送、读取三步。清空缓冲这一步不能省，如果上一次响应没读完，残余字节会和新响应对接错位，导致整帧解析全部偏掉。verify_frame是刚性检查，校验不过的帧绝不进解析逻辑，宁可打印原始hex排查，也不把错数据带进业务层。
参数说明：timeout=0.5秒是等待应答上限，消防主机串口响应通常在几十毫秒内，0.5秒已留足余量；设太短主机忙时会误判超时，设太长轮询周期被拖慢。read(128)里的128是示例缓冲长度，真实响应帧长度按协议列表的响应帧结构计算，点位多时一帧可能超过这个数。更稳的做法是读到帧头后，解析出长度字段再按长度循环读取，下面解析小节会用到这个思路。
3.3 响应解析：把原始字节拆成点位对象
收到响应帧后，第一件事永远是校验，第二件事是切数据区，第三件事才是业务解析。字段位序必须对照协议列表的"响应帧字段表"，一个字节都不能猜。
def parse_fire_points(frame: bytes): # 先校验，再按长度字段切数据区 if not verify_frame(frame): print("校验失败，原始帧:", frame.hex()) return [] addr = frame[1] # 帧结构按协议列表定义定位 cmd = frame[2] # 应该是 CMD_READ_FIRE length = frame[3] # 数据区长度字段 data = frame[4:4 + length] # 按长度字段精确切出数据区 points = [] # 数据区通常由若干连续点记录组成，每条记录格式固定。 # 这里按 step=4 演示：设备号高字节 + 设备号低字节 + 状态 + 类型 step = 4 for i in range(0, len(data) - step + 1, step): rec = data[i:i + step] point_no = rec[0] * 256 + rec[1] # 示例：点位编号按大端2字节 state = rec[2] # 示例：0=正常，1=火警 if state: points.append({"no": point_no, "state": state}) return points说明：解析的每一步都必须能和协议列表给出的示例帧对上。如果拆完的数据区长度和length字段不一致，先怀疑数据区里是否包含公共字段，比如时间戳、回路号、帧序号。很多厂商在点位列表前会放几个公共字节，不把它们先扣掉，点位就会整体偏移，解析出来的点号全是错位乱码。项目里遇到这种情况，我的做法是把抓到的原始hex贴到协议列表的示例帧旁边逐列比对，比在代码里反复调偏移量快得多。
点位地址解出来后，先别急着接业务，做一步硬核核对：把解析出的点号清单和主机面板上实际显示的点号对照几个，确认编号规则一致，再讨论映射关系。这一步能避免整个平台接了一堆错位点位才发现，返工成本极高。
4. 点位映射才是协议落地的核心：把报文里的数字变成平台上看得懂的报警点
报文里的编号只是一个数字，平台要展示的是一条有含义的报警：哪个防火分区、什么设备类型、叫什么名字。点位映射就是把数字翻译成人话，工作量往往超过协议解析本身。
4.1 一次码、二次码与编码设备号：点位编号必须分清的三套体系
消防主机里点位编号存在两套体系，协议列表里默认用的是哪套，直接决定你看到点号的形态。
第一套是回路加部位的一次码，比如"01-001"，表示第一回路第一部位。这套体系在早期机型上常见，特点是编号短、直观，和图纸上的短路子编号对应得很好。第二套是编码地址（也叫二次码），通常是一位六到八位的数字，比如"001001"，前几位代表回路或区域，后几位是设备编码。协议列表的响应帧里，点位记录给出来的多数是编码地址，少部分给的是回路和部位的组合。
怎么确认是哪套？拿一个真实点位做锚点。主机面板上人工触发一个点位（比如按下某个手报按钮），同时抓取读取火警命令的响应帧，看这个触发点在报文里显示的编号是多少，再和主机面板显示值比对。这个试验一次就能确认编号体系，之后批量解析就放心了。
有经验的工程师会在现场先做一次"点号锚定"：随机挑三个不同回路的点位，逐个触发、逐个抓包、逐个记录。三个锚点确认后，解析程序的边界条件才算真的验证过，不能只看协议列表的文字描述就开干。
4.2 点位类型标记：火警、故障、监管、反馈与屏蔽
消防主机对外提供的点位状态远不止火警一种。协议列表的数据区里，每个点记录除了编号，通常还有一个状态字或类型字段。对不上这张表，平台会把故障显示成火警。
| 类型 | 典型状态含义 | 常见状态值 |
|---|---|---|
| 火警 | 探测器或手报触发 | 1 |
| 故障 | 设备断线、损坏、通讯异常 | 2 |
| 监管 | 监管输入动作 | 3 |
| 反馈 | 联动设备动作后的反馈信号 | 4 |
| 屏蔽 | 点位被人为隔离，不参与报警 | 5 |
注意一个关键细节：同一个点位在不同状态下，会出现在不同的查询命令响应里。比如一个烟感先报故障，随后转为火警；平台上两个事件都要展示，还要能区分先后。如果只查一个命令，就会漏掉一半事件。正确做法是轮询时把火警、故障、反馈、屏蔽四类查询命令都轮一遍，每类结果分别处理。
屏蔽和反馈最容易搞混。屏蔽是维保人员手动隔离点位，点位不再参与报警逻辑；反馈是联动设备（比如水泵、风机）动作后回给主机的信号。混了之后，平台会在屏蔽点位动作时弹出"反馈",干扰值班人员判断。协议列表里这几类点位的类型标记通常在数据区的高位字节，解析时留意是单字节还是多字节的位图，位图的话就要逐位拆。
4.3 从报文到点位映射表：一张表把协议数据变成平台数据
点位映射最终落地成一张表，这是我做每个消防接入项目必建的产物，或者叫点表。初始版本在项目启动时建立，随着调试逐步修正。
| 平台点号 | 主机编码 | 回路 | 部位 | 类型 | 中文名称 | 物理位置 | 所属分区 |
|---|---|---|---|---|---|---|---|
| P0001 | 001001 | 1 | 1 | 烟感 | 1号楼3层电梯厅烟感 | 3F-E01 | A区 |
| P0002 | 002015 | 2 | 15 | 手报 | 1号楼3层楼梯口手报 | 3F-S01 | A区 |
| P0003 | 010002 | 10 | 2 | 消火栓按钮 | 2号楼地库消火栓 | B1-H02 | B区 |
建表的方法也讲究顺序。先在图纸上整理出物理点位清单，包含中文名称、回路、部位、位置；再拿协议列表的编码规则，把物理点位的回路部位换算成主机编码；最后在平台里导入这张表，用真实报警去回验。顺序反过来的话，先抓报文再反查图纸，点位一多就乱了。
最容易被忽略的一步是映射表要和主机面板联动校验。平台部署完后，挑几个点位在主机侧做模拟报警，观察平台是否在正确的位置弹出正确的名称。如果A点位动作结果B点位弹窗，先查映射表的编码列，再查解析代码的字节序，不要改数据。
5. 对接JK-2020的常见问题与排查：5个现场踩坑记录
这一章节是我做了多个消防联网项目攒下来的实际问题，每条都按"现象、原因、解决"三层拆开。你大概率会碰到其中一两条。
5.1 串口能连通但读不到点位，平台上一片空白
现象：串口助手收得到响应帧，校验也通过，但解析出来的点位全是零，或者数据区长度字段显示0。平台里看不到任何点位。
原因：命令码和主机固件不匹配。协议列表是220412版本，但主机固件可能更老或更新，固件升级后部分命令码会调整，主机不认这个命令码时有时会返回空数据区，而不是报错。这是最容易被忽略的地方，因为链路层一切正常。
解决：先去主机面板查"软件版本"或"固件版本"，和协议列表的适用范围说明对照。协议列表里通常会有版本适用范围说明，没有的话，用几条"通用命令"做交叉验证，比如查询时间、查询主机状态。如果连这些通用命令都返回空数据区，基本可以确认固件版本和协议列表不一致，找主机厂家要对应版本协议，不要自己在代码里猜。
5.2 轮询间隔设太短，跑几小时后串口彻底沉默
现象：刚上电一切正常，连跑几个小时后主机串口完全没有响应，重启程序又恢复。短则两小时，长则一晚，总会在某个时刻断掉。
原因：这类报警主机的串口处理在下位机上不是独立任务，而是主循环里的一小段分支。轮询频率过高时，主机来不及处理缓冲区里的请求，缓冲区溢出后串口驱动进入异常状态，之后所有外发请求都被丢弃。有些主机的串口驱动在反复收到校验错误的帧后，也会主动停止对外响应，直到系统复位。
解决：把轮询周期调到300到500毫秒，单条命令失败不要立即重试，等下一轮再发；连续失败5次，主动让出串口2秒钟再继续。这个节奏我调过多个项目，跑一周稳定没问题。调试时也别用50毫秒的间隔做压力测试，一旦主机串口被压死，只能断电复位，没有后悔药。
5.3 校验代码看起来没问题，就是算不对
现象：按协议列表描述的校验算法实现代码，算出来的校验位总是差一两个字节，CRC计算结果完全对不上。
原因：三种常见情况。一是校验范围理解错，多算了帧头或少算了地址；二是CRC的初始值、高低位字节序没对齐，Modbus和CCITT两种算法差的就是这两点；三是协议列表的示例帧来自某一台特定固件的主机，个别版本存在字节序差异，和现网设备不一致。
解决：拿协议列表里给出的完整示例帧，手工逐字节演算一遍，在代码里把异或中间结果或CRC的每一步打印出来，对照第一个不一致的位置；再用CRC计算工具和你的代码逐字节对比。确认算法正确后，把校验函数固化成单元测试，输入示例帧、断言校验位正确，以后任何改动都不会再把校验改坏。
5.4 点位编号和图纸永远对不上
现象：解析出来的点号在平台里全部存在，但和图纸上的物理位置对应不上，比如A区手报弹出来的是B区烟感。
原因：点位编号体系用错了。很多主机同时支持"回路-部位"和"编码地址"两种编号方式，协议列表默认给的是其中一种，而图纸通常按另一种方式标注。如果解析时想当然按默认方式拆，映射表再正确也没有用。
解决：回到4.1节说的锚点试验，在某一个回路上人工触发一个明确点位（比如一个手报），同时抓响应帧，用这个点做锚点反推编号规则。确认规则后，把整个编码换算逻辑写成独立函数，输入图纸点位输出协议编号，在导入平台前就完成换算，而不是直接导入原始编号。
5.5 RS485接线正确但串口就是不通，换线换模块也没用
现象：示波器量RS485的A、B端有波形，但串口助手一个字节都收不到。换了几根线，换了几个USB转串口模块，故障依旧。
原因：这类报警主机的对外串口形态容易被误判。背板丝印可能是RS232或RS485，但如果前面板的调试口是RJ11或DB9，接口电平可能是RS232、TTL或RS485之一。RS232转RS485模块的流向切换也是经典坑，自动流向转换模块在持续双向通讯时偶尔会丢字节或卡在发送态。
解决：先看主机背板接口丝印和协议列表的接口说明，确定接口电平类型，再选对应线缆。调试阶段别用几元钱的自动流向转换线，改用带方向控制的工业级RS485转USB模块，这一类玄学问题能少一半。接线顺序按A接A、B接B，屏蔽层单端接地，别让屏蔽层形成环路。
6. 验证协议对接值得做的一件事：先做收发回环仿真，再做点位比对
协议代码写完别急着上真机，先把真机前的验证做到位，能省掉大量现场调试时间。
6.1 用仿真器把协议先跑通，再上真机减少现场折腾
我一般会写一个回环仿真器：程序启动后监听串口，收到帧就按协议列表的规则回一个构造好的响应帧。这样在办公室就能验证拼帧、校验、解析、点位映射全部逻辑，完全不需要连接真实主机。仿真器的核心价值是确定性：你发的每一条命令，响应的每一个字节都在掌控中，出了错马上能定位。等代码逻辑全部确认后，再去现场接真机，这时候剩下的问题只有物理连接和现场参数两类，排错范围大大缩小。
仿真器的做法不复杂，用一个线程循环读串口，收到帧后解析命令码，按命令码返回预设的构造帧。
6.2 跑一晚点位比对，用日志确认长期稳定性
代码上真机后，别急着验收和交付。我习惯做一件事：通宵跑一晚，第二天上午做点位比对。具体是把平台当晚收到的所有火警、故障、反馈、屏蔽事件导出，和主机面板的历史记录逐条对比，数量和点位编号必须完全一致。这个比对能一次性暴露大部分隐患，比如丢帧、点位类型解析错误、状态翻转漏报。
比对通过后再做一次联动测试：人为触发几个真实点位，观察平台从收到报文到弹窗的延迟，正常应该在1到3秒内。超过5秒说明轮询周期或解析链路有问题，要回头看缓冲和循环读取逻辑。这就是我每次接消防主机的收尾动作，也是被坑过之后养成的习惯。文本协议对接这件事没有太多玄学，无非是把协议列表读透、把报文一条条对清、把点表和主机面板逐点核完，剩下的就是稳定性的时间问题。希望这条路径对你有帮助，能让你少走我走过的弯路。
本文还有配套的精品资源，点击获取
