Energy dashboard spikes on HA re-start

Occasionally I get ‘spikes’ etc. on my energy dashboard which I know how to correct via. developer tools etc. However, I have noticed that this mainly happens when I have re-started HA e.g. after installing an update. I am therefore wondering if it can be avoided. When I look at the relevant consumption entities the dashboard is using I don’t see any corresponding jumps, but I presume they will be temporarily unavailable on re-start which is interpreted as as zero, and then when they become available again that jump (from zero) is seen as consumption. Is this a feature of the energy dashboard, or could I do something with the entities to stop it happening?

Energy dashboard just uses long term statistics, it doesn’t record any data on its own, so if it’s an issue it’s probably an issue in the recorder, or in the integration itself.

You can confirm by making a statistics graph card of your entity and look for unusual changes in the sum around the time of the restart.

Generally unavailable shouldn’t be interpreted as zero, so I don’t think that’s the answer, as a sensor going unavailable and back does not cause a spike, but maybe there’s something else weird going on around the reset.

Sometimes poorly written template sensors report actual 0.0 when they should be unavailable, that can be a problem.

Share the history graphs of the sensors, including a restart, so we can see what is going on.

I have forced a restart and created a spike as expected. I had been looking at the history by just clicking on the entity and nothing was showing up, but I have now gone into the history card which seems to show more detail which seems to show the issue is that when the entity comes back online it initially has an incorrect value.

What is that a graph of?

It is the entity I am using to track consumption, which is from the GivTCP addon; the spurious value at restart wasn’t showing up on a less detailed graph (below), but I guess it is the reason for my spikes, rather than the dashboard itself, so I will redirect my query.

history1