使用EB 实现M-Bus热量表采集的实例

随着物联网技术在能源计量领域的深入应用，如何高效、灵活地采集和传输热量表数据成为了关键挑战。本文将以KC22 LoRaWAN电池版M-Bus采集器为例，结合其内置的Edge-Bus (EB) 虚拟机和EB Compiler SDK，详细介绍如何通过简单的配置实现对基于CJ/T 188协议的M-Bus热量表的采集，特别是针对协议一致但厂家代码不同的嘉洁能、迈拓和艾克瑞等品牌的适配，实现快速部署和智能化边缘计算。

更多的EdgeBus代码可以查看：https://github.com/ManThink/TKL-EB-SDK

1. KC22与EB：M-Bus采集的黄金组合

1.1 KC22 DTU简介

KC22是一款高性能、低功耗的LoRaWAN M-Bus采集器，专为远距离、电池供电的物联网应用设计。它通过M-Bus接口与热量表通信，并通过LoRaWAN协议将数据上传至云端。

其核心优势在于内置的EB（Edge-Bus）虚拟机 。EB允许用户通过编写TypeScript代码（使用EB Compiler SDK），在设备本地实现复杂的业务逻辑，例如：

• 协议适配：灵活解析和封装不同厂家的M-Bus协议。
• 数据处理：本地进行数据校验、单位转换和异常告警。
• 事件驱动：周期性查询（Query Event）和按需上行（LoraUp Event）数据。

1.2 EB Compiler SDK核心概念

EB Compiler SDK提供了一个事件驱动的架构，将采集和上传任务抽象为两个核心事件 ：

2. M-Bus热量表协议分析与适配

根据用户提供的资料，嘉洁能、迈拓和艾克瑞的协议基础一致，均基于CJ/T 188标准，区别主要在于厂家代码和地址格式。

2.1 通用协议结构

以艾克瑞的读计量数据指令为例，其通信参数为：2400bps、偶校验、8位数据位、1位停止位 (2400.8.E.1) [艾科瑞协议, Page 1]。

读计量数据指令示例 (以地址12345678为例)： FE FE FE 68 20 78 56 34 12 00 00 00 01 03 90 1F 01 50 16 [艾科瑞协议, Page 3]

采集关键数据项： 协议返回数据中包含累计热量、瞬时热量、累计流量、供回水温度等关键数据，它们以BCD码格式存储，且单位在前，数据在后 [艾科瑞协议, Page 4]。

2.2 EB中的协议实现（以CJ188HeatMeter.ts为例）

EB的配置核心在于otaConfig和QueryEvent的定义。

2.2.1 串口参数配置

在CJ188HeatMeter.ts中，可以看到KC22的串口参数配置：

let otaConfig = getOtaConfig({
    // ...
    BaudRate: 2400,
    StopBits: 1,
    DataBits: 8,
    Checkbit: CheckbitEnum.EVEN, // 偶校验
    Battery: true, // 电池供电，Class A模式
    BzType: 303, // 业务类型
    BzVersion: 12 // 业务版本
})

该配置与CJ/T 188协议要求的2400.8.E.1完全吻合。

2.2.2 查询事件与数据解析

1. 定义查询指令： cmdBuffer1定义了发送给热量表的查询指令。

let cmdBuffer1=Buffer.from("FE FE FE FE FE 68 20 12 19 24 18 27 31 00 01 03 1F 90 12 0C 16".replaceAll(" ", ""), "hex")

1. CRC校验配置： M-Bus协议使用简单的二进制算术累加和作为校验码（CS）。EB通过setQueryCrc和setAckCrc来配置校验模式。

quEvent1.setQueryCrc({
    Mode: CrcMode.SUM, // 累加和校验
    CrcLen:1,
    placeIndex:-2,
    crcCheckRange:{
        startIndex:5,
        endIndex:-2
    }
})
// 接收校验同理

1. 数据解析与转换： 这是EB实现协议适配的关键。pushEBData方法定义了从接收缓冲区（quEvent1.ackBuffer）读取数据并写入上行缓冲区（upEvent1.txBuffer）的规则。例如，读取热量表地址（通常是BCD码）：

quEvent1.pushEBData(upEvent1.txBuffer.writeUintLE(
    quEvent1.ackBuffer.readBcd(2,7), // 从偏移量2开始，读取7个字节的BCD码
    3,6),{
    condition: ExprCondition.ONTIME
})

对于热量、流量等数据，同样使用readBcd(offset, length)方法进行读取，并根据协议规范确定正确的偏移量和长度。

3. 针对多厂家协议的EB配置策略

由于嘉洁能、迈拓和鸿豪兴达的协议基础一致，KC22的EB配置只需关注两个核心点：M-Bus地址和厂家代码。

3.1 M-Bus地址配置

M-Bus协议的地址（如鸿豪兴达的AA AA AA AA AA AA AA）是查询指令的一部分。在实际应用中，DTU需要根据所连接热量表的地址来动态生成查询指令。

在EB中，可以通过将地址参数化并存入APP Buffer来实现动态配置 [EB SDK, line 162]。

1. APP Buffer存储地址： 将热量表的M-Bus地址（例如7字节）写入APP Buffer的特定偏移量。
2. 指令动态生成： 在QueryEvent的数据复制或计算规则中，从APP Buffer读取地址，并将其插入到cmdBuffer的相应位置。

3.2 厂家代码适配

协议一致但厂家代码不同，意味着只需要在EB代码中维护一个协议模板，并根据实际连接的表计，动态修改查询指令中的厂家代码（如果协议中包含厂家代码字段）。

策略：

• 统一EB代码： 编写一套通用的EB代码（如CJ188HeatMeter.ts的逻辑）。
• 参数化厂家代码： 将厂家代码作为配置参数（例如，存入APP Buffer的另一个偏移量）。
• 动态替换： 在QueryEvent发送指令前，从APP Buffer读取厂家代码，并替换cmdBuffer中对应的字节。

通过这种方式，一套EB固件可以适配所有协议基础相同的CJ/T 188表计，只需通过LoRaWAN下发指令（写入APP Buffer）来修改地址和厂家代码等配置参数，即可实现DTU的灵活部署和远程配置。

4. 实战操作步骤

KC22 DTU的部署和配置流程主要分为三步：

示例：远程复位命令

KC22支持通过下行指令进行远程控制。例如，复位命令为：

控制字=0x03，起始地址=0x09，字节长度=0x01，写入内容为0x01
通过214端口下发 0xCF 03 09 01 01 会使设备复位。

5. 总结

KC22 M-Bus转LoRa DTU结合EB虚拟机，为热量表采集提供了一个高灵活性、低功耗的解决方案。通过EB Compiler SDK，用户可以轻松实现对CJ/T 188协议的深度适配，即使面对不同厂家代码的表计，也能通过一套通用的EB逻辑和远程参数配置，实现快速、可靠的数据采集和传输。这种边缘计算能力，极大地简化了现场部署和后期的维护工作。