I have been spending months trying to find the best way to filter abnormal energy readings from energy sensor so that I can get an accurate sensor reading and filter out abnormal energy readings. None of the built in filters are designed for consumption (the value always goes up unless a device reading resets to 0). I was told to use a availability template only which works to make sure problems like you sensor going to unknown then back to it’s regular reading would cause an energy spike. I tried creating a custom component and I made my own custom filter specifically for consumption and was going to distribute it to the community (hoping to have it added eventually to the default filters but really it just is a lot of extra work when a template sensor can do the same simple job and can follow the same logic and I can change the source devices id in a template sensor in the UI you can’t do that for a filter, you have to delete it and recreate it
Here is my code for the template sensor:
{% set max_jump = 0.1 %}
{% set raw = states('sensor.123_test_sensor') %}
{% set last_state = this.state %}
{% set raw_invalid = raw in ['unknown', 'unavailable', 'none', ''] %}
{% set last_invalid = last_state in ['unknown', 'unavailable', 'none', ''] %}
{% if raw_invalid and last_invalid %}
unavailable
{% elif raw_invalid %}
{{ last_state }}
{% elif last_invalid %}
{{ raw | float }}
{% else %}
{% set current = raw | float %}
{% set last = last_state | float %}
{% if (current - last) | abs <= max_jump %}
{{ current }}
{% else %}
{{ last }}
{% endif %}
{% endif %}
You’ll need to adjust the max_jump
value to best fit your device. This value defines the maximum allowed change between readings from the original sensor — think of it like a bandpass filter. Only changes up to and including max_jump
are accepted.
If the new reading increases by more than max_jump
, or the reading decreases the filter will discard it and keep the last valid reading from the filter.
To fine-tune this, let the filter run for a few days and observe your typical energy usage per update. Be sure to give the filter some breathing room — if your max_jump
is too tight, a legitimate increase could be ignored, and the filter may get “stuck” with an outdated value that never catches up. If that happens, the only recovery is to reset your original sensor to 0.
Set the raw
value to your energy sensor that is the source of truth for energy consumption.
I know I could use an availability sensor but I really like the ability to use the UI for making changes without reboots. And either way it’s returning an ‘unavailable’ so why not do it in the UI and just put the logic first? same difference?
I have been running this for a bit with no issue but looking for feedback if I am missing something. I want some hardened code for other users to use when they want to filter energy readings to make sure they are getting real expected values… We need to trust our energy reading and we can’t do that without some kind of filter it seems… There is no built in filter for this so this is the next best thing. I will keep updating the code above with any changes that anyone suggest to make this better.