-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Get 24h forecast of prices #3
Comments
Why do you need the imbalance prices for this and not the day ahead prices? Aren't the imbalance prices only available a couple of seconds before the energy is actually used? The code is already set up to fetch the day ahead prices of the whole day. However, now it only saves the current price to the database and not the whole day. It's indeed a nice feature to have and when I have time I will look into it. Does anyone know of an integration that does something similar (adding future data to a sensor) so we can look how its done? |
Yes, you're right. The day ahead prices needs only to be loaded just after midnight so we could it use it in HA automations. Sorry, I'm new to dev HA integrations and python. |
For help you could take a look at this code: written by trippelb, sadly he never made an addon .. |
@JanLankhorst that would probably work, but it feels more like a work around to make a seperate sensors for every hour. I would argue that, for example, "hour 1" is a current state (or state attribute). Ideally you would want to have one sensor that would have data on the future hours so you can plot these. Found this issue about forecast states. Apparently there is currently no support for future values in home assistant. So it would be very hard to implement this. Some extremely powerful automations can be made with future values. I can add some more sensors for a couple of hours, or some time states of the time at which prices are highest or lowest. However, having 24 sensors for every hour is not my preference. What do you think? |
Relative levels would be awesome, or working with attributes? 1 sensor with up-to 24 attributes should be possible I guess?; my use case is a home battery; typically there are two peaks a day; one in the morning and one in the early evening. My intention is to buy cheap twice a day and sell (taking into account expected own usage) at the peak levels; also taking into account expected PV yield and car battery "headroom". The invertor I intend to buy supports setting up 6 daily timeslots through mod bus. Next step would be to pre heat the buffer supply of the heat pump (provided I manage to get one!) |
@ronaldt80 What do you mean with relative sensors? I added a sensor that shows the current price as a percentage of the maximum price of the day, as I wanted to turn off the heat pump at the peaks above 70% of the max. Is that what you mean as well? Attributes may indeed be a good option I think. However making graphs with this is not very user friendly. How would you use these 24 attributes in your system? Btw, what battery do you use? I am looking for such a system myself as well. |
I'm looking into a 3 phase 8/10/12kw deye inverter combined with 3 5kwh battery units. Challenge is finding an electrician. Advantage of deye is that the modbus can be used to plot a charge/discharge pattern - raspberry pi and esphome both possible. |
The Nordpool integration has this, but it splits the prices in "today" and "tomorrow" with 24 different prices in each. That makes it difficult to use in HA because one night prices is in two different lists. The format is something like this `unit_of_measurement: NOK
|
Only add attribute data per 24h after midnight so you can use this data in HA automation. |
@blowk That would be my suggestion also. This approach makes it useful for calculation in HA. |
Alright, i managed to get the attributes into this format in the new commit: To also get the times is a bit more work, but it can be possible. This can be done in the format @stigvi mentioned. Another approach would be having separate attributes per hour. I am not sure which one would be more convenient. |
The format @stigvi mentioned should be ok. today_prices: 0.223, 0.197, 0.206, 0.169, 0.188, 0.197, 0.33, 0.427, 0.497, 0.209, 0.185, 0.154, 0.148, 0.149, 0.135, 0.14, 0.165, 0.184, 0.377, 0.252, 0.252, 0.169, 0.165, 0.147 would be like this, no? today_prices:
|
In your example: 0.223 will correspond with 00:00-01:00, 0.197 with 01:00-02:00 etc. When I have time this week I will look into getting the times in there as well. The format will probably look something like this:
|
That would be great. With timestamps, it is possible to sort this list based on price and it would be easy to find the cheapest or most expensive N hours. |
Managed to get the timestamped prices in the attributes in the new commit. Let me know if you have any issues. |
Thanks!. Seems to work for me:
|
Looks good. But I have only today's prices in my HA. Should tomorrows prices be in that list, also? |
The prices are only published one day ahead |
Thats is unfortunate. It makes planning car charging from 22:00 to 06:00 not so easy. And a little bit strange because prices for friday is available mid day on thursday in Norway. Edit: When I look at transparency.entsoe, I see that prices for tomorrow is indeed available |
Oh that is interesting, it would probably be possible to make a sensor with the data for as far ahead as the data goes |
I hope so. If I can have a list with today and tomorrows prices, it is easy to select the elements from 22:00 to 06:00 next day, sort it on price and then select the 4 cheapest hours. |
Prices of the day after come available some time in the afternoon I think (my guess is at 15:00). Can't find anything about it online though. We'll have to watch at what time prices of the following day are available. Extending the forecast would be nice indeed. The code is setup to fetch from 00:00 till 23:00 and all sensors are based on that, so this would mean a fairly big overhaul of how the integration fetches prices and calculates max, min and avg. |
Thanks for the input.
|
I will make some small changes to the attributes to fetch the prices of the day after. I deleted the non timestamped price list, as i don't think it is necessary. Let me know if I am wrong on this. The timestamped attributes will now ditch the "timestamped" term and be called @blowk in your case it means that if you only want to show the prices of today in the graph you need to change data_generator to:
@stigvi @mmoerdijk I think with this you should be able to have the data for as far ahead as the data goes and select the cheapest hours between 22:00 and 6:00 after the prices of the following day are available by calling the If everything works I will commit it in a few hours. |
@JaccoR Thanks for the changes!
|
Tried a bit of templating but get stuck on the format of the time value. Could it be the time is stored as a string where as the nordpool integration records it as a time value? What I want to do:
Any help would be much appreciated |
And question, does anyone know why the apex card prints the last value of the series in the legend? Eg. in the above example 0.149 and 0.234? |
@ronaldt80 Yes the time is a string, I thought converting it to a string was the only way to get it into attributes as timevalues gave some errors. I also thought that the nordpool integration converted it to a string hence the quotation marks. Do you know this?
That's the way @blowk set it up. Its the value of the sensors used for plotting the attributes ( |
@ronaldt80 : you can also plot one serie in apex chart and use the prices attribute, so it will plot all price of 48 hours. Before noon, the prices for the next day will not be available, but in the afternoon it will be updated.
|
I will close this issue because the feature is now already included in the integration. |
|
Thanks!! |
Maybe it should be interested if we could get a price range for 24h, so you can create an chart with for example ApexCharts card
I see in the readme of https://github.com/EnergieID/entsoe-py, there is query_imbalance_prices
client.query_imbalance_prices(country_code, start, end, psr_type=None)
The text was updated successfully, but these errors were encountered: