MQTT HA discovery: SCM+ and IDM meter readings are never discovered (`consumption` mapping is keyed to the wrong case)

What happens

Running rtl_433 against a US utility meter with -R 154 (SCM+) and piping to rtl_433_mqtt_hass.py, Home Assistant gets discovery configs for time, rssi, snr and noise — but not for the meter reading itself. The one field the whole setup exists to read is the one field that never appears. Everything looks healthy: the decode is CRC-valid, the JSON on MQTT contains the reading, and the bridge reports no error.

The reading has to be created as a manual template sensor to be usable at all.

Why

rtl_433_mqtt_hass.py matches field names exactly and case-sensitively:

for key in data.keys():
    if key in mappings:

The SCM+ decoder emits the key Consumption (src/devices/scmplus.c):

"Consumption",      "",   DATA_FORMAT, "%u", DATA_INT, consumption_data,

The mapping table only has consumption, lowercase:

"consumption": {
    "device_type": "sensor",
    "object_suffix": "consumption",
    "config": {
        "name": "SCMplus Consumption Value",
        ...

So the entry that is named for SCM+ can never match an SCM+ message.

There is a second half to this that is worth flagging on its own: lowercase consumption is not dead code. Across the whole of src/devices/, exactly one decoder emits it — neptune_r900.c — and exactly one emits Consumption — scmplus.c. So today that entry silently serves Neptune R900 water meters, while presenting itself in Home Assistant as "SCMplus Consumption Value". Anyone with an R900 has a mislabelled entity and probably has not noticed.

ERT-SCM is unaffected: it emits consumption_data, which is mapped correctly.

Also unmapped

IDM and NETIDM (src/devices/ert_idm.c) emit none of their consumption fields into discovery:

• LastConsumptionCount (line 285) — the meter reading
• ConsumptionIntervalCount (line 276)
• DifferentialConsumptionIntervals (line 286) — an array; not a simple sensor, noted for completeness rather than proposed
• MeterType (line 291), also emitted by SCM+ (line 150)

Suggested fix

Additive — nothing existing changes behaviour, so no R900 user loses an entity:

     "consumption": {
         "device_type": "sensor",
         "object_suffix": "consumption",
         "config": {
-            "name": "SCMplus Consumption Value",
+            "name": "Consumption Value",
             "value_template": "{{ value|int }}",
             "state_class": "total_increasing",
         }
     },
 
+    "Consumption": {
+        "device_type": "sensor",
+        "object_suffix": "consumption",
+        "config": {
+            "name": "SCMplus Consumption Value",
+            "value_template": "{{ value|int }}",
+            "state_class": "total_increasing",
+        }
+    },
+
+    "LastConsumptionCount": {
+        "device_type": "sensor",
+        "object_suffix": "consumption",
+        "config": {
+            "name": "IDM Consumption Value",
+            "value_template": "{{ value|int }}",
+            "state_class": "total_increasing",
+        }
+    },
+
+    "ConsumptionIntervalCount": {
+        "device_type": "sensor",
+        "object_suffix": "consumption_interval",
+        "config": {
+            "name": "Consumption Interval Count",
+            "value_template": "{{ value|int }}",
+            "state_class": "measurement",
+        }
+    },
+
+    "MeterType": {
+        "device_type": "sensor",
+        "object_suffix": "meter_type",
+        "config": {
+            "name": "Meter Type",
+            "entity_category": "diagnostic",
+        }
+    },
+

Renaming the lowercase entry to a neutral "Consumption Value" is the conservative option — it stops it claiming to be SCM+ without guessing that every future user of that key is an R900. Happy to make it "Neptune R900 Consumption Value" instead if you would rather be explicit.

On device_class and units

Deliberately not set. SCM+ and IDM carry a MeterType of Electric, Gas or Water, and the raw counter's unit varies by utility and by meter, so a static device_class: gas or a static unit would be wrong for most users. Leaving them unset matches what consumption_data already does. Users can add them in HA once they have compared against the physical dial. Mentioning it because it is the obvious follow-up question.

Environment

• rtl_433 built from master
• RTL-SDR Blog V4 Lite, via the vendor librtlsdr fork
• Protocol 154 (SCM+), a gas meter, CRC-valid decodes at 24–31 dB SNR
• MQTT to Home Assistant

I am happy to open this as a PR rather than an issue if that is easier.