Hello,
I experienced a negative measurement in my energy dashboard. The figure below comes from a single smart plug but it returned a negative measurement in March. Has anybody experienced something similar? It quite damages my long term statistics forever. Any ideas how to troubleshoot it or take it away from the database?
Long term statistics can be edited from the developer tools to edit out the outliers. They are often caused by sensors that change to 0 instead of unavailable. A common cause of that is when people use a float(0) filter in templates without using an availability template.
Another possible cause is a wrong state class on your sensor. If the sensor periodically resets to 0 and starts counting fresh, then you should not use state class total, but total_increasing. In this case I suspect that last thing is your cause.
There are zeroes from 13th to 31st March. 13th another sensor (not utility meter) shows 14kWh but that’s not even included in the utility meter. I see different numbers in history but zeroes in long term statistics. This does not seem to be a problem of a sensor. What do you think?
Hello, thank you for your extensive answer but I got the error in LTS again. However, this time, I do not see peak in the power sensor from which the energy is calculated, neither the statistics contain an “outlier”. Would you have some tips how to find it and delete it?
Then I would be really helpful if you can explain me in detail how to make “an availability template” because that’s probably the cause. We use the plug only when charging the car in this place, then the plug is removed and becomes unavailable. Thank you.
What I do not understand is how the same sensor is differently interpreted. The figure shows the erroneous -350kW, while the dialog when I click on it does not show any erroneous measurement last month in September.
So where is the error? I do not see it using the tool provided in developer tools.
Some answer to multiple questions:
The dialog to fix statistics errors only shows very few entries, so unless the outlier button picks them up you’d need to know the time of the outlier up to 5 or 10 minutes.
How a sensor behaves in the energy dashboard when values drop (to 0 or otherwise) is determined by the state class of the sensor. What is the right state class depends on the behaviour of the sensor. Most of the time, state class total increasing is the best one, unless it is a sensor that counts backward for energy production.
Sensors going to 0 when they should be unavailable are always bad. If they are template sensors, an availability template can fix it, but if the sensor is from an integration, the integration developer should fix it.
Either way, details about the sensor (integration, yaml, attributes from developer tools, reset behaviour) are needed to fix issues like these.
Thanks for your reply, however, in contrast to previous situation, no sensor has a peak according which I would be able to determine the time. All sensors show correct data, just the LTS shows nonsense and the sensor I am analyzing from LTS perspective is a helper, utility meter.
ok solved, I do not need to go through all the exact time per 15mins in developer tools / statistics and look directly when outliers button doesn’t catch it. The energy dashboard itself is helpful because you can find the exact date and time in the daily view and quickly click backwards day by day.
1 Like
