Tried to have a look but I don’t understand how it works… Could you elaborate a bit ?
Below is the templates I use for for consumption and pv production (as well as on et off peak cost calulation):
For starters you were using the wrong state_class, and the last_reset attribute is no longer required.
That may have fixed it but just in case the availability template will also offer a bit of extra protection. I am assuming that sensor.kp_energy_tot_grid_consumption divided by 1000 is currently over 1400kWh from the erroneous result you got in your energy dashboard. if this is not the case, adjust the availability template 1400 number. The result of your template should be just greater than this.
Excellent, I have modified my setup according to your example… hopefully this will solve my issuer, let’s see next hour !
2 more questions…
I don’t understand what the is role of availability ? You are right, the ‘sensor.kp_energy_tot_grid_consumption’ divided by 1000 is > 1400kwh (it is 4445 kWh) therefore condition will be always True so why don’t we put ‘availability: True’ ?
As I have many days with wong cost, is it possible to correct the past datas ?
Because when your sensor goes into a fault condition it should report “unavailable” or “unknown”, the energy dashboard knows to ignore this.
However your template sensor uses a float filter that has a default of 0. So if it can’t convert the state of the watched sensor to a number it reports 0. So unavailable or unknown or none becomes 0.
This causes your energy to go from 4445 kWh to 0kWh when your watched sensor in the template goes off-line for whatever reason (including restarts). Then when the sensor comes on-line again it shoots back up to 4445 kWh. 0 to 4445 causes the energy dashboard to record that massive spike in energy use.
The availability template will return false when your template drops below 1400kWh, and this will change the template sensor state to unavailable protecting you from the massive spike in the energy dashboard when the sensor comes back on line as it will change from unavailable to 4445 kWh, and this will be ignored.
Thanks again for explanations. I have modified according your suggestions and restart HA. It looks ok for consumption but I got a spike for ‘return to grid’.
Change the 1000 values to just under the individual totals. This will catch the error if only one of those sensors goes off-line.
You shouldn’t have to.
I had one instance where my solar inverter total energy drooped down to zero rather than stepping directly down, but that was an issue with the SMA integration (which has been fixed).
For the correction of the wrong past data, I have decided to setup a VM of HA on my Unraid server (to be able to test the repair without breaking my live setuo), so I :
Backup my live HA
Create the VM on Unraid based on this image ‘haos_ova-7.2.qcow2’
Restore the backup
But the HA VM has issue with history and the energy dashboard does not appear whilst it should be a clone on my live setup which is working… any idea of the problem ?
Thansk again.
The database does not backup well, more often than not it gets corrupted. There is work being done to fix this but it’s not there yet.
You could try copying the home-assistant_v2.db file from one Home Assistant to the other. Stop Home Assistant before copying, and stop the new Home Assistant before pasting.
Or if you are using the MariaDB addon, stop the addon, create a partial backup of MariaDB only. Restore this to the VM Home Assistant.
Thanks again @tom_i , I have corrected all the past datas and it is working well. Moreover I have learned a bit of sql and the way statistics works i ha…
On the other hand backup/restore of mariadb is a nghtmare it barely never worked (corrupt database) but thats another story.
I have got a strange calculation of total cost. Its adding grid import and export together.
This started today when i have added static costs for the export with 3 digits like 0,051 to my energy dashboard.
I could fix this issue with correcting value to 0,05 as i found out that 3 digits are not supported.
Now the computation is correct.