Filter based on tamper flags or type

[legrego]

This request is a bit of a workaround, so I'm happy to discuss alternative approaches.

My energy meter reports via SCM, and most readings appear correct. Occasionally, I see messages that indicate unrealistic consumption spikes, where it suggests that I consumed over 1,000,000 kWh since the last report.

With debug logging enabled, I noticed that these spikes correlate to SCM messages from the same meter, but with a different Type, and with both TamperPhy and TamperEnc flags set.

The sample messages are unaltered from the logs, except for the message ID, which I've redacted. This ID is the same in both of the real messages.

Ordinary message (Type: 4, no tamper) @ 21:09:12

{
  "Time": "2023-10-25T21:09:12.907677625Z",
  "Offset": 0,
  "Length": 0,
  "Type": "SCM",
  "Message": {
    "ID": 12345678,
    "Type": 4,
    "TamperPhy": 0,
    "TamperEnc": 0,
    "Consumption": 43006,
    "ChecksumVal": 42528
  }
}

Sample "spike" message (Type: 6, tamper) @ 21:09:54

{
  "Time": "2023-10-25T21:09:54.192145691Z",
  "Offset": 0,
  "Length": 0,
  "Type": "SCM",
  "Message": {
    "ID": 12345678,
    "Type": 6,
    "TamperPhy": 1,
    "TamperEnc": 2,
    "Consumption": 5546750,
    "ChecksumVal": 42538
  }
}

Another ordinary message (Type: 4, no tamper) @ 21:09:54

Consumption resets to expected level following the erroneous spike.

{
  "Time": "2023-10-25T21:09:54.413726412Z",
  "Offset": 0,
  "Length": 0,
  "Type": "SCM",
  "Message": {
    "ID": 12345678,
    "Type": 4,
    "TamperPhy": 0,
    "TamperEnc": 0,
    "Consumption": 43006,
    "ChecksumVal": 42528
  }
}

Has anyone come across this before? These false consumption spikes are problematic for me downstream, so I'd like a way to filter them out before publishing them into MQTT (via https://github.com/allangood/rtlamr2mqtt).

[legrego]

The specifications for my meter (https://www.smartmetereducationnetwork.com/uploads/how-to-tell-if-I-have-a-ami-dte-smart-advanced-meter/Itron%20Centron%20Meter%20Technical%20Guide1482163-201106090057150.pdf) only mention Type: 4 as valid, and don't reference Type: 6 at all. This leads me to believe that either the documentation is incomplete, or we are incorrectly interpreting the SCM message. I'm more inclined to believe that the docs are wrong, but stranger things have happened.