britkat1980 / giv_tcp

TCP connection (from inverter) and MQTT implementation
78 stars 37 forks source link

consumption entities on restart #237

Open dmlambert99 opened 2 weeks ago

dmlambert99 commented 2 weeks ago

I use some of the givTCP entities for the energy dashboard, but noticed that I sometimes se 'spikes', which I have to correct. The penny has now dropped that this happens whenever I restart HA. I initially thought it was because there was a jump from 0 back up to the current daily total, but it looks like the entity starts off with a random value before getting corrected. Pic below is for energy today, but I see the same issue on the energy total sensor too. Example below where I restarted at 9:52:

spike history1 history 2
gcoan commented 2 weeks ago

That's very surprising. I too use the GivTCP sensors (solar generation, import and export) to feed my energy dashboard but I never see such spikes occurring.

The energy dashboard uses the long term statistics to feed the dashboard which is why its always lagged behind live data, to get spikes that big it means that the sensor is reading rubbish values for quite a while. I've noticed givtcp v3 takes much longer to start up than v2 which could contribute to this, but I still find it surprising.

One thing I do differently which maybe what stops me getting these issues is that I wrap the givtcp sensors inside a utility meter and use the utility meter for the energy dashboard. This was as recommended by a speak to the geek video, to abstract the live data from its use in HA so that if for example you ever had an inverter replaced you could just change the utility meter config and all the history would be preserved.

I'm wondering if whilst the givtcp sensor goes unknown the utility meter preserves the old value?

sammort commented 2 weeks ago

I also see these large spikes frequently when using GivTCP data in the energy dashboard, note there was no charging of the battery from 4pm onwards in the below screenshot (and my single AIO couldn't charge 21kWh in one hour):

image

I frequently have to go in to HA's Developer Tools > Statistics and use the outliers tool to find the spikes and remove them.

image

In my case HA is not being restarted at these times and the graph for the entity also doesn't show the spike itself (I guess HA is filtering the outliers automatically?). I don't see any corresponding logs that might indicate why this is happening (i.e there's no restarts of GivTCP or comms errors that I can see).

image

EDIT: In the History tab it is possible to see the spikes on the entity, though I still have no idea what is causing this:

image
sammort commented 2 weeks ago

One thing I do differently which maybe what stops me getting these issues is that I wrap the givtcp sensors inside a utility meter and use the utility meter for the energy dashboard.

This is something I've always intended to do, but now I don't want to lose the long-running stats I've accumulated. Perhaps there's some way I could export the long-term stats from an entity to the new utility meter.

gcoan commented 2 weeks ago

One thing I do differently which maybe what stops me getting these issues is that I wrap the givtcp sensors inside a utility meter and use the utility meter for the energy dashboard.

This is something I've always intended to do, but now I don't want to lose the long-running stats I've accumulated. Perhaps there's some way I could export the long-term stats from an entity to the new utility meter.

There is a way to do that stats move, but actually you can if you're careful create a new sensor to take over the old sensor history.

But before doing so, suggest you create a utility meter in parallel with your existing sensors, and feed it into the energy dashboard alongside your existing sensors to see if this fixes the issue. Then can worry about cutting over from old to new without losing history.

Nilogax commented 2 weeks ago

@sammort did you see those spikes on previous versions or only since moving to V3?

My 'battery charge energy today' has started spiking since changing to V3 but the 'Total' sensor (that I use in the energy dashboard) isn't affected. These do not relate to restarts.

Screenshot_20240922-145200

gcoan commented 1 week ago

Currently running v2.4.9

I've just spotted that I am seeing the same spikes on my GivTCP with 2x hybrid inverters. I can see several sensors spiking at the same time, battery charge, discharge, solar generation, e.g

Export, battery discharge and solar spike at the same time on the 20th: image

Looking at the outliers reported in the stats it looks like this has been happening intermittently for quite some time, certainly on v2, and my use of utility meters hasn't saved me from them image

gcoan commented 1 week ago

I'm wondering if the spikes are caused by the sensors being total_increasing that then get unexpectedly lower values - item 4 on this energy dashboard FAQ https://gist.github.com/langestefan/acbf7e42b15b302e9aacc08663039e57 ?

dmlambert99 commented 1 week ago

I now think I may have found that the fix for my issue is already built in and I was just unaware of it. In the GivTCP config there is a setting for MQTT retain. That was disabled in my case, which may be the default setting, so I tried turning it on and now on restart my consumption and export (etc.) entities are briefly unavailable but then resume at the correct number with no random number first, which ought to solve my problem (I can't confirm immediately due to interval between energy dashboard updates)

gcoan commented 1 week ago

In the GivTCP config there is a setting for MQTT retain. That was disabled in my case, which may be the default setting

Ooh, I just checked my GivTCP v2 config and mine was also set with retain = False, which is indeed the default setting.

I've set it to True and 🤞 its the fix

Nilogax commented 1 week ago

Hmmmm - my config has retain switched on and I'm still seeing those spikes. Maybe a different issue though as it just seems to be on one sensor.

sammort commented 1 week ago

I also have "MQTT_Retain": true in settings (which has been the case since moving to v3) and I've been seeing the issue and it doesn't correlate with restarts of the container for me.

It did also happen with v2.

dmlambert99 commented 1 week ago

I have done a restart in a fresh hourly timeslot and didn't get any spike on my dashboard as a result, so my issue does indeed seem to be fixed by that (I am running V2 only at the moment).