一、LoRaWAN 在热量表采集场景中的技术挑战
在集中供热、区域能源管理等场景中，热量表往往分布广泛、供电条件受限，且设备生命周期长。传统有线抄表或私有无线方案在改造成本、维护复杂度和扩展性方面存在明显不足。
LoRaWAN 以其远距离、低功耗和标准化特性，逐渐成为热量表远程采集的主流通信方式。但在实际落地过程中，工程人员往往面临两个核心问题：
一是 M-Bus 与 CJ/T 188 协议在不同厂家的实现存在细节差异
二是 现场设备参数变化频繁，固件频繁修改成本高
这正是引入边缘计算与可配置协议解析机制的价值所在。
二、KC22 与 Edge-Bus：面向工程部署的采集架构
2.1 KC22 LoRaWAN M-Bus 采集器概述
KC22 是一款面向电池供电场景设计的 LoRaWAN M-Bus 采集终端，主要用于热量表、水表等仪表的数据采集与远程上传。
其典型工作模式为：
通过 M-Bus 接口与热量表通信
在本地完成协议解析与数据处理
通过 LoRaWAN 将结构化数据上报至平台
KC22 的核心差异点并不在于硬件接口本身，而在于其内置的 Edge-Bus（EB）虚拟机。
2.2 Edge-Bus 与 EB Compiler SDK 的设计理念
Edge-Bus 是运行在终端设备上的轻量级事件驱动虚拟机，允许用户使用 TypeScript 编写采集与处理逻辑，并通过 EB Compiler SDK 编译后部署到设备端。
在 EB 中，所有业务逻辑被拆分为事件驱动模型，主要包括两类核心事件：
查询事件（Query Event）
负责周期性向 M-Bus 表计发送指令并接收原始数据
上行事件（LoraUp Event）
负责将解析后的数据按 LoRaWAN 规范进行封装并上报
这种解耦设计使采集逻辑与通信逻辑清晰分离，为协议复用和参数化配置提供了基础。
三、CJ/T 188 M-Bus 热量表协议的共性分析
3.1 多厂家协议的一致性基础
在实际项目中，嘉洁能、迈拓、艾克瑞等热量表虽然厂商不同，但其通信协议均基于 CJ/T 188 标准。
其主要一致点包括：
通信参数统一为 2400bps、8 数据位、偶校验、1 停止位
数据项编码方式统一采用 BCD 格式
数据帧结构与校验方式保持一致
差异主要集中在两个方面：
M-Bus 表计地址
厂家代码或扩展字段
这为使用统一 EB 协议模板提供了现实基础。
3.2 典型读数指令与数据特征
以 CJ/T 188 热量表的读计量数据指令为例，指令帧中包含表计地址、控制码、数据标识及校验字段。
返回数据通常包含：
累计热量
瞬时热量
累计流量
供水温度与回水温度
所有数值均以 BCD 编码方式存储，单位信息在协议中有明确约定。
四、EB 中的 CJ/T 188 协议实现思路
4.1 串口与通信参数配置
在 EB 代码中，首先需要对 KC22 的串口参数进行配置，使其与 CJ/T 188 要求完全一致。
该配置在 EB 初始化阶段完成，一旦固化，后续无需频繁调整。
4.2 查询事件中的指令构造与校验
查询事件中定义了发送给热量表的查询指令缓存。
针对 CJ/T 188 协议，EB 提供了灵活的校验配置接口，可直接配置累加和校验方式，用于指令发送和应答校验。
4.3 数据解析与本地处理
EB 提供了针对 BCD 数据的读取与转换接口，可按照协议中定义的偏移量和长度，从应答缓冲区中读取各类数据项。
解析完成后，数据被写入上行事件的发送缓冲区，供 LoRaWAN 上报使用。
五、多厂家适配的关键：参数化而非多固件
5.1 M-Bus 地址的动态配置策略
M-Bus 地址是查询指令中的关键字段，不同项目中表计地址差异较大。
在 EB 中，可以通过 APP Buffer 存储表计地址参数，并在查询事件中动态读取该参数，拼接生成完整查询指令。
这样，同一套固件即可适配不同地址的表计。
5.2 厂家代码的统一适配方法
对于协议结构一致但厂家代码不同的情况，EB 代码中只需保留一个协议模板。
厂家代码作为可配置参数存入 APP Buffer，在发送指令前动态替换对应字段即可。
通过这种方式，可以实现：
单一 EB 固件
多厂家 CJ/T 188 表计适配
远程参数修改，无需现场升级
六、KC22 的工程化部署流程
完整的工程部署通常包含以下步骤：
第一步，编写 EB 协议逻辑
基于 CJ/T 188 协议完成串口配置、查询指令定义和数据解析规则
第二步，编译并升级固件
使用 EB Compiler SDK 生成固件，通过 ThinkLink 或第三方 LoRaWAN 平台进行远程升级
第三步，远程参数配置
通过 LoRaWAN 下行指令写入表计地址、厂家代码等参数，实现快速部署
KC22 同时支持远程控制类指令，例如远程复位，可用于运维阶段的异常恢复。
七、总结
KC22 LoRaWAN M-Bus 采集器结合 Edge-Bus 虚拟机，为 CJ/T 188 热量表提供了一种高度工程化、可复用的采集方案。
通过将协议差异抽象为参数配置，而非固件差异，不仅显著降低了部署与维护成本，也为后续多型号、多厂家的表计接入提供了可持续扩展能力。
在能源计量物联网规模化落地的过程中，这种"边缘计算 + 协议模板化"的思路，正逐步成为主流技术路径。
更多 Edge-Bus 示例代码可参考
https://github.com/ManThink/TKL-EB-SDK