We decode FlowIQ 2200 (KWM2231) via wM‑Bus on ESP32 (CC1101, 868 MHz). Compact frames (CI=0x79, len=36) and full frames (CI=0x78, len=61) are received. Full‑frame flow uses VIF 0x3B (2 bytes) and appears correct, but CRC checks always fail on full frames. Full frames are sporadic (≈13–25 minutes between). We now cache full‑frame flow and bridge compact values >255 using last full‑frame offset.
We’d like help to confirm where CRC should be checked (if applicable) and whether our record mapping for status/alarms is correct for FlowIQ 2200.
Environment
Hardware: ESP32 + CC1101 @ 868 MHz
Meter: FlowIQ 2200 (KWM2231)
Firmware: 0.3.2 (repo: github.com/erikxson/WaterMeter-FlowIQ2200)
What works
Compact frame decoding for volume + flow (VIF 0x32, 1 byte).
Full frame decoding for flow (VIF 0x3B, 2 bytes).
JSON publishes FlowLph + FlowLphFull.
Issues
CRC on full frames does not validate with EN13757 or X25.
Full frames are infrequent (observed ~13–25 min).
We don’t yet map status/alarms (leak/burst/reverse).
Current behavior
Compact flow (CI=0x79) is 1‑byte VIF 0x32. We extend it using the last full‑frame flow:
- if last full flow >=256, we keep a +256 offset and apply it to compact values
- offset stays until the next full frame arrives (then it’s updated/reset)
- without recent full frame, compact value is raw 0..255
Logs (examples)
CI=0x78 len=61
CRC_FAIL ci=0x78 len=61 calc=0xC907 read=0xF68E
FULLFLOW vif=0x3B vlen=2 lph=305
RAW len=61 data=8E F6 78 04 FF 23 00 00 00 00 04 13 C0 95 02 00 44 13 0B 8F 02 00 42 6C 41 32 02 3B 31 01 92 01 3B D5 03 A2 01 3B 00 00 06 FF 1B 07 70 00 ...
Questions
Is CRC expected/usable in plaintext after decrypt for FlowIQ 2200? If yes, where is it located?
Are we interpreting VIF 0x3B correctly as flow for this meter?
Any hints on record mappings for alarms/status (leak/burst/reverse) in FlowIQ 2200?
Additional notes
We added a raw RF dump (pre‑decrypt) to MQTT topic watermeter/0/debug/rf to inspect if CRC bytes are present there.
We decode FlowIQ 2200 (KWM2231) via wM‑Bus on ESP32 (CC1101, 868 MHz). Compact frames (CI=0x79, len=36) and full frames (CI=0x78, len=61) are received. Full‑frame flow uses VIF 0x3B (2 bytes) and appears correct, but CRC checks always fail on full frames. Full frames are sporadic (≈13–25 minutes between). We now cache full‑frame flow and bridge compact values >255 using last full‑frame offset.
We’d like help to confirm where CRC should be checked (if applicable) and whether our record mapping for status/alarms is correct for FlowIQ 2200.
Environment
Hardware: ESP32 + CC1101 @ 868 MHz
Meter: FlowIQ 2200 (KWM2231)
Firmware: 0.3.2 (repo: github.com/erikxson/WaterMeter-FlowIQ2200)
What works
Compact frame decoding for volume + flow (VIF 0x32, 1 byte).
Full frame decoding for flow (VIF 0x3B, 2 bytes).
JSON publishes FlowLph + FlowLphFull.
Issues
CRC on full frames does not validate with EN13757 or X25.
Full frames are infrequent (observed ~13–25 min).
We don’t yet map status/alarms (leak/burst/reverse).
Current behavior
Compact flow (CI=0x79) is 1‑byte VIF 0x32. We extend it using the last full‑frame flow:
Logs (examples)
CI=0x78 len=61
CRC_FAIL ci=0x78 len=61 calc=0xC907 read=0xF68E
FULLFLOW vif=0x3B vlen=2 lph=305
RAW len=61 data=8E F6 78 04 FF 23 00 00 00 00 04 13 C0 95 02 00 44 13 0B 8F 02 00 42 6C 41 32 02 3B 31 01 92 01 3B D5 03 A2 01 3B 00 00 06 FF 1B 07 70 00 ...
Questions
Is CRC expected/usable in plaintext after decrypt for FlowIQ 2200? If yes, where is it located?
Are we interpreting VIF 0x3B correctly as flow for this meter?
Any hints on record mappings for alarms/status (leak/burst/reverse) in FlowIQ 2200?
Additional notes
We added a raw RF dump (pre‑decrypt) to MQTT topic watermeter/0/debug/rf to inspect if CRC bytes are present there.