Electricity Day Ahead Prices for Home Assistant using Node-Red and Entso-E API

Share your Projects!
34

So I thought, let’s take a look at long term price fluctuations per day, because that’s the only thing that makes it interesting to trade energy on a daily basis.

image
image1525×996 233 KB

standard deviation is on the right Y-axis, minimum and maximum on the left Y-axis. Damn, look at the volatility on the electricity market, completely unreal if you compare since 2015.
Question is, will this stay this way? And thus make it interesting to invest in a home battery for trading?

Couple of things are new now of course, in relation to the situation since 2015.

  1. Corona hit;
  2. Nasty stuff in Europe;
  3. Green deal/energy transition, etc, etc.

So we can probably expect to have higher volatility in the future, but as high as we have now? mmm… I’m not to sure if we should base our economic model for home battery on current price volatility. Maybe take half of the price fluctuation we see now to calculate longer term profitability for trading energy with a home battery. Then we can use that to look at the technical write-off cost per discharge-cycle to determine when to trade, and when not to trade.

The thinking process continues!

3 Likes
35

Just installed it. Will test it the next days!

1 Like
37

Glad to have came across your post.
I Just learned about the entsoe database today and was enthusiastically waiting to get the API key.
I was really interested in the volatily and the price spikes that might occur.

Your graph reveals that you’re a fellow dutchie, so I decided to share my own view on this most intriguing option to help with the reduction of the current energy bill and the energie transition (If there are more batteries in residential areas then more effective PV usage doesn’t depend on the grid providers ability to increase the high voltage lines throughput making the grid more stable - if done right).
Since we have the same rules and regulations to contend with my input should be more applicable to you.

I’m currently building a battery back-up system (65Kwh capacity) with:

  • 4 seplos diy rack kits (complete kit for which you only need to provide prismatic cells)
  • 64 prismatic 320Ah eve cells (If searched for on alibaba you will be able to get around 117$ per kwh instead of >180$)
  • 2 victron multiplus II 5000W inverters (due to my 40A - 230*40 = 9.200w - grid connection limit)
  • Some breakers and ground fault protection devices to reduce the risks of something breaking (sized for my exact setup)
  • 14 395 w jinko panels
  • Solaredge se5000h

One important part of why I’m already in the process of building the battery is that the rules and regulations (as I was able to find in the 2e kamer documents) seem to perfectly align in the coming year for maximum return on investment, while minimizing the risk that you’re exposed to.
Next year there will be a price ceiling for 2900Kwh set at 0,4 euro.
Currently this still seems to be applicable for dynamic contracts (hence the reduced risk)

Because (and this is important and the reason why I mentioned my PV setup) on the other hand we still have 2 years of the “salderingsregeling” meaning that providers like tibber will fully refund taxes for all consumed Kwh up until when you start using more than you produced.
This allows us to calculate the round trip efficiency (I took an low estimated 85% on my sized system) and multiple that to the daily difference between the highest hours and the lowest hours pricing.

What I noticed is that the energy prices dip between 03:00 and 05:00 (of course not always but that can be smatified in automation) and between 12:00 and 15:00.
While the peaks fall in between around 07:00 - 09:00 and 17:00 - 19:00.

With 4 hours intake a cycle and 4 hourse discharging a cycle for 2 times a day with an average (calculated based on data that I got from the frank energy api over the last few weeks) of 0,15 cents return per Kwh on each round-trip.

Due to the modularity of my bms system I’m able to only replace the cells (which should last 4000 cycles at the least at my intended charge / discharge cycles) when the battery starts to degrade due to “age”.
Which is around 1/3 of the entire system cost.
Resulting in around 5 cents required to be made for each cycle (with only 4000 cycles max) to be net zero in usage costs. (disregarding the round-trip efficiency loss that I compensate with PV to prevent the “salderingsregeling” from reducing the profitability of the setup)

Meaning that with the 0,15 cents price difference it comes down to 2/3 profit and 1/3 cost of wear and tear. (also simplifying by not including the maintenance after multiple years off usage of the rest of the setup).

Meaning that making a profit with buying and selling energy is an valid option while also allowing you to get rid of the energy providers “variabel contract” absurly high prices (profit margins) and give the profit to yourself instead by allowing you to get energy when it is cheap. Use and sell it when prices are high and buffer your solar production in the battery bank for when the prices are highest (usually not when everybody is producing solar - who would have guessed)

This has the added benefit off reducing stress on the grid and instead of inverters shutting down (for you and your neighbour) due to high net voltage it would help reduce the grid voltage so that everybody wins.
Even if the impact of a single battery bank isn’t that big on the entire grid (with enough people doing it and a large enough battery bank to saturate your own grid supply) it will help.
And for when it doesn’t a programmable esp32 relay will provide an 230v 40A magnetic relais with an signal for my house to disconnect from the grid.

In that way at least the PV production doesn’t get wasted.
Since, the inverters will use their UPS functionality to keep the lights on.

The most difficult part is going to be creating an automation for when to sell and when to buy.
While also tracking the origin/cost of Kwh’s going in and prices when going out of your battery (for cost/savings/profit tracking purposes)
Since, this would need to consider PV production estimate, current consumption, average daily consumption from current time point, desired DOD %, whether next peak is the best moment to sell with all available data (for example currently “tanking” on sunday and selling on monday throughout the day is insanely profitable it seems) etc.
The more “complex” the automation the higher the return will be (and the more invisible savings will become visible) but also the higher the chances off a bug or unforeseen situation costing you money instead.

At the very least it is a fun hobby project to do and with the end of “salderingsregeling” in sight and my PV setup and the possibility to buy energy when it’s cheap will ensure that the system will eventually pay for itself.
Because even when hour prices become constant during the day you will still save on the VAT that you don’t have to pay by self consuming your solar output.
So it’s not a matter of if the setup will pay for itself but rather how long it will take.

Once you go down the rabbit hole, the thinking never stops!

4 Likes
38

Due to Day-light-saving hassle still ongoing in Europe, this “No DST” option become more timely relevant. I noticed that “tpriceArray = flow.get(“tpArray”);” was missing from the latter one?

39

Yeah, so it was :slight_smile:

Like said earlier, this was quite “quick & dirty” solution I put together in few tens of minutes waiting for more elegant ones from someone who does these from living etc…

Also looks like there are some other things to take look at as well, e.g. DST recognition seems not to work as intended.

To all: Feel free to present a solutions, suggestion etc., I’m a bit busy at the moment…

40

…checked the DST-check thingy

if (new Date().getTimezoneOffset() < -150) {
    msg.payload = "true";
}
else {
    msg.payload = "false";
}
return msg;

Note there was a typo in the last “payload” (was paylaod) in my original sample, fix that.

Also, what this daylight checking does, is that it gets the offset value in minutes between current timezone and UTC. In Finland during DST it is -180 and otherwise -120. That’s why the comparison; it makes the difference between these 2 situations…

41

Anyway, after quickly checking the thread after a long period of time, there seems to be a whole new general-purpose integration for this by @JaccoR

I have not checked it, it is probably more usable, so check it out. I’m going to continue with my own node-red thingy for several reasons; it does what I need, I somewhat understand what it does so I can alter the code later, if I wish to try something new and also, I 'm not dependent on external integrations.

:slight_smile:

1 Like
42

Hi mekanics!

I follow your logic :slight_smile: I am somewhat able to understand what it does yet the creating code like you have done is a bit more difficult to me.

My understanding after quick look is that the timing might be wrong for one hour still. It is one hour earlier in this implementation if I have now understood correctly by comparing prices this gives and Entso-e side (Fingrid app as well). Did I find this correct?

Will those time-ranges in URL play some role? Seems price from T00:00 is weird (not from yesterday array either) and after that it is shifted by one… Or maybe it was actually due to “25hrs” of yesterday.

43

Yeah,

Checking again the Restful API it says the following:

It is important to take area’s timezone into consideration, as well as winter/summer time. For example, consider the day of February 2 2016 in CET. This is during winter time and hence using UTC this day is considered to start at 2016-01-01 at 23:00 and end at 2016-01-02 at 23:00. As another example, the day of July 5 2016 in CET is during summer time and using UTC this day is considered to start at 2016-07-04 at 22:00 and end at 2016-07-05 at 22:00.

…which means that we actually do not need the DST checking at all. The server also makes the one hour shift in it’s response, so we can remove the check DST route.

The other interesting thing is, that there actually is one extra value for 30.10., the 3:00 value is doubled and altogether we get 25 values for that day, which is correct in this situation though. The two 03:00 values are also different, which also makes sense; there of course is a bit different pricing environment for both these 03:00 hours.

Because of this there was a 1 hour shift for the rest of the day, this kind of indexed method of getting the values did not “see that coming”

Also, the periodEnd value of all the url’s generated in the 3 generate urls blocks should be set to 22:00 to avoid the range from going to another day’s range, in which case it would return two 24 hour sets of values.

So the url should be e.g. in yesterday url of form:

https://web-api.tp.entsoe.eu/api?securityToken=MY_TOKEN_HERE&documentType=A44&in_Domain=10YFI-1--------U&out_Domain=10YFI-1--------U&periodStart="+yesterdayString+"0000&periodEnd="+yesterdayString+"2200"

Let’s keep an eye on it after the changes for few days… However, with this structure I can foresee similar hassle in the spring again, not because of the DST change itself, but because of the missing hour, there will be one day with only 23 values for the day returned…

Anyway, because of the general debate around this DST, it could be that we do not have it anymore in the spring

44

Thank you for this! Something like this I was also about to conclude inbthe morning but it helps to get another opinion for this!

And yes the weird value as the first price value today was truly the 24th hour (index 23) and it also didn’t know the 25th (no index 24) hour of the day. Small error and happens only twice per year :blush:

45

I installed it and al data is coming in! Nice work!,
I live in a appartement and no space voor pv panels. It would be wonderfull if natural gas price can be added in a coming version. Then I can compare price MJoule eletricity with price MJoule natural gas.
Then I could try switching between heating with gas or electricity.

1 Like
46

Hello,
I did made copy configuration of Hhalewijn.
But I get the same problem.
node-red is working.
Mqtt get some messages, but not data in homeassist. logging

time=“2023-01-07T13:51:33+01:00” level=debug msg=“Superuser check with backend Files”
time=“2023-01-07T13:51:33+01:00” level=debug msg=“Superuser check with backend HTTP”
time=“2023-01-07T13:51:33+01:00” level=debug msg=“http request approved for leon”
time=“2023-01-07T13:51:33+01:00” level=debug msg=“superuser leon acl authenticated with backend HTTP”
time=“2023-01-07T13:51:33+01:00” level=debug msg=“setting acl cache (granted = true) for xxxx”
time=“2023-01-07T13:51:33+01:00” level=debug msg=“to auth record: [97 99 108 45 108 101 111 110 45 101 110 115 116 111 101 47 100 97 121 45 97 104 101 97 100 45 110 111 100 101 114 101 100 95 57 52 52 101 55 57 102 57 53 99 51 100 50 52 51 52 45 50 218 57 163 238 94 107 75 13 50 85 191 239 149 96 24 144 175 216 7 9]\n”
time=“2023-01-07T13:51:33+01:00” level=debug msg=“Acl is true for user xxxx”

Day-ahead-price and others say still unkown.

Anyone any idee?

47

Hi, have you been able to just download the data from ENTSO using the URL with you API-code? this is a way to check if ENTSO is accepting your request. If that succeeds, you can carry on with Node Red and HA.
regards, Harold

48

Check out Electricity price right now - Home Assistant REST integration for a simpler alternative utilizing entso-e and rest integration, also has currency conversion and support for extra fees and VAT factor. And no api key needed :slight_smile:

Pull requests welcome!

Description page

49

Hi,
I get the following debug message on triggering the first timestamp:

“TypeError: Cannot read properties of undefined (reading ‘TimeSeries’)”

any hints where to search for a solution?

50

Please help, after 14/2/2023 I’m now getting an error, - I’ve updated the token to see if it was the problem, - and no it was not :confused:

My URL have been working for over 9 months:

var urlAddr = “https://transparency.entsoe.eu/api?securityToken=XXXXXXXXXXX&documentType=A44&in_Domain=10YDK-2--------M&out_Domain=10YDK-2--------M&periodStart=” + todayString + “0000&periodEnd=” + todayString + “2300”

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <link rel="icon" type="image/png" href="favicon.png"/>
    <title>ENTSO-E Transparency Platform</title>
    <style type="text/css" media="screen">

        object:focus {
            outline: none;
        }

        /**     * Eric Meyer's Reset CSS v2.0 (http://meyerweb.com/eric/tools/css/reset/)     * http://cssreset.com     */
        html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td, article, aside, canvas, details, embed, figure, figcaption, footer, header, hgroup, menu, nav, output, ruby, section, summary, time, mark, audio, video {
            margin: 0;
            padding: 0;
  ...
51

Since mid february '23 the old address has stopped working, so from now on the new address as mentioned is mandatory:

"https://web-api.tp.entsoe.eu/api...
52

Yeah, that has been used as you see from posts above. No problems in that. Nor in anything else currently.

53

Entso-e was having some issues but lately been reliable again.

55

Now system running more than half a year… few problems from Entso-e and momentarily issues from heatpump loosing connection to internet (and also local grid). Experience so far is that this home assistant system has been working nice… approx. 15…30% savings in energy price compared to Nordpool average price for the month.

Soon we are getting 15min price system in Finland, if I understood from Fingrid’s information. We need to update the system for 96 row system instead of 24 :slight_smile: