Post 19 was rubbish. See imporant edit if you have been thinking of following my method.
Hi, Thanks for posting the top post, works perfect.
I do have another issue related to nordpool and cost. I convert my usage from an sensor showing kwh pr hour, updating at the hour. Using a simple template sensor I multiply with the nordpool price for the hour, getting a cost for the hour.
Problem: it is shows “un-natural” on a chart, as the cost of the hour from 13.00-14.00 ends in the graphs as shown as cost in the period from 14.00-15.00, as the sensor is created in the next hour. A easy method could be to run the calculation at 59minutes of the hour. However, not optimal for some other automations I have. Have you looked into something similar?
@khvej8 If you read my many updates you will find that this is the EXACT same issue I am fighting.
You cannot make a sensot that multiplies the kWh accumulated per time unit by current cost because you cannot control exactly when the two sensors change even if in theory they both change on the hour.
I am working on something and I think I have a solution cooking.
My big problem I am fighting is how to get rid of recorded wrong data. I see many are fighting that and the devs have not addressed the issue. When you setup something that is complex then you fail before you succeed. I have recorded 100000s of kroner some hours ago and I cannot get rid of the data. Even if you delete a utility_meter the data remains in the database and when you create it again it sticks. Even if you rename the sensor, it sticks because renaming in the UI does not alter the original name in the database. It sticks forever. They forget to clean the database when you delete utility_meter. Really annoying.
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
2 Likes
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
1 Like
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