简介：这份消防主机协议列表文档面向消防系统集成商、工程师与维护人员，系统整理了多品牌消防主机的通信协议与地址映射规则，用于解决不同厂商设备接入时的兼容性与数据交互问题。资源包为单一PDF文件，大小约129KB，内容以协议条目与版本更新记录为主，便于按主机型号快速检索对应通信方式。文档覆盖部件地址映射方法0至方法6、波特率设定、事件应答机制、地址重映射及通讯故障监控等关键知识点，并记录了青岛鼎信、西门子FS720、SIMPLEX_4100U、安舍_IQ8、赋安FS5050等协议的修订细节，如0xEB字符处理、模块地址加1000映射、继电器号作区号等。目前已有2637人学习下载，适合需要对接多品牌消防主机、排查通信异常或完善协议兼容方案的技术人员参考，可帮助快速定位地址映射规则与协议变更要点，提升系统集成与调试效率。
1. 消防主机协议列表：一份让集成商少走弯路的串口通讯速查手册
做消防系统集成的同行大概都遇到过这种场景：项目现场摆着一台十年前的老主机，厂家技术手册早丢了，上位机要接进来做集中监控，却不知道这台主机的串口参数、地址映射规则、通讯故障监控逻辑。打电话问厂家，对方说“我们只支持自己的CRT软件”；翻遍网络，能找到的只有零散的几页截图。这时候如果手头有一份按品牌、按型号整理好的协议速查表，能直接查到波特率、校验位、地址映射方法，至少能省掉两三天试错时间。
这份《消防主机协议列表_V1.0_20171116.pdf》就是干这个用的。它把海湾、松江、北大青鸟、西门子、能美、NOTIFIER、赋安、泰和安、安舍、青岛鼎信等几十个品牌的消防主机通讯协议参数汇总成一张大表，每条协议标注了串口通讯参数（波特率、校验位、数据位、停止位）、是否监控通讯故障、部件地址映射方法编号，以及适用主机型号的备注。它不是协议原文，而是一份“索引+参数速查”文档，适合消防系统集成商、上位机软件开发者和现场调试工程师在配接第三方监控平台时快速定位参数。2017年11月这个版本已经积累了130条协议条目，从2016年4月的初始版本一路迭代过来，更新记录里能看到大量“增加某主机协议”“修改地址映射方法”“解决某故障问题”的痕迹，说明它是跟着实际项目反馈在持续维护的。
2. 协议表怎么读：串口参数、地址映射与通讯故障监控
2.1 串口通讯参数：波特率、校验位与停止位的组合逻辑
打开协议表，最先看到的是“串口通讯参数”这一列，格式统一写成“波特率,校验位,数据位,停止位”。比如海湾5000写的是“2400,none,8,1”，意思是波特率2400bps、无校验、8位数据位、1位停止位。能美R21写的是“9600,odd,8,1”，校验位是奇校验。松下EBL8000比较特殊，写的是“4800,even,8,2”，停止位是2位。
这些参数不是随便定的。消防主机串口通讯大多基于RS-232或RS-485物理层，波特率从1200到115200都有分布。低波特率（1200、2400）多见于早期主机，比如无锡中策1用的是1200bps，松江2002用的是2400bps。高波特率（115200）出现在数据量较大的场景，比如西门子PDS(BC80)和日环8412打印口。校验位方面，绝大多数协议用none，少数日系主机用odd或even，比如能美系列统一用odd，松下和SIMPLEX用even。
实际配接时，上位机串口初始化代码需要按表里的参数逐项设置。以Python的pyserial为例：
import serial # 以海湾5000为例：2400,none,8,1 ser = serial.Serial( port='COM3', # 根据实际接线调整 baudrate=2400, # 对应表中波特率 bytesize=serial.EIGHTBITS, # 数据位8 parity=serial.PARITY_NONE, # 校验位none stopbits=serial.STOPBITS_ONE,# 停止位1 timeout=1 # 读超时1秒，避免阻塞 )这段代码的关键在于parity和stopbits必须和表里完全一致。我见过有人接能美R21时用了PARITY_NONE，结果收到的数据全是乱码，换成PARITY_ODD就正常了。另外注意，表里有些协议标注了“不监控消防主机通讯故障”，协议名称带“NL”后缀，比如“6-3.利达LD128E NL”“8-4.能美_R21 NL”。这类协议在软件逻辑上不需要定时发送巡检命令，也不判断主机是否在线，适合只采集数据的场景。
2.2 地址映射方法：从方法0到方法6的编码规则
地址映射是这份文档最核心的技术点。消防主机上传的部件地址和监控中心平台理解的设备地址往往不是一回事，中间需要一层映射转换。表1定义了7种映射方法（方法0到方法6），每种方法规定了4个字节的部件地址如何拆解成区号、回路号、位号或设备号。
方法0是最基础的一种：BYTE0和BYTE1组成区号（10进制，万位到个位），BYTE2和BYTE3组成位号（10进制，万位到个位）。区号对应回路号，位号对应设备号。海湾5000、北大青鸟、利达LD128E等都用方法0。
方法1在方法0基础上增加了主机号：BYTE0的高位是主机号（范围0~64），低位和BYTE1组成回路号（范围0~999），BYTE2和BYTE3仍然是位号。松江系列、西门子FC18R-PRT、国泰怡安GK601等用方法1。
方法2把主机号扩展到0~640，回路号压缩到0~99，区号占BYTE0，回路号占BYTE1，位号占BYTE2和BYTE3。NOTIFIER系列、能美R23、赋安FS5050等用方法2。
方法3比较特殊：BYTE0到BYTE3直接对应设备号的4个字节，不分区位号。这针对设备号本身就是4字节的用户系统，比如海湾INET01接口卡、西门子FC18/FS720系列。
方法4用于“栋/区/层/设备号”编址方式：BYTE0是设备号，BYTE1是栋，BYTE2是区，BYTE3是层。赋安5058用方法4。
方法5和方法6是后来补充的。方法5在方法1基础上增加了板卡号：BYTE0高2位是主机号，中间2位是板卡号（0~99），BYTE1的低4位是回路号（0~9），BYTE2和BYTE3是位号。营口山鹰转换器3.0用方法5。方法6针对“主机号/回路号/设备号”编址：BYTE0是设备号，BYTE1和BYTE2是回路号（高字节+低字节），BYTE3是主机号。MINIMAX报警主机用方法6。
写映射转换代码时，需要按字节操作。以方法2为例，假设收到4字节部件地址[0x01, 0x05, 0x00, 0x17]：
def map_method2(data): # data为4字节列表，小端格式：BYTE0, BYTE1, BYTE2, BYTE3 zone = data[0] # 区号 = BYTE0 loop = data[1] # 回路号 = BYTE1 # 位号 = BYTE2 + BYTE3*256（小端） device = data[2] + (data[3] << 8) return zone, loop, device # 解析结果：区号1，回路号5，设备号23注意文档里特别说明“所有数据单元按小端格式传输，即低字节在先，高字节在后”。这意味着如果你用C语言做结构体映射，要小心字节序问题。我一般会在代码里显式按字节取值，不依赖结构体对齐。
2.3 通讯故障监控与NL后缀：什么时候该发巡检命令
协议表里有一列“通讯故障”，填“是”表示传输装置需要监控与消防主机之间的通讯状态，通常做法是定时发送巡检命令，主机回复则判定在线，超时未回复则上报通讯故障。填“空”或协议名称带“NL”后缀的，表示不监控通讯故障。
这个区别在实际项目里很关键。比如“6-3.利达LD128E NL”和“6-1.利达LD128E”用的是同一套地址映射方法0，但前者不监控通讯故障。如果你的上位机软件对每条协议都统一发巡检命令，遇到NL协议可能会收到异常回复或者干脆没回复，导致误报通讯故障。常见做法是：在协议配置表里增加一个布尔字段monitor_comm_fault，根据协议名称是否含“NL”或表中“通讯故障”列是否为空来设置。代码逻辑大致如下：
# 协议配置示例 protocol_config = { "6-1.利达LD128E": {"monitor_comm_fault": True, "map_method": 0}, "6-3.利达LD128E NL": {"monitor_comm_fault": False, "map_method": 0}, "8-4.能美_R21 NL": {"monitor_comm_fault": False, "map_method": 0}, } def should_send_poll(protocol_name): cfg = protocol_config.get(protocol_name) if cfg is None: return True # 默认监控 return cfg["monitor_comm_fault"]另外注意，有些协议虽然“通讯故障”列填了“是”，但更新记录里提到“不监控消防主机通讯故障”，比如“8-7.能美N3060”在2017年10月24日增加时标注了“部件地址映射用方法2”，但更早的“8-4.能美_R21 NL”明确不监控。以表中最终参数为准，更新记录只作背景参考。
3. 从协议表到可运行代码：地址映射与二次映射的实现
3.1 用Python实现方法0到方法6的通用映射函数
协议表里定义了7种映射方法，实际写代码时没必要为每种方法写一个独立函数，可以用一个带method参数的通用函数处理。下面是我在项目里常用的实现方式：
def map_address(raw_bytes, method): """ raw_bytes: 4字节列表，小端格式 [BYTE0, BYTE1, BYTE2, BYTE3] method: 映射方法编号，0~6 返回: (zone, loop, device) 或 (device,) 视方法而定 """ b0, b1, b2, b3 = raw_bytes if method == 0: # 区号=BYTE0+BYTE1*256，位号=BYTE2+BYTE3*256 zone = b0 + (b1 << 8) device = b2 + (b3 << 8) return zone, None, device elif method == 1: # 主机号=BYTE0高2位，回路号=BYTE0低6位+BYTE1 host = (b0 >> 6) & 0x03 loop = ((b0 & 0x3F) << 8) + b1 device = b2 + (b3 << 8) return host, loop, device elif method == 2: # 主机号=BYTE0高2位，区号=BYTE0低6位，回路号=BYTE1 host = (b0 >> 6) & 0x03 zone = b0 & 0x3F loop = b1 device = b2 + (b3 << 8) return host, loop, device elif method == 3: # 设备号直接等于4字节小端值 device = b0 + (b1 << 8) + (b2 << 16) + (b3 << 24) return None, None, device elif method == 4: # 栋/区/层/设备号 device = b0 building = b1 zone = b2 floor = b3 return building, zone, (floor, device) elif method == 5: # 主机号=BYTE0高2位，板卡号=BYTE0中间2位，回路号=BYTE1低4位 host = (b0 >> 6) & 0x03 board = (b0 >> 4) & 0x03 loop = b1 & 0x0F device = b2 + (b3 << 8) return host, loop, device elif method == 6: # 设备号=BYTE0，回路号=BYTE1+BYTE2*256，主机号=BYTE3 device = b0 loop = b1 + (b2 << 8) host = b3 return host, loop, device else: raise ValueError(f"不支持的映射方法: {method}")这段代码里每个方法的位操作都对应表1的定义。注意方法1和方法2的区别：方法1的回路号范围是0~999，所以BYTE0的低6位和BYTE1组合成10位回路号；方法2的回路号范围是0~99，只用BYTE1一个字节。方法5的板卡号占BYTE0的中间2位，实际项目中板卡号范围0~99需要更多位，但表里定义如此，按表实现即可。
3.2 二次映射：模块地址+1000解决重号问题
文档表2定义了“设备地址二次映射”，专门针对NOTIFIER、赋安等主机系统。这些系统同一个报警回路内，探测器类和模块类设备地址可能重号，比如探测器地址23和模块地址23同时存在。为了让监控中心能区分，需要对模块地址做二次映射：模块地址+1000。
以赋安FS5050为例，更新记录里写得很清楚：“模块地址映射方法为：映射地址=模块地址+1000；例如：模块地址为23，那么模块映射地址为1023”。NOTIFIER 3030也是同样规则。
实现时，需要在解析出设备地址后，根据设备类型判断是否加1000：
def apply_secondary_map(device_addr, device_type): """ device_addr: 原始设备地址 device_type: 'detector' 或 'module' 返回: 映射后的上传地址 """ if device_type == 'module': return device_addr + 1000 return device_addr # 示例：模块地址23 -> 上传1023 upload_addr = apply_secondary_map(23, 'module') # 1023这个逻辑看似简单，但实际调试时容易翻车的地方在于：设备类型从哪里来？协议表里没有直接给出每个设备类型字段的定义，需要结合具体主机的协议原文判断。常见做法是维护一张设备类型码表，比如NOTIFIER协议里某个字节的bit0~bit3表示设备类型，0x01是探测器，0x02是模块。这部分需要对照协议原文实现，协议列表只提供了映射规则。
3.3 用配置表驱动多协议适配
一个监控平台往往要同时接多种品牌的主机，如果每接一种就改一次代码，维护成本太高。我的做法是把协议表里的参数抽成JSON配置，代码只读配置：
{ "protocols": [ { "name": "3-1.海湾5000", "baudrate": 2400, "parity": "none", "bytesize": 8, "stopbits": 1, "monitor_comm_fault": true, "map_method": 0, "secondary_map": false }, { "name": "23-1.赋安FS5050", "baudrate": 9600, "parity": "none", "bytesize": 8, "stopbits": 1, "monitor_comm_fault": true, "map_method": 1, "secondary_map": true, "secondary_offset": 1000 } ] }代码启动时加载配置，根据map_method调用对应的映射函数，根据secondary_map决定是否加偏移。这样新增协议只需要改配置，不用动代码。注意赋安FS5050的映射方法在更新记录里从方法0改成了方法1，配置表里要写最终值。
4. 避坑排查：协议配接中最容易翻车的五个地方
4.1 波特率对但校验位错，数据全是乱码
现象：串口能打开，但收到的数据字节全是0xFF或随机值，帧头对不上。原因：校验位设置和主机实际不一致。比如能美R21表里写的是9600,odd,8,1，如果代码里用了PARITY_NONE，每个字节的校验位被忽略，但主机发送时带了奇校验位，接收端解析就会错位。解决：严格按表里“校验位”列设置，odd对应PARITY_ODD，even对应PARITY_EVEN，none对应PARITY_NONE。如果不确定，可以用串口助手逐个试，但优先信表里的值。
4.2 地址映射方法选错，设备地址全部偏移
现象：火警上传后，监控中心显示的设备编号和主机上看到的不一致，比如主机显示“1回路23号”，平台显示“5回路23号”。原因：映射方法选错。方法0的区号占BYTE0和BYTE1，方法1的BYTE0高位是主机号，如果该用方法1却用了方法0，区号就会把主机号也算进去。解决：查协议表里该主机对应的“部件地址映射说明”列，确认方法编号。更新记录里提到“31-1.河马HM8000”的映射方法从方法0改成了方法1，如果按旧文档配就会错。
4.3 NL协议发了巡检命令，误报通讯故障
现象：配接利达LD128E NL或能美R21 NL时，平台每隔几秒报一次“通讯故障”，但主机实际在线。原因：NL协议不监控通讯故障，主机不回复巡检命令，平台超时后误判。解决：在协议配置里把monitor_comm_fault设为false，不发送巡检命令，也不做超时判断。协议名称带“NL”后缀的都要这样处理。
4.4 西门子FS720数据包中间出现0xEB导致帧解析失败
现象：接收西门子FS720数据时，偶尔丢帧或解析出错误数据。原因：更新记录里提到“修改‘5-4.西门子FS720’主机协议，修改处理了数据包中间出现0xEB字符的问题”。0xEB可能是帧头或帧尾标志，如果数据区恰好出现0xEB，简单的按标志分割会截断数据包。解决：按协议原文的长度字段读取完整数据包，不要用标志字符做分割。如果协议原文没有长度字段，需要做转义处理，比如0xEB后跟0x00表示数据0xEB。
4.5 模块地址未做二次映射，与探测器地址冲突
现象：赋安FS5050或NOTIFIER 3030主机上，模块23和探测器23同时报警，平台只显示一个设备。原因：没有对模块地址加1000做二次映射，两个设备上传的地址都是23。解决：在解析出设备地址后，根据设备类型判断，模块类地址加1000。注意偏移量是1000，不是100或10000，表2里写得很明确。
5. 进阶用法：用协议表做自动化测试与协议差异比对
协议表除了查参数，还能用来做两件进阶的事：自动化测试用例生成和协议差异比对。
先说自动化测试。接了一种新主机后，怎么验证地址映射代码写得对？我的做法是从协议表里提取映射方法，构造边界测试数据。比如方法2的区号范围0~63，回路号0~99，设备号0~65000。用Python生成一组边界值：
import itertools def generate_test_cases(method): cases = [] if method == 2: for zone in [0, 1, 63]: for loop in [0, 1, 99]: for device in [0, 1, 65000]: # 构造4字节小端数据 b0 = zone # 假设主机号为0 b1 = loop b2 = device & 0xFF b3 = (device >> 8) & 0xFF cases.append(([b0, b1, b2, b3], (0, zone, loop, device))) return cases for raw, expected in generate_test_cases(2): result = map_address(raw, 2) assert result == expected[1:], f"失败: {raw} -> {result}"这样能在不接真实主机的情况下验证映射逻辑。边界值覆盖了0、1、最大值，基本能发现位操作错误。
再说协议差异比对。这份文档有130条协议，很多是同一品牌的不同型号，参数只有细微差别。比如“7-2.SIMPLEX4100_19K2”和“7-3.SIMPLEX4100_9600”除了波特率不同（19200 vs 9600），其他参数完全一样。用脚本把协议表解析成结构化数据后，可以按品牌分组，找出参数差异：
import pandas as pd # 假设已从PDF提取为CSV df = pd.read_csv('protocols.csv') # 按品牌分组，查看同一品牌下不同协议的参数差异 for brand, group in df.groupby('brand'): if len(group) > 1: params = group[['baudrate', 'parity', 'map_method', 'monitor_comm_fault']] if params.nunique().sum() > 4: # 有差异 print(f"品牌 {brand} 存在参数差异：") print(params.to_string())这个思路在接新项目时特别有用：拿到一台主机型号，先查同品牌其他型号的参数，大概率能猜出通讯参数范围，减少试错次数。
最后说一个我自己的习惯。每次配接新协议，我会先把协议表里对应的那一条抄到项目笔记里，包括波特率、校验位、映射方法、是否NL、是否有二次映射，然后写一个最小测试脚本，只做串口打开和原始数据打印，确认能收到数据后再写解析逻辑。这个习惯帮我省掉了很多“以为参数对了其实校验位错了”的返工。从那以后我每次接新主机都强制走一遍这个流程，先通串口再谈协议。希望这份协议列表和上面的排查思路能帮到你。
本文还有配套的精品资源，点击获取
