The issue is that the daily sensor is not giving the same result as the template sensor although it’s basically the same only difference is a daily reset.
It’s because your usage of defaults for the float filters, in combination with the periodically resetting flag you enabled on the utility meter.
If you now reset HA, the defaults on the float filmster will cause your template sensor to become 0 until the integrations are loaded.
That will trigger the utility meter to think your meter has been reset, and it will add the new data to the value it already had, causing the state to double.
Use this template to avoid that (the state of you template sensor will be unknown instead of 0)
{% set y = states('sensor.sn_27762_daily_yield') | float('na') %}
{% set e = states('sensor.daily_solar_export') | float('na') %}
{% if y | is_number and e | is_number %}
{{ (y / 1000 - e) | round(2) }}
{% else %}
none
{% endif %}
BTW even with this, you can still get issues around midnight if both integrations don’t reset at the same time. If both also provide a lifetime sensor I would advice to use the m those instead.
Thank you for this information.
I have adapted the template sensors code, will see tomorrow after full day if that solves the issue. but I’m confident it will.
Seems the issue is still not good.
In fact I’ve notice that the value of ‘Daily Netto Solar Usage’ is close the the ‘Daily Solar Production’ while I’ll expect it must be equal to ‘Netto Solar Usage’
Again this is my template sensor yaml and that is a correct value, but when using this sensor in a utility meter it goes wrong.
{% set y = states('sensor.daily_solar_production') | float('na') %}
{% set e = states('sensor.daily_solar_export') | float('na') %}
{% if y | is_number and e | is_number %}
{{ (y - e) | round(2) }}
{% else %}
none
{% endif %}
I’d be willing to bet it isn’t doing exactly what you’d expect. Combining sensors (either with addition or subtraction) often leads to unexpected results, especially when using the output to drive a utility meter.
Yes, the calculated value is correct. But look at the graph of the sensor’s history. Is it truly continuously increasing, or is it jumping up and down even though the overall trend is increasing?
My bet is on the latter: it is jumping up and down. That would be because the two source sensors don’t update at the exact same time, and therefore your template sensor is triggered once when daily_yield changes (and so the template sensor gets larger) and then another time when solar_export changes (and this is when the template sensor decreases due to subtraction in the template).
When you created the utility meter, did you choose the “net consumption” option? If you don’t remember, you can look at the attributes in developer tools → states and find out if the state_class is total (meaning “net consumption” was selected) or if it is total_increasing (which means it wasn’t selected).
I’ll make another prediction that it is total_increasing because you didn’t select “net consumption”. So every time your template sensor decreases, that change is ignored by the total_increasing utility meter.
If all my guessing is actually correct, you have two options:
Option 1.
Delete the utility meter and the template sensor.
Then create a new trigger-based template sensor which has to be done in YAML and not using the UI. With a trigger-based template sensor, you can have the template only get updated when the daily_yield sensor has a new state. And therefore the template will always output a value that is larger than the previous reported value.
You can then re-create your utility sensor in the UI, and you can leave the “net consumption” option unselected.
Option 2:
Delete the utility meter.
Edit the template sensor you previous created, and change the state class from total_increasing to total. This won’t affect your current issue, but it will fix the next problem that you haven’t yet noticed, which is that the statistics for your template sensor are wrong.
Create a new utility meter with “net consumption” selected.
This new utility meter won’t ignore the sudden decreases that will still happen, so the running total will now be correct.
Thanks for your clear explanation.
Learning a lot from this.
indeed my sensor had “total increasing” and “net consumption” wasn’t ticked on the utility meter.
modified now as explained by you in option 2.
Should see the result tomorrow.
