Got it working so big thanks to @mekanics!
I’m currently converting all my configurations from Nord Pool API to ENTSO-E. I’ve had binary sensors for example for lowest 2 hours but with this array I don’t know how to sort the prices. Ideas to do it? Would appreciate a lot for any tips.
Add: As the array contains strings and not datetimes I can’t compare them to each other. It seems difficult to convert string to datetime or at least I haven’t found a way.
Cheers 
I managed to draw graphs directly using node-red dashboard. That is now working perfectly.
But I have same difficulties with koelli, to find 2 - 4 lowest prices of the next day.
I started trying to solve the problem by using “findIndex()” and building function to compare values to that. After finding index of the cheapest prices, I could then convert those to hours. But I am not sure if this solution is going to work.
Here’s an example for two lowest hours:
- binary_sensor:
- name: Lowest price period_2_entso
unique_id: electricity_lowest_price_2_entso
state: >-
{% set l=state_attr('sensor.day_ahead_price', 'records')|sort(attribute='Price') %}
{% set t = now().isoformat() %}
{{ (t >= l[0].Time and t <= l[0].End)
or (t >= l[1].Time and t <= l[1].End) }}
And here’s an example for 12 lowest hours:
- binary_sensor:
- name: Lowest price period_12_entso
unique_id: electricity_lowest_price_12_entso
state: >-
{% set l=state_attr('sensor.day_ahead_price', 'records')|sort(attribute='Price') %}
{% set t = now().isoformat() %}
{{ (t >= l[0].Time and t <= l[0].End)
or (t >= l[1].Time and t <= l[1].End)
or (t >= l[2].Time and t <= l[2].End)
or (t >= l[3].Time and t <= l[3].End)
or (t >= l[4].Time and t <= l[4].End)
or (t >= l[5].Time and t <= l[5].End)
or (t >= l[6].Time and t <= l[6].End)
or (t >= l[7].Time and t <= l[7].End)
or (t >= l[8].Time and t <= l[8].End)
or (t >= l[9].Time and t <= l[9].End)
or (t >= l[10].Time and t <= l[10].End)
or (t >= l[11].Time and t <= l[11].End) }}
Almost a solution but not quite. When the array contains tomorrow values which are not available they’re not nulls but they are zeroes. And obviously zero is lower than most of the SPOT prices. Next should find a solution to fill the array with nulls and not zeroes.
Add: Easy to fill nulls but then the comparison for lowest hours doesn’t work as you can’t compare values with nulls. Oh my.
Add: Mean while let’s just fill the tomorrow’s array values with 99 so the comparison works. Quick and very dirty.
have you completed the implementation by including an algorithm that defines which hours are the best for enabling electical heating of the house? I would need that… (to control water boiler and electrical floor heating)
I have. Examples I gave will not work as they include few mistakes. I have also made some modifications to the original code as I needed to include night and day tariffs to the day ahead prices. I’ll add the codes to my original post soon.
I am working on an integration to fetch the day ahead energy prices from the ENTSO-e Transparency Platform. Check it out:
For now, it only considers Dutch prices, but I am working on adding all EU countries with some configuration. Edit: All countries are available now, just add your country code when setting up the integration.
It is the first integration I built, so it would be great if there are people willing to help me test and develop the integration.
Hi,
I was trying to get the prices for the netherlands. But i can’t find the url for it.
i tried to change FI for NL but that doesn’t work.
Anyone a idea?
thank you. It works now.
Hi!
I am new-be for this Home Assistant so please forgive simplistic question. I am OK so far to bring Entso-e prices to Home Assistant and that finding right index with & without daylight saving was pretty fancy.
Where I am stuck is that where to actually put this binary_sensor code? Configuration-yaml? In templating I assume I would not need the binary_sensor declarations (not sure if that is what to call it) but could use template within automation wizard as such? In templating this “.End” seems not working but tells UndefinedError: ‘dict object’ has no attribute ‘End’
Eventually the target is to turn on the heatpumps during the “lowest prices available”.
Would appreciate the help a lot!
Hi,
i started with the code and examples in the beginning of this post, worked my way up to a reasonable piece of work and have it now running for some weeks. I’m not used to document in this community or in Github but got some questions after posting some youtube video’s on this item.
So today I outputted the whole thing with all modifications to my own wordpress site. Unfortunatly it is written in Dutch but you can use the code since that is still in English. And if someone wants to publish it here, be my guest. Sorry for the lazyness…
Thanks a lot guys, I’m building along with you all and have everything working. Now the question is, how do we optimize for charging a battery when prices are lowest, and discharge when price is highest.
The question is: Can we make money using this information for automatic charge/discharge automations for a home battery setup?
Couple of things we need for that (I think):
I think we need to have 2 cycles of charge/discharge maximum per day based on what i see on the cost per kwh graph (or maybe a variable to decide that for ourselves).
Does this make sense or do I make this way to complicated?
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.
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.
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!
Just installed it. Will test it the next days!
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:
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!
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?
Yeah, so it was 
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…
…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…
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.
Hi mekanics!
I follow your logic 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.