Hello. I’ve set up Home Assistant to track how much money I would have paid for electricity if I didn’t have solar panels. I’ve got a sensor to track how much home generated energy I have used, multiplied by my current standard import rate. However, I’m having a problem with the sensor which sometimes spikes at 00:00 when the sensor resets. This causes the utility meter to give an inaccurate reading. I thought I’d solved this problem with the addition of an availability template, but it doesn’t seem to be helping. This is my template sensor:
- sensor:
- name: "Daily Solar Savings Raw"
unique_id: daily_solar_savings_raw
unit_of_measurement: "£"
state_class: measurement
device_class: monetary
availability: >
{{
state_attr('sensor.flux_import_rates', 'standard') | is_number
and states('sensor.daily_solar_kwh') | is_number
and states('sensor.daily_export_off_peak_kwh') | is_number
and states('sensor.daily_export_standard_kwh') | is_number
and states('sensor.daily_export_peak_kwh') | is_number
}}
state: >
{% set std = state_attr('sensor.flux_import_rates', 'standard') | float %}
{% set solar = states('sensor.daily_solar_kwh') | float %}
{% set export = (
states('sensor.daily_export_off_peak_kwh') | float +
states('sensor.daily_export_standard_kwh') | float +
states('sensor.daily_export_peak_kwh') | float
) %}
{% set self = [solar - export, 0] | max %}
{{ (self * std) | round(2) }}
You can see below where I sometimes get a spike when the sensor resets at midnight.
I’ve only been using home assistant for a few months. I’ve learned a lot, but I am still very much a beginner. If anybody is able to offer any advice on what’s happening and how I can fix this issue, I’d be most grateful. Many thanks.
Solar and export each trigger a calculation when they change to 0, if export sets to 0 before solar you get the spike. Maybe make a trigger based template sensor instead? it sill allow you to add a condition to ignore an update at midnight if only one of the two is 0.
Another (maybe somewhat crude) option is to make the sensor unavailable when only one of the sensors is 0 at midnight.
Sensors that accumulate are best left as non-resetting, especially when you need to combine two or more by addition or subtraction. The totals for a specific interval (hour, day, week, month, year, etc) can be obtained via statistics rather than creating a sensor for each interval.
In your case, the statistics are wrong because you have state_class: measurement when it should instead be set to state_class: total_increasing. That is probably not a problem you were even aware of but you should fix it anyway.
If you want to keep all your sensors as daily resetting, that’s still possible, you can follow any of the suggestions Edwin shared. My usual recommendation is the trigger-based template sensor route so you can manage when your template sensor renders.
One more thing that often causes exactly these midnight spikes: at the reset moment the two source sensors briefly disagree, with one resetting to 0 or going unavailable while the other still holds its old value, so the template computes a bogus intermediate result. Adding an availability template that requires both source sensors to be numeric (not unavailable or unknown) keeps the sensor unavailable instead of rendering 0 during the reset window, and unavailable states are excluded from statistics. Combined with the total_increasing state class mentioned above, that usually flattens the spikes completely.
Thanks very much for all your advice. I’m not keen on changing to non-resetting sensors at this stage because the changes required to the rest of my setup would be quite significant. But, it’s helpful knowledge for the future. I was using originally using state_class: total_increasing, but l wondered whether this may be causing the problem, so I changed it to measurement. Thanks for the confirmation @mekaneck that it should be total_increasing. I will change it back. I’ll also investigate the trigger based template solution, and makes some amends to the availability template this weekend and see how I get on. Thanks again.
