Comcore EUW300 ChirpStack Codec

A ChirpStack v4 JavaScript codec (decodeUplink/encodeDownlink) for the Comcore EUW300 ultrasonic water meter, implementing protocol V2.0 (2026-02-26) from Qingdao Comcore Technologies Co., Ltd.

Files

• comcore_euw300_codec.js — the codec. Drop it into ChirpStack's device profile codec editor (or chirpstack-application-server's payload codec field) as-is.
• Comcore Watermeter Communication Protocol-EUW300-V2.0-20260226-EN.pdf — the vendor protocol spec this codec's documented message types are decoded against.

Supported uplink message types

Data Identifier	Report type	Status
0x8410	Daily frozen data (reported 00:00–06:00 each day)	Documented in V2.0 spec
0x8411	Key press report (magnetic button held 3s)	Documented in V2.0 spec
0x8412	Abnormal event report	Documented in V2.0 spec
0x8409	Hourly frozen data (12 hourly accumulations per packet)	Documented in V2.0 spec
0x7028	Daily report (V1.0 legacy format)	Undocumented in V2.0 — see below

Any other data identifier is passed through with raw hex bytes attached (data.rawData) and a warning.

The 0x7028 message

0x7028 doesn't appear anywhere in the V2.0 protocol PDF, but its 34-byte payload has the same layout as CJT188 command DI=911F ("R Measurement Data"), a command defined in Comcore's WGH desktop configuration app. That mapping was recovered by decompiling the desktop app and cross-referencing its config XML against its own response-parsing logic, then validated against real captured payloads from multiple physical meters. Bytes [0-32] of the payload match the documented 911F response exactly; byte [33] is extra and still unexplained.

Known caveat: batteryVoltage_V is decoded with an inferred ×10⁻⁴ scale. The 911F spec states ×10⁻³, but that produced implausible ~25–27V readings across every real sample checked so far; ×10⁻⁴ puts them all in a normal ~2.6–2.7V range for this device's lithium cell. Not yet confirmed against a live meter's actual battery reading. decodeUplink emits a warning on every 0x7028 frame noting both of these caveats.

Frame format (all message types)

68 [type] [addr x7] [ctrl] [len] [DI x2] [ser] [data...] [checksum] 16

• 0x68 start-of-frame, 0x16 end-of-frame
• 7-byte BCD meter address, low-order byte first
• Checksum is the sum of all bytes from SOF up to (not including) the checksum byte, mod 256
• Malformed frames (bad SOF, truncated length, checksum/EOF mismatch) produce entries in errors/warnings rather than throwing

Output shape

{
  data: {
    meterAddress: "25070330100035",
    dataIdentifier: "0x7028",
    serialNumber: 0,
    reportType: "daily_v1",
    // ...fields specific to the report type
  },
  errors: [],
  warnings: []
}