Unstable(?) Websocket Connection Confusing HA Statistics?

[MarkusMit]

Hi.
I'm experiencing some issues with the HA statstics of entities created by the ha-goecharger-api2 integration, and helper sensors depending on those, as well as the Energy dashboard.
E.g. the statistics of sensor.goe_******_eto show unplausible negative and positive jumps of 1.200 kWhs - unfortunately I already fixed those manually - but Looking at the history of the sensor I noticed gaps at those times:

So looked a bit closer, and I noticed that at the same times all the sensors of the ha-goecharger-api2 device become unknown (unbekannt) for a few seconds or minutes, then they come back. e.g. select.goe_******_lmo (as _eto doesn't show up there):

Could this be related to unstable websocket connections I saw mentioned in other places?
Would it be possible to keep the sensors "available" even when the websocket connection fails? at least for a certain time?

[marq24]

TLDR; I have no reasonable explanation why this is happening to you...

Here is the theory of operation for this integration: The central point is a DataUpdateCoordinator. This Coordination has two containers in which the data of the different sensors are stored. Each Sensor has a unique key, that can be mapped to a API-Key from your go-eCharger...

Once the integration is started, the DataCoordinator is accessing the API (get request) and fill the first data container with all key's (and the corresponding values returned by the charger)... Once this is done a WebSocket connection will be established and a second data container will be created - for every field/api-key the websocket will provide an update, the integration generates / update the entry in this second data container.

To display a value for a sensor, the DataUpdateCordinator will provide a data container composed from the websocket-data and the web-request-container- prioritizing the websocket keys... With other words, if a value is "newer" in the websocket-data container, this value will be provided for the sensor.

When the websocket-connection goes down (even temporary) then none of the existing data-containers will be destroyed - they all will be kept in memory of your HA... Since even if the websocket (and it's data container would go down) there would still exist the web-api-request container with it's data (that indeed could be outdated)

IMHO (but of course I don't have a prove for that), when all your sensors become unknown , then this is cause of a restart of the integration - you might like to enable the debug login order to check if this is the case... Since at least I can tell you for my local installation the mentioned sensor in your sceenshots will be "only" become unavailable here, when I restart my HA...

[MarkusMit]

Thanks for your quick response!
As those gaps happen at the strangest times, I'm quite sure that they are not only produced by HA reboots.
However, I will enable debug logging and see what I can observe.

[marq24]

don't have to be HA reboots/restarts - also can/could be integration restarts (that could be also triggered remotely)... But as I tried to explain - currently I am clueless, how the values can switch to 'unknown´ - stay there for some minutes - and then return... I will double check, what happens, when websocket might provide "null" for an existing key...

[marq24]

Let's see, if 'this' can fix your issue... https://github.com/marq24/ha-goecharger-api2/releases/tag/2026.5.1