LoRaWAN-Based CJ/T 188 M-Bus Heat Meter Data Acquisition: An Engineering Practice with KC22 and Edge-Bus

1. Challenges in LoRaWAN-Based Heat Meter Deployment

In district heating and energy management systems, heat meters are typically widely distributed and powered by batteries. Traditional wired or proprietary wireless solutions often suffer from high retrofit costs and limited scalability.

While LoRaWAN offers long-range, low-power, and standardized connectivity, practical deployment still faces challenges related to protocol variations and frequent on-site configuration changes.

This makes edge-level protocol processing and flexible configuration mechanisms essential.

1. KC22 and Edge-Bus Architecture 2.1 Overview of KC22

KC22 is a LoRaWAN-enabled M-Bus data acquisition device designed for battery-powered field installations. It communicates with heat meters via M-Bus and uploads processed data to the cloud over LoRaWAN.

Its key advantage lies in the embedded Edge-Bus virtual machine, which enables customizable edge logic without modifying the hardware.

2.2 Edge-Bus and EB Compiler SDK

Edge-Bus provides an event-driven execution environment on the device. Using the EB Compiler SDK, users can write TypeScript-based logic for protocol handling and data processing.

The core events include:

Query Events for meter polling and raw data acquisition
LoraUp Events for LoRaWAN payload packaging and uplink transmission

This separation simplifies protocol reuse and long-term maintenance.

1. Common Characteristics of CJ/T 188 Heat Meter Protocols 3.1 Protocol Consistency Across Manufacturers

Heat meters from manufacturers such as Jiajieneng, Metersit, and Acrel share a common CJ/T 188 protocol foundation.

They typically use identical serial communication parameters, BCD-encoded data fields, and similar frame structures, with differences mainly limited to meter addresses and manufacturer codes.

3.2 Data Structure and Metering Values

Typical responses include cumulative heat, instantaneous heat, total flow, and supply/return temperatures. All values follow clearly defined offsets and lengths within the protocol frame.

1. Implementing CJ/T 188 in Edge-Bus 4.1 Serial Configuration

The serial interface parameters are configured within the EB logic to match CJ/T 188 requirements, ensuring stable communication.

4.2 Query Events and Checksum Handling

Query Events define the polling commands and configure checksum verification. EB supports the checksum mechanisms required by M-Bus-based CJ/T 188 devices.

4.3 Data Parsing and Processing

EB provides built-in methods for reading and converting BCD data. Parsed values are written to uplink buffers for LoRaWAN transmission.

1. Multi-Vendor Adaptation via Parameterization 5.1 Dynamic M-Bus Address Configuration

Meter addresses are stored in the APP Buffer and dynamically inserted into query commands at runtime, allowing a single firmware to support different devices.

5.2 Manufacturer Code Handling

Manufacturer-specific fields can also be parameterized. By updating configuration values remotely, the same EB logic can adapt to multiple CJ/T 188 implementations.

1. Deployment Workflow

A typical deployment includes:

Developing EB logic based on the CJ/T 188 protocol
Compiling and upgrading firmware via LoRaWAN
Remotely configuring meter parameters through downlink commands

This approach minimizes on-site intervention and simplifies large-scale rollouts.

1. Conclusion

By combining KC22 with the Edge-Bus virtual machine, a highly flexible and scalable solution for CJ/T 188 heat meter data acquisition is achieved.

Protocol differences are abstracted into configurable parameters rather than separate firmware versions, significantly reducing deployment and maintenance costs.

This edge-computing-driven approach provides a robust foundation for large-scale energy metering IoT systems.

More Edge-Bus examples are available at
https://github.com/ManThink/TKL-EB-SDK