一、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
