Open dmlambert99 opened 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?
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):
I frequently have to go in to HA's Developer Tools > Statistics and use the outliers tool to find the spikes and remove them.
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).
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:
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.
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.
@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.
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:
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
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 ?
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)
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
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.
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.
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).
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: