MQTT & CAD - Cumulative gas readings are off by hundreds of millions of kWh

edited June 2022 in API Info


I recently set up my Glow Display & CAD which has been working great, and I set it up with local MQTT to Home Assistant.

However, I've noticed that the cumulative gas reading is off by hundreds of millions of kWh. Here's an example packet from the MQTT stream:

  "gasmeter": {
    "timestamp": "2022-06-18T08:39:21Z",
    "energy": {
      "export": {
        "cumulative": 0,
        "units": "kWh"
      "import": {
        "cumulative": 711118290944,
        "day": 3.045,
        "week": 34.202,
        "month": 178.53,
        "units": "kWh",
        "mprn": "REMOVED",
        "supplier": "---",
        "price": {
          "unitrate": 0.0736,
          "standingcharge": 0.2722
    "power": {
      "value": 0,
      "units": "kW"

You can see that the day, week and month values are correct and in kWh (I confirmed these with my IHD). However the cumulative value is definitely not correct, especially as the meter was only installed in February.

I checked the gas meter reading on my Cameleon IHD and it shows the right cumulative lifetime reading (ie. latest read) as 238 m3.

If I check the gas meter reading on the Glow Display & CAD it shows the incorrect cumulative lifetime reading (ie. latest read) as 711264567296.00 (no units, assuming kWh). This value increases by huge, unrealistic amounts as the reading is updated over time.

The CAD does have the right kWh values for the day, week and month and those match up with the Cameleon IHD.

If it helps, the Bright app reports the following for my gas meter:

  • Maufacturer: L+G
  • SMETS 2
  • Firmware 03033254
  • Gas proxy manufacturer: WNC
  • Gas proxy firmware: 030A0007

Any suggestions on how I can resolve this so the CAD & MQTT endpoint are using the correct gas meter readings?


  • If you are still having this issue please raise a ticket with

  • I still have the issue. I sent an email about this to that email address yesterday so I'll wait for a response there. Thanks.

  • Did you get a resolution to this? I personally don't have this issue with the data from glow but when I pull data from ( I registered with them last year before I found glow) I see anomalies at 00:30 on a lot of days ... from last months export I see these ... its always the same number and always 00:30 so when I am analysing I just ignore anything at 00:30 as my boiler (only thing I use gas for) is off.

    timestamp (UTC) energyConsumption (m3)

    06/07/2022 00:30 16777.215

    11/07/2022 00:30 16777.215

    16/07/2022 00:30 16777.215

    17/07/2022 00:30 16777.215

    18/07/2022 00:30 16777.215

    22/07/2022 00:30 16777.215

    25/07/2022 00:30 16777.215

    26/07/2022 00:30 16777.215

    30/07/2022 00:30 16777.215

    05/08/2022 00:30 16777.215

    I have tried to reach out to but have never got a response - this item on github provides some insight

  • Sadly this is GBCS code

    16777.215 * 1000 = 16777215 = in HEX 0xFFFFFF which just means - Error.

  • yes - as documented in the github link I included ... if people don't take action to remove these error values and just include them in the sum it can result in the summing of gas consumption to be wildly out

  • We do in our database - clearly n3rgy do not.

    I make no comment.

Sign In or Register to comment.