unlobito / ha-hildebrandglow

PRE-RELEASE. HomeAssistant integration for the Hildebrand Glow smart meter HAN for UK SMETS meters.
MIT License
54 stars 32 forks source link

High Instant read #52

Open scott400k opened 2 years ago

scott400k commented 2 years ago

Hi,

Firstly thansk for the Dev it works great.........except i'm getting the occasionalreading that is far too high like its a pulse that being reported back of circa 10000W and its happening where my solar is exporting to the grid (attached) is from the graphana i'm using from the data recorded in my InfluxDB. image

An Extract of the data Recorded (incorrect data is in bold):-

022-03-25 15:26:40 475 2022-03-25 15:26:50 0 2022-03-25 15:27:20 316 2022-03-25 15:27:30 942 2022-03-25 15:27:40 0 2022-03-25 15:30:40 10472 2022-03-25 15:31:00 0 2022-03-25 15:40:50 10850

scott400k commented 2 years ago

OK, So I might have Identified the issue the data i'm getting is 10x too high if I apply /10 to the data in Graphana it works fine, but the amount in the Lovelace shows:- image so i'm not sure how to apply the "fix" in Lovelace :-/

andersonshatch commented 2 years ago

I just got a glow device this week and noticed this. Just pushed a fix that I will open a PR for shortly (plus some other changes e.g. production sensor to track return to grid)... want to test it works for you too @scott400k? The change is limited to one file: https://github.com/andersonshatch/ha-hildebrandglow/commit/9d61dd9ae863de92d557db98cbea71df2ab0ff1a

townsmcp commented 2 years ago

@scott400k and @andersonshatch i have been in touch with Hildebrand about high spikes in gas and electric from the MQTT access. I have also seen the same in this integration. Today they replaced with the following:

We confirm that the meter has returned a value of "FFFFFFFFFFFF", which for the data type means it's an invalid value.

The ingress to the Hildebrand database detects these invalid values and discards them so they don't appear in our APIs (and therefore Bright); we assume they do appear in the MQTT feed and so will need to be detected and discarded by MQTT users.

This means the spikes you are seeing @scott400k will be due to a returned value of Fs. The code therefore needs to be change to exclude any reading when value is FFFFFFFFFFFF (these values are sent as hex which do convert to a decimal value however the decimal is clearly incorrect

andersonshatch commented 2 years ago

@townsmcp have yet to see that, but has only been a day or so with the device. Sounds more like #54 though. This issue (and what my change addresses) occurs whenever you are exporting electricity, i.e. instant consumption goes below 0.

townsmcp commented 2 years ago

@andersonshatch my bad. When I read the OP I thought it meant the same issue I’m getting of massive spikes

scott400k commented 2 years ago

@andersonshatch Hiya sorry been away this weekend, to clarify my issue is more that all the readings are x10 what they should be.

So a reading on the Glow screen is 6.06KW but the Ha Hildebrandglow integration shows 60,590W (which is 60.590KW!).

andersonshatch commented 2 years ago

Ah, I see, thanks for the extra detail @scott400k the changes I've made are for a separate issue then. Though I think I do see where your issue lays, the information about where to place the decimal place is decoded, but then just ignored.

scott400k commented 2 years ago

That would be outstanding if it could be fixed :-D