Since a month or so, not sure when it exactly started, an energy sensor (that is the sum of two MQTT sensors) shows occasional spikes.
These spikes coincide with these errors
2025-11-02 04:56:55.904 WARNING (MainThread) [homeassistant.components.mqtt.client] Error returned from MQTT server: The connection was lost.
2025-11-03 13:02:41.667 WARNING (MainThread) [homeassistant.components.mqtt.client] Error returned from MQTT server: The connection was lost.
2025-11-03 13:33:20.278 WARNING (MainThread) [homeassistant.components.mqtt.client] Error returned from MQTT server: The connection was lost.
The last spikes occurred at 04:55, 13:00 and 13:30, same times as the MQTT errors. These spikes are the energy values at 5 minute intervals, which can be manually corrected using developer-tools/statistics. Usually these 5 minute values are about 0.02 to 0.04 kWh, when a spike occurs, they are over 5kWh.
The only retained messages I found were those from MQTT Auto Discovery, no retained messages with a value in it. So a retained message doesn’t seem to be the cause here.
Since other than updating HASS, nothing has changed the last couple of months, does anyone have any clue why this might be happening?
Show the template doing the summing. I’m 99% certain it is missing an availability template, but there may be other improvements needed. It will also help to see graphs of the values of the components and the sum at the time of the spike.
ps. For the energy dashboard you don’t need to sum things, just list them both. It gives more informative graphs. The dashboard handles outages better (assuming sensors go unavailable as they should. If they are not unavailable at those times then the problem is in what sends the values).
And when that is done, look inty why all those dropouts?
ps. For the energy dashboard you don’t need to sum things, just list them both. It gives more informative graphs. The dashboard handles outages better (assuming sensors go unavailable as they should. If they are not unavailable at those times then the problem is in what sends the values).
It’s not for that, the two seperate MQTT-sensors are listed there. But I also have a sankey-chart (for both power and energy) where the energy graph starts with the day and night/weekend counters seperately, followed by the total (the sum sensor) and then per device.
And when that is done, look inty why all those dropouts?
The connection losses? Haven’t figured that out yet. They happen a couple times a day, sometimes only once a day. Already checked if ESET Smart Security (on the W11 host, HASS in VMware Workstation) maybe randomly blocking something. Haven’t found anything yet.
But then, the MQTT server/broker is running in HASS, so HASS loses the connection with itself?
If one of these sensors is unavailable while the other is not (enough for the template to notice) this template returns about half of what it used to.
state_class: total_increasing
When that happens, in the energy dashboard, the other half is counted as totally new consumption or production, because toal_increasing treats it as a counter reset to 0 followed by a change for the half that was not unavailable.
There you have your spikes. Utility meters will behave just as bad. This has been this way for years.
The availability template makes sure the sensor is unavailable when not all data is present to get a proper result:
availability: "{{ has_value('sensor.e_in_1') and has_value('sensor.e_in_2') }}"
Sensors going to 0 unexpectedly without being unavailable is also a problem. When the right value returns you get a spike for the same reason. So even when both sensors go unavailable at the same time, you will still get the spikes because the 0 is treated as a total counter reset.
The drops in your graph should never happen. If the original mqtt sensor does this, then it should be fixed at the source. If that is i possible, you might need to extend the unavailability sensor to treat 0 as unavailable too. For total_increasing sensors that should not pose a problem.
@Edwin_D Thanks for the explanation , availability template has been added.
The drops in your graph should never happen. If the original mqtt sensor does this, then it should be fixed at the source. If that is i possible, you might need to extend the unavailability sensor to treat 0 as unavailable too. For total_increasing sensors that should not pose a problem.
The drops in the graph happen on the moments the log indicates a connection loss between the MQTT broker and client, both of which are running on HASS. I don’t suppose you could think of any reason what could cause that?
This is what E in 1 and E in 2 look like on the same day of the screenshot with the spikes (in the 5m values) and drops on the E in totaal graph:
The only thing out of the ordinary is that E in 1 seems to be missing some data, in a period it’s not increasing (daytime), E in 2 is increasing like it should. Both of which are send in the same MQTT-datamessage and also with gas and grid voltage.
, availability template has been added.
