You can delete all history from the developer console, the service is called “Recorder: Purge Entities”. It will delete all history on an entity.
To solve the problem of timing i have a triggerbased sensor, which updated on “59” minutes. I call the sensor for “nordpool previous hour price”, and then I use this one for the calculations.
You cannot purge entities from long term statistics. I have tried the purge service hours ago.
OK, believed it would remove everything. It removed the normal state information when I tried, however can see the problem of statestics
Ahm. It is partially true.
If a utility_meter is created and you add garbage, you first delete it in the UI.
Then you go to Developer tools → statistics and look for fix-me items. Fix and accept to delete
That seems to work.
Except it did not work with a sensor I created yesterday. Something went wrong in the dataset because it was not in the fixme list but I could see it in the sqlite DB and the data kept on coming back. What seems to have worked was that I stopped HA from CLI. Hacked all the JSON files getting rid of all traces of it. And then started HA again. And then I went to fixme and now it is finally gone. Surely a bug. But I cannot reproduce it now
Tried to repeat it again.
Deleting utility_meter, fixing, adding again. Old data coming back. It is not consistant. And I also purged database. Not enough. This was 2 minutes old data so I can live with it. But annoying that you have no control of the content in the database and cannot get rid of garbage without having to stop HA and use SQL tools to remove garbage from the DB.
Back to original problem
We want to calculate and display cost per time unit like hour or day
Again a reminder. My rock solid datainput is the actual meter reading from a Kamstrup meter which is a number in kWh with 2 decimals accuracy. It updates every 10 seconds. Except if the little ESP8266 choke and skips a reading but then next reading is an absolute reading and we catch up again.
I have changed from normal template sensor to a triggered template sensor.
In my configuration yaml I !include template: from a directory and I simply added a new file for triggered template sensor and the only one I have looks like this
- trigger:
- platform: state
entity_id: sensor.kamstrup_tpi
sensor:
- name: "Electricity Spend"
unique_id: electricity_spend
device_class: monetary
unit_of_measurement: "DKK"
state: >
{{ '%0.6f'|format( float(states('sensor.energi_data_service'),0) * ( float(states('sensor.kamstrup_tpi'),0) - float(this.attributes.last) ) ) }}
attributes:
last: >
{{ float(states('sensor.kamstrup_tpi'),0) }}
Let me explain.
So we trigger each time the Kamstrup meter has a new value. Ie every 10 seconds.
The sensor defined is named Electricity Spend and gets the entity ID sensor.electricity_spend
This is an incremental sensor that sends the amount in DKK spent since last reading.
The sensor has one attribute called last. And last is set to the same value that also triggered the sensor. But as it seems to work, the “this” object used in the state contains the object as it was before the trigger. So we can store the last value that the sensor was triggered for as an attribute and then next time we trigger we calculate the, current - last. And multiply with the price.
I have found that the price from the Energy Data Service works without glitches. At least so far. Good job Malene! But remember to add your local electricity “pusher” over-charge excl VAT to get an accurate figure.
Let us see how this works out. Note that I do not use round(). I could not make that work reliable and it also sucks to look at. I changed to the format and used 6 digits because we want to avoid accumulating errors. But without you get like 20 digits and that is hopeless to look at in a dash board.
To get the daily and hourly I create from helpers two utility_meters. One that resets hourly and one that resets daily. And the source is the electricity_spend sensor. And remember to tick off that it is a delta sensor.
Kenneth
Saw your updates to the documentation. Fantastic job. Thanks. And now your integration has run for several days I can say - not a glitch in the data. Super work
I see the resilience of this integration as pretty high, as it has fallback procedures in place, should the API from Energi Data Service not respond as expected.
Not sure if you saw it - but I have added all known additional cost templates, for when you enable automatic tariff data, to the wiki.
This page How to add costs of subscription and delivery? · MTrab/energidataservice Wiki · GitHub is GOLD. It lists a lot of the extra costs that you cannot find on the price pages from the companies.
Your source Live elpriser - elpriser time for time - inkl. spottillæg, transport, afgifter is also gold. You can see the Spotpris tillæg per kWh by manually setting your yearly consumption to 1 kWh on that page. Unfortunately the prices are rounded off to two decimals. I had to experiment a bit with the decimals to make the HA displayed price to fully match what I see the the Andel Energi App. Yes. I know it is silly. But I cannot help it. I am an engineer 
One more hint to those that follow this.
If you round off the cost using any of the integrations to two decimals, then you will accumulate errors.
On the other hand it is horrible to display the current electricity price with 6 decimals. Or more if you do not round at all.
A work around can be to create an additional template sensor used only for display purposes and then round that off to 2 decimals.
But there is also another little hack that works for entity cards
I also use the custom front end component Multiple Entity Row. And even if you do not want multiple entities in same row, the same component can round off a value to the number of decimals you like without affecting the actual sensor that keeps is full precision.
Just use this in the entity card
- entity: sensor.energi_data_service
type: custom:multiple-entity-row
format: precision2
it is not perfect as the perfect component would set the decimals to fixed number - also if the last decimals are zeros. But it is OK. Better than 3.4120999999999999999999
Hey. I also had the custom component template-entity-row installed. That can do the exact thing we want
- type: custom:template-entity-row
entity: sensor.energi_data_service
state: >
{{ '%0.2f'|format(float(states('sensor.energi_data_service'))) }} DKK/kWh
Price shown with exactly two decimals. Hurray
But there is a problem with the card editor. Every time you reopen to edit, it does a molestation of the template and you have to fix it each time to save it. It tries to be smart but either dupplicates single quotes or change > to | and then it does not work. Very annoying. I need to find a generic example because I fear the front end devs will not look at it when it relates to a custom component
@BlackChart Here on january 31st, your integration does not use the February tarifs for tomorrows prices. Not a huge issue but would just mention. My manual method used for the Nordpool integration seems to work. That integration recalculates hour by hour using the february data from the matrix.
Now will the price after midnight be correct? That one is important for my accumulated cost calculation
@WallyR The Eloverblik integration does not update tariffs to February. It is 1st of February 10:15 am and not even HA restart makes it update. So I guess the data source is not reliable. Maybe human update it when they have time. For exact calculation of consumption in money I need a reliable source so for the moment my original post has worked the best. It changed at midnight and calculated tomorrows prices correctly on Jan 31st. Unfortunately it requires manual updating in advance but you can do that months in advance and just have to keep an eye on the one tariff that changes each month
I have not checked it myself, but I guess the error must be at the eloverblik.dk site then, which is run by EnergiNet, a company under the governments control.
https://eloverblik.dk/about
@KennethLavrsen Tried using your template in post 28. Replaced your Kamstrup sensor with mine but got an error
UndefinedError: ‘this’ is undefined
What do I do wrong?
What version of HA do you run?
I think the “this” object was added to one of the newer versions.
I run the latest. 2023.2
looking at the code it could be a cyclic reference issue.
“this” is referring to the current sensor, but on setting up the state the first time, there is no attribute called last, so it fails.
This is just a guess though.
You may be right. How do I fix that. Thank you
Remove the below text from the setup, then save and restart.
Now the value is created, so re-add the text again and save and restart.