Getting price configuration right

[jriisj]

Hi there!

I love my power monitoring setup and have it configured to integrate with other elements in my home. I find it super educational and a natural way of improving habits for me and the family.

I do however struggle with getting my price configuration right. I have an ENTSO-E API key up and running and it is pulling that data correctly. I would however like to include all of the various wonderful (irony is applied) tarifs we have in Denmark, which can be quite significant.

So my questions are

1. What is the base value øre or kroner (for most of EU the correlating values would be cents or euros)? It isn't clear to me from the documentation
2. Is there a gap in my "rules" (dates for various tarrifs) meaning that they aren't added (+) to the net price?

I have attached a screenshot of my rules as they are currently configured for reference

Here are the future hourly net prices (as of now) and I can't see a large increase correlating to the step up in tarrifs for peak this evening.

[ArnieO]

First of all, we no longer recommend to use the Entso-E API key. We have experienced a bit of outages on the API, so we have set up an intermediary server that fetches data from Entso-E - and have some other alternatives as backup. To fetch price data from our intermediate server, just leave the API key empty.

1. What is the base value øre or kroner (for most of EU the correlating values would be cents or euros)? It isn't clear to me from the documentation

Not sure that I understand the question, but the price is fetched from Entso-E in EUR, then calculated to the selected currency (in your case DKK, I assume) by using the exchange rate published for the same date on https://www.norges-bank.no/tema/Statistikk/Valutakurser/?tab=api
This could cause some very minor rounding errors if you compare to Danish sites that publish prices in DKK.

2. Is there a gap in my "rules" (dates for various tarrifs) meaning that they aren't added (+) to the net price?

Sorry, but I don't understand the question. Can you elaborate?

[jriisj]

Thanks for responding, I really appreciate it 👍 and great insight on no longer relying on Entso-E.
My first question was if the values I would add (+) to my "base price" should be noted in Kroner or Øre (the equvilant for someone in the US would be dollars or cents)? If it is in kroner then I would need to shift the decimal point up.

On my second question, from what I can deduct on the prices shown in the graph, my price configuration correctly adds VAT (25%) but does not add the tarrifs based on the dates and time of day (Sommer vs Winter and the various day part pricing). So I would naturally assume that I have not configured these correctly on my instance of AMS. So I was hoping someone could spot my mistake and let me know 😃

[ArnieO]

First question
The prices are automatically shown in Kroner (with decimals) when the highest price is above 1 krone, in øre if prices are lower. The prices transmitted on MQTT are always in Kroner.

Second question
Understood now! Sorry - I'm not able to spot it.
Maybe @gskjold can help?

[t-m-cor]

I think I just had the same problem as you.

As far as I could test, it seems that price calculations are skipped if end date is befor start date (in a calender).

You have (as I did, lives en .dk), some prices that runs from 1. oct to 31. mar, and as far as I can see/test, these entrys gets skipped/ignored.

To solve it, I had to split it into: 1. oct to 31. dec, and another/new from 1. jan to 31. mar.

So there is some logic that fails (IMHO). The calculations need to do something like “if end-date<start-date then end-date += 1year”, before comparing to current date.

Greetings from DK.

P.S. my test for “correct” prices, was done by comparing with elspotpris.dk , works great for .dk

[jriisj]

That actually makes a lot of sense and a little annoyed that I hadn't thought to try that as a possible solution. Thank you kind DK stranger!

[t-m-cor]

Created issue #886 (not sure how to reference it correctly ?)

[ArnieO]

Very helpful, I now (finally!) understand which issue @jriisj has! And I see @gskjold has marked this as a bug in #886, so I close this issue as it is a "pre-duplicate".