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

robhawkes

Hello,

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?

clivee

If you are still having this issue please raise a ticket with support@glowmarkt.com

robhawkes

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.

Snigehere

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 n3rgy.com ( 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 n3rgy.com but have never got a response - this item on github provides some insight

https://github.com/n3rgy/data/issues/1

clivee

Sadly this is GBCS code

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

Snigehere

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

clivee

We do in our database - clearly n3rgy do not.

I make no comment.