Energy dashboard shows crazy and unrealistic energy spike

Hi,
Today the Energy Dashboard is showing a crazy number that is totally fake for my power consumption: 90 kWh in just one hour!

The sensor/device that accounts energy consumption is a Shelly EM, and it has NOT recorded such spike.
What has happened? And how can I fix this spike?

1 Like

You are showing the Power sensor history for the Shelly.

Show the Energy sensor history for the Shelly, particularly around 9am.

You can fix this in Developer Tools → Statistics. Find your energy sensor and click on the ramp icon to the right. Select the time the massive spike occurred (Somewhere around 8 to 9am) and edit it to 0 or an average of the readings either side of that time.

If you are using a template sensor to alter your Shelly EM total energy you may need to add an availability template to prevent this occurring again.

3 Likes

Here’s the Energy Sensor history.
Seems that the sensor became unavailable or something, but NOT because of the Shelly, as the latter is showing the right data. Something went wrong in HA itself?

I have adjusted the power consumption by replacing the wrong value as an average. Thank you!
How can we tell if this is a bug or something terrible happened to my instance?
At that time I was sleeping, so nobody changed anything in HA.

its because of the short moment with zero as value… then next value is correct, energy dash takes the the whole difference between the zero and proper value as consumed. Unavailble sensors better come back with Nan value instead of initiating with zero for this.
There is more on this topic , also in WTH.

As the Shelly device does not store historical data it’s impossible to say if it was caused by a bug in the Shelly firmware or the Home Assistant integration.

The dashboard itself is reporting correctly. If it sees some_value0some_value it will add the 0some_value step. This will not occur if the device reports some_valueunknownsome_value

My SMA solar inverter energy has done a similar thing in the past so I filter out all 0 states (and low values) and feed that to the energy dashboard.

You should add the correct device_class and state_class if using the filtered sensor directly with the energy dashboard (the utility meter adds these for me).

1 Like

To what data are you referring to?
I am using the ShellyForHass integration from HACS, I showed the data in the second post where you see the dip. It’s the one called “Consumi Generali” (renamed by me), and is a sensor created by ShellyForHass, I just added it to the Energy dashboard.
So I guess I can talk to the integration author: the instantaneous power consumption is correct, but the historical data is not.

The actual device has no history web page we can check to see if it actually sent 0 (= firmware bug) or not (=integration bug).

Is there any reason you are not using the core Shelly integration?

I use it for my Shelly EM and have never seen a spike like this.

the issue happens quite often - and is a regular topic.
The reason is exactly, as explained by tom - the sensor has a value of X - then, it received a 0 as value.
This can be caused by a reboot of homeassistant (and the integration has not yet reported a new state) - or for whatever reason else)…

In this case, the 0 will be added to the statistics - and when the sensor is getting the correct value again, this will again added as a caluclation step.
Resulting in a sum with OLD Value + New Value.

this can be resolved by:

  • integration developer should implement an “unavailable state” - or by creating a manual template sensor where you refer to the sensors state - but implement a check agains zero-values.
2 Likes

The convenience to use the App / Cloud service as well, which cannot be done if MQTT is enabled too.
Okay, I use the app rarely but is nice to have it.

1 Like

Hi Christoph,

if I understand u correctly, the best way to prevend this issue is to create a sensor manually and store this incorrect values there?

So it looks like this example here

        state: >
          {% if states('sensor.tasmota_strom_total_in') == 'unavailable' or states('sensor.tasmota_strom_total_in') < '1' %}
            {{ states('sensor.tasmota_wrong') }}
          {% else %}
            {{ states('sensor.tasmota_strom_total_in') }}
          {% endif %}

Source: Tasmota Smart Meter mit HomeAssistant | DreamzZ.IO

Am I right or what else is the best way to fix it?
Unfortunately I am not one of these pro guys and have to gather the knowledge. So I would be very grateful for help and feedback :slight_smile:

Hi, usually, such peaks happen, when the sensor is reporting a value like zero - instead of being unavailable or unknown.
Sometimes, this happens - if you restart HomeAssistant, the Integration was reloaded - but the sensor has not yet delivered a new or correct state.

So first - you should check if this is the case.

IF the sensor is in either unknown or unavailable state - this should not cause peaks in the energy dashboard.
If it does report zero values, this does cause such peaks.

The best thing in this case would be, that this behave will be fixed within the integration.

Sometimes, it happens, if you are using template sensors that these templates will show a zero-value if the source sensor is unavailable or unknown.
In this case, you should add the availability option to your template:

for example like this template:

  - sensor:
      - name: "Solaredge Calculated m1 Import"
        unique_id: "solaredge_calculated_m1_import"
        icon: mdi:transmission-tower-import
        unit_of_measurement: "kWh"
        device_class: energy
        state_class: total_increasing
        state: >
          {% set measured_import = states('sensor.solaredge_m1_imported_kwh') | float(0) %}
          {% set imported_before_meter_installation = 296.00 | float(0) %}
          {{ (measured_import + imported_before_meter_installation) | round(3, 0) }}
        availability: >
          {{ states('sensor.solaredge_m1_imported_kwh') not in ['unknown', 'unavailable', 'None'] }}

The core integration does not use mqtt. It uses CoIoT.

Yeah, I eventually discovered this and made the switch a couple of months ago.
The only problem is that the integration records energy consumption too frequently and it makes the DB grow huge.

1 Like

If you don’t mid the loss in resolution you can pass the energy sensor to a filter sensor and use that. Then exclude the original sensor from the recorder.

1 Like

I have a similar situation, where I got a peak in energy monitor, but no peak in the entities itself. This happend for the first time since I use the energy monitor:


image

The spikes are in all measurements, so energy consumption, photovoltaic production and gas consumption. But at this time there was no spikes in normal history, for example:



Can I somehow correct it? @tom_l you showed how to correct a statistic of an entity. Is there a way to correct the data of energy monitor?