-
Notifications
You must be signed in to change notification settings - Fork 69
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 - Forecast Horizon - extend beyond 48 values #240
Comments
Yes this is a hard coded parameter for performance concerns. If extended we could quickly fall into memory issues and that will be bad for your HA instance. However we could be flexible and add an additional optional parameter to extend this limitation if needed by the user. Why is your goal for extending this limitation and optimizing over 24 h span? |
I am trying to allow longer range forecasting to allow better charge/discharge of battery. Example deeper discharge if it can see a good solar day in 2 days, or higher state of charge if solar forecast is low. I think 2-3 days would allow battery cycling to be more accurate instead of chasing end charge state 24 hours away, if it was 3 days away the end state influence would be diluted. Agree it could be a variable to manage resource issues. |
+1 on this. The battery forecasting would be better. I live in Sweden with nordpool, so when we get the prices for the upcoming day there is very much use to go beyond 48 values. For my part an optional parameter would be great. The performance shouldn't be a problem here, my server needs something to do :) |
Just on performance, I am running it in a VM, so I can just allocate more resources - if needed. I appreciate those running on devices with restricted resources will need a way of limiting the forecast either by days or intervals. |
When these problems fall into the curse of dimensionality, the memory need grows extremely fast exponentially. Even in a machine over teraflops you are done |
But still this feature will be added, just be warned |
This is already a possibility. Just set |
So, let me start with david, you amazing, and thank you for pointing out the delta_forecast value. Cant believe I didnt see it. ive extended that to 7. Im loading in 96 values, and my optimisation step is 30. Im getting shape errors below. Cant understand why its referencing 44 or 22. When I run 48 values in, it runs with no issue. Trying to work out what I am doing wrong. Any ideas on starting points would be great. CURL Source: 48 Hour: Curl Translated Output: 48hour: EMHASS LOG: Update: |
@kcoffau let us know if you figure it out. I have similar issue when trying 26h forecast with delta_forecast 2. |
Ok so I went down to this and this is actually a bug! |
Done! |
My 34h forecast now works. Thanks. |
After 12.30pm each day our energy market operator (AEMO) publishes 30 minute forecasts until 3.30am the day after the following day (ie for the next 39 hours), they then update this set of forecasts every 5 minutes, always finishing at 3.30am. EMHASS can now consume the full 39 hours and with MPC can update it's optimisation every time the pricing changes. Thanks @davidusb-geek . |
Describe the improvement
I have been happily using 48 forecast values in 30 min blocks for a long time now. I am now able to forecast 6 days in 30 min increments, 180 variables.
I updated my curl to push 96 values (as a starting point) and get error:
"IndexError: index 95 is out of bounds for axis 0 with size 48"
So....
I dont have time this week, but I was going to have a look next week and see what I can do, but before I do, I want to check, is my understanding of 48 values in the forecast the current limitation? Is that for performance or other?
Cheers,
Kel.
The text was updated successfully, but these errors were encountered: