简介：《消防主机协议列表_V1.0_20171116.pdf》面向消防系统集成商、现场工程师与运维人员，集中梳理多品牌消防主机的通信协议、地址映射与兼容性处理规则，可用于设备接入、协议选型和故障排查。压缩包仅含1个PDF文件，约129KB，篇幅紧凑却按版本更新记录持续补充主机协议与修正说明，便于按时间线追溯兼容性变化。已有2668人学习，说明其在消防主机联网与CRT接入场景中具有较高参考价值。内容覆盖部件地址映射方法、波特率设置、事件ACK应答、地址重映射、模块与区号关联及通讯故障监控等要点，并记录西门子、SIMPLEX、NOTIFIER、安舍、海湾等协议的增补与修订。读者可据此快速理解不同主机的数据交互差异，定位地址冲突、数据包异常和故障处理问题，为系统集成与现场调试提供可查依据。

1. 串口连上了却收不到火警：从“对不上号”开始排查

消防主机接入传输装置，最常见的翻车现场不是线接错了，而是串口打通了、数据也进来了，监控中心却把 23 号模块的火警显示成探测器——或者干脆整条主机的数据全丢。这类问题排查起来最折腾人：现场在机房，日志在平台，协议表在另一个人的电脑里，两头一对不上，就只能靠猜。我见过最典型的案例，是某消防主机调试时模块地址和探测器地址重叠，同一回路里 23 号既有探测器又有模块，上传后监控中心根本无法区分设备类型，火警和故障混在一起，值班人员白跑一趟。这份《消防主机协议列表》解决的正是这类“协议选型 + 地址映射”导致的对接故障，覆盖百余种主机协议和 7 种地址映射方法，适合消防集成调试、传输装置对接、平台接入排障的工程师当作对照表来用。

2. 消防主机协议选型错：三种典型报错与定位顺序

协议列表里一百多条协议，编号从 1-1 排到 52-1，同名主机往往还有 9600、19200、打印口、CRT 卡等多个变体。选错一条，表现出的报错五花八门，但归根结底分三类：数据收不到、数据乱码、数据能收但内容不对。下面按这三类拆开说，每类给出可执行的定位路径。

2.1 收不到数据：先核串口参数，再核协议编号

最基础的排查永远是串口三要素：波特率、校验位、数据位。协议表里每条协议都明确标注了这组参数，但现场最容易出的错是“凭印象填”。比如安舍 IQ8 系列，33-1 是 600,none,8,1，33-6 安舍_IQ8(9600) 才是 9600,none,8,1，同一个品牌不同型号的波特率差了十几倍。再如能美系列，R21 用 9600,odd,8,1，松下 EBL8000 却是 4800,even,8,2——注意最后一位是停止位 2，不是常见的 1。

按下面的顺序核一遍，能排掉大部分“收不到”的故障：

# 串口参数核对顺序，以 Linux 下 stty 为例 stty -F /dev/ttyS1 9600 cs8 -parenb -cstopb # 9600,none,8,1 无校验 1 停止位 # 能美 R21 这一路是奇校验，参数要改成： stty -F /dev/ttyS1 9600 cs8 parenb parodd -cstopb # 松下 EBL8000 是偶校验 2 停止位： stty -F /dev/ttyS1 4800 cs8 parenb -parodd cstopb

parenb打开校验，parodd表示奇校验、不带它则是偶校验，cstopb表示两位停止位。参数填错时，串口驱动通常不报错，数据进缓冲区就是一堆无效字节，表现为“端口有数据但解析不出来”。这一步过了还收不到，再去看协议编号：同一主机若有“打印口”“CRT 卡”“转换器”等后缀，说明物理接口不同，接的是打印机口就不能选主机串口协议。比如 3-4 海湾 9000 打印口、22-3 营口山鹰打印口、40-1 日环 8120 打印口，都属于从打印口取数据的协议，接口选错必然一条数据都收不上。

2.2 数据乱码：字节序和 0xEB 字符的坑

串口参数对了、数据也有，但解析出来是乱码，第一个怀疑对象是字节序。协议说明里写得很清楚：传输装置与监控中心传输数据时，所有数据单元按小端格式传输，低字节在先、高字节在后。很多平台侧按大端解析，部件地址就会解析成一个完全对不上的数字——这其实是字节序错了，不是地址映射错了。

第二个坑更隐蔽，是特殊字符干扰。版本记录里有一条很典型的修改：“5-4. 西门子 FS720”协议修改处理了数据包中间出现 0xEB 字符的问题。0xEB 本身是合法数据字节，问题出在帧同步逻辑上：如果收帧程序用某个固定字符做帧头或帧尾，数据区里恰好冒出这个值，就会被误判成帧边界，整包数据从中间被切开。处理方式不是改串口参数，而是在解析层做长度校验和转义，常见做法是：

/* 收帧伪代码：先按长度字段定界，不依赖固定字符做帧尾 */ while (buf_len >= HEAD_LEN + LEN_FIELD) { if (buf[0] != FRAME_HEAD) { shift_one_byte(); continue; } /* 丢一个字节重新对齐 */ frame_len = HEAD_LEN + buf[LEN_POS] + TAIL_LEN; /* 长度字段决定边界 */ if (buf_len < frame_len) break; /* 半包，等下次读取 */ if (buf[frame_len - 1] == FRAME_TAIL) { /* 尾校验通过才交付 */ dispatch_frame(buf, frame_len); shift_offset(frame_len); } else { shift_one_byte(); /* 尾不对，前移一字节重同步 */ } }

核心思路是用长度字段定界、校验字节收尾，而不是傻等 0xEB 或某个固定字符。shift_one_byte()是重同步的关键，帧头错位时只前移一个字节，不能整包丢弃，否则会连带丢掉紧跟其后的正常帧。

2.3 数据能收但内容不对：地址映射方法选错了

这是最容易被误判为“协议不兼容”的一类。设备上传上来了，监控中心的部件地址却是乱的，地址值远超合理范围，或者模块和探测器撞号。根因几乎都落在地址映射方法上。协议表定义了方法 0 到方法 6 共七种映射，方法 0 把区号放高两字节、位号放低两字节，方法 1 里高字节还含主机号，方法 3 则是部件地址直接对应设备号、不分区位号，适用于设备号为 4 字节的系统。

方法 0：BYTE0=区号(万位~百位) BYTE1=区号(十位、个位) BYTE2=位号(万位~百位) BYTE3=位号(十位、个位) 方法 1：高字节含主机号(0~64)+回路号(0~999)，低两字节为设备号，适用带主机号区分的系统 方法 3：BYTE0~BYTE3 直接搬设备号，部件地址不分区位号 方法 6：BYTE0=设备号，BYTE1~BYTE2=回路号高低字节，BYTE3=设备号，对应主机号/回路号/设备号编址

判断该用哪种，看主机自身的编址方式就行：区号 + 位号编址用方法 0；带主机号、多主机级联用方法 1；只给一串 4 字节设备号、内部不分区位用方法 3；采用主机号/回路号/设备号三级编址的用方法 6。MINIMAX 报警主机（52-1）用的就是方法 6，能美 N3060（8-7）用方法 2，赋安 FS5058（23-2）用方法 4——方法 4 对应“栋/区/层/设备号”编址，四个字节分别放设备号、区、层、号。选错方法的典型表现是地址能显示，但回路号、设备号的位置全错，看着像数据解析错，实际上是映射表配错。

3. 部件地址重号与叠加：模块地址 +1000 这类问题怎么解

如果说完协议选型是入门，地址重映射就是这类项目里最能体现经验的环节。很多主机在同一个报警回路内，探测器和模块共用一段地址空间，23 号探测器后面还能挂一个 23 号模块。传输装置只知道“23 号设备报警了”，监控中心却不知道是探测器还是模块，这时候就得上二次映射。

3.1 为什么模块地址要 +1000

协议说明表 2 给出的方案很直接：对模块类设备的地址做地址二次映射，上传地址 = 设备地址 + 1000。版本记录里有两处几乎一模一样的表述：NOTIF3030 CRT 卡的模块地址映射为“映射地址 = 模块地址 + 1000，例如模块地址为 23，映射地址为 1023”；赋安 FS5050 的协议修改也是同一套逻辑，目的写得很清楚——解决探测器类设备与模块类设备地址重叠的问题。

这套方案还有一个演进痕迹值得注意：版本记录里先出现过“10-5.NOTI.3030_地址重映射”，后来被删掉，理由是“NOTIFIER3030 主机已经全部采用地址重映射”。也就是说，重映射从一个可选协议变成了全局默认行为，配接该主机时不需要再单独选带“地址重映射”字样的协议，直接在 10-1 或 10-6 上配方法 2 即可。

# 模块地址二次映射：探测器直传，模块 +1000，避免同回路撞号 def map_module_addr(device_addr: int, is_module: bool) -> int: if not is_module: return device_addr # 探测器、手报保持原地址 if device_addr >= 1000: # 已经是映射后的地址，避免二次叠加 return device_addr return device_addr + 1000 # 模块地址 23 -> 1023 # 平台侧还原时反向减回去，日志里才能看到真实设备号 def unmap_addr(mapped_addr: int) -> int: return mapped_addr - 1000 if mapped_addr >= 1000 else mapped_addr

is_module这个标志必须来自协议解析层对设备类型的判定，不能靠地址范围猜。真正容易翻车的是第二行那个幂等判断：如果传输装置重启后对同一批数据又做了一遍映射，23 变成 1023 再变成 2023，监控中心的图上就会冒出一批根本不存在的设备。我一般会在映射前后各打一条日志，写清楚原始地址、设备类型、映射结果，出问题时一比对就知道映射跑了几次。反向还原函数在排查时同样重要，平台日志里看到的永远是该减 1000 的那个号码。

3.2 映射方法 2 与 +1000 的关系别搞混

一个高频混淆点：方法 2 和模块 +1000 是两件事。方法 2 描述的是区号和位号的字节组织方式，高字节含主机号（0~640）、回路号（0~99）；+1000 是设备类型层面的地址偏移，专治探测器与模块重号。协议表里 NOTIF3030 的写法是“方法 2 + R0”，R0 就是指表 2 里的二次映射规则，两个要一起配。只配方法 2 不配 R0，撞号依旧；只做 +1000 不配方法 2，字节位置又不对。

现场判断这两种情况，看报上来的地址值最直接：地址整体错位、回路号跑到设备号位置上，是映射方法错；地址规律正确但模块和探测器混在一起分不清，是缺了 R0 那层偏移。

3.3 不带“NL”和带“NL”的协议差在哪

协议列表里有一批名字带“NL”后缀的协议，比如 6-3 利达 LD128E NL、8-4 能美 R21 NL、32_5 依爱 6120 模块 NL、4-6 青鸟 193K 卡 V1.8NL。列表注释写明了：协议名称加 NL 后缀的，表示该协议不监控与消防主机通讯故障。反过来，“通讯故障”一栏填“是”的协议，传输装置会持续检测它与消防主机的链路状态，断线就上报通讯故障。

这个差异在现场是实打实的误报来源。某些主机本身不会主动发心跳或巡检应答，传输装置按标准协议去监控通讯状态，就会周期性误报“与消防主机通讯故障”。版本记录里能看到多条同类修改的痕迹：能美 R21/R23 系列主机不监控通讯故障、利达 LD128E NL 不监控通讯故障、营口山鹰转换器 NL 不再监控与消防主机通讯故障、奥瑞那 OXX20 模块解决了不能接收复位信号的问题。所以选型时不能只看品牌对不对，主机型号后面带不带打印口、带不带 NL，决定的是链路监控行为，选错就会陷入“主机好好的，平台一直报通讯故障”的拉锯。

选型对照决策顺序： 1. 现场是串口取数还是打印口取数 -> 决定协议编号是否带“打印口/PRT” 2. 主机是否支持心跳/巡检应答 -> 不支持则选带 NL 的协议，关闭链路监控 3. 主机是多机级联还是单机 -> 决定地址映射是否含主机号（方法 1/2/5） 4. 同回路探测器与模块是否共址 -> 共址则启用 +1000 二次映射（R0） 5. 主机编址是区号+位号还是纯设备号 -> 决定用方法 0/3/4/6

这五步走完，协议编号、串口参数、映射方法、链路监控四项才算配齐。实际项目里出问题，往往是五项里有两三项同时对不上，只修一项看不到效果，于是被误判成“这份协议本身不行”。

4. 排查避坑清单：五条来自现场的血泪记录

4.1 现象：改了协议编号，波特率却还是老的

原因：协议编号和串口参数是两处配置，很多配置工具在切换协议时只替换了解析器，波特率字段保留上一次的值。解决：每次换协议后重新确认一遍串口全参数，包括校验位和停止位，别只看波特率数字。能美系列从 R21（9600,odd）切到松下 EBL8000（4800,even,8,2）这种跨品牌切换，三项全变。

4.2 现象：平台持续报“与消防主机通讯故障”，现场链路正常

原因：该主机型号不支持通讯状态检测，却选了监控通讯故障的协议。解决：换成带 NL 后缀的变体，或按注释切换到不监控通讯故障的协议编号。这类误报在夜间最折磨人，值班人员反复被叫起来确认现场。

4.3 现象：模块地址每隔一段时间就变一次，数值越来越大

原因：地址二次映射被重复执行，+1000 叠加了多次。解决：在映射前加幂等判断，映射后写日志；同时检查传输装置重启后是否对缓存数据重新走了一遍映射流程。这个坑和 3.1 里那段代码的第二行是同一件事。

4.4 现象：收到事件帧后主机不再发后续数据

原因：协议要求收到事件数据帧后回 ACK(0x06) 应答，未回则主机认为链路异常、停止推送。10-5 NOTIFIER N-CRT_1 的说明就明确写了这一点。解决：在解析层收到事件帧后立即回 0x06，且回 ACK 不能阻塞主收帧循环，通常单独放一个发送缓冲。

4.5 现象：换了新型号主机后，能美 R23 的 8 回路设备跑到 10 回路

原因：旧协议按固定回路数做偏移换算，新型号回路配置不同就错位。版本记录里 8-2 能美 R23 的修改正是“解决 8 回路设备对应到 10 回路的问题”。解决：按新型号选对应版本的协议编号，不要沿用旧机型的协议去硬配，回路号偏移量这类硬编码参数在新协议里已经修正。

5. 快速定位：先看地址值，再看字节序，最后看链路状态

现场排障时间紧，我最后会落成一套三分钟自检：拿到一条解析异常的数据，先看地址值本身。地址明显超出合理范围、万位千位乱跳，先怀疑字节序和映射方法；地址规律正常但设备类型对不上，查 +1000 二次映射是否启用、是否叠加；串口有数据但一条都解析不出来，回到串口参数和 0xEB 这类特殊字符的帧同步。

协议表里几个关键字段可以当索引来查：通讯故障列填“是”的，要保证链路监控真的在跑；填“空”的，平台侧不能配通讯故障告警。地址映射说明列写的“方法 N”，对应表 1 的字节布局；“+R0”则对应表 2 的二次映射。很多“协议不兼容”的结论，其实是这两列没对上。

验证的最后一招是隔离法：拿一台已知能正常工作的主机和协议组合，先接上确认传输装置和平台链路本身没问题，再把待测主机单独接上去，这样能立刻区分是平台侧问题还是协议侧问题，比对着日志猜快得多。

从那以后我每次配接新主机，都强制走一遍“协议编号、串口五参数、映射方法、NL 后缀、ACK 要求”这五项核对，一项不落。这份协议列表的价值不在于它列了多少品牌，而在于它把每条协议的参数、映射和监控行为都固化成了可比对的字段，出问题时能一条条对着查，省掉大量来回猜的时间。希望帮到你。

本文还有配套的精品资源，点击获取