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
Error passing forecast data #4
Comments
Hi, this is more of a problem from the emhass add-on and not this emhass core module. |
Is that 1 day length meaning 48 entries for each half hour block?
Also is the forecast list meant to be the next forty eight 30 minute
blocks, or the forty eight 30 minute blocks starting from midnight. I would
assume the latter, which is how my buy/ sell prices are available. However
my PV forecast has today's forecast (from midnight) and tomorrow's forecast
(from midnight) as attributes, so I may need to do some sorting there.
…On Mon, 25 Apr 2022 at 17:19, David ***@***.***> wrote:
Hi, this is more of a problem from the emhass add-on and not this emhass
core module.
The logs in the add-on were wrong. I've just fixed that. There is a
mismatch between the passed length of the list and your
optimization_time_step and the default forecast length which is 1 day.
In other words, the passed list needs to have a 1 day length.
—
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AS4B3XWXF6BPAGJLVSLDKNTVGZBRHANCNFSM5UHOOBPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
If your |
In the case of the |
I am passing 48 items, but it still reports an error:
From the logs:
|
You need to update to >> v0.1.32 |
Still fails to load forecast with 0.1.32 :-(
|
Again a very silly error! Fixed >> v0.1.33 |
OK, we have passed the initial check, but get a ValueError Shape of passed values...
When POST this data set:
|
What are your configuration params? From the configuration pane?
|
Not much changed from the defaults. One load, which is my heatpump 5000W.
|
Ok, I just modified my previous comment. Try the |
Unsuccessful unfortunately.
|
Ok, looking for where the problem is. I'm able to reproduce the error. |
Ok found the error and fixed. The error was right in this emhass core module. Wrong handling of the list of values indexes. |
Thanks, looks like upgrading to 0.1.36 needs to install module 'six'
|
Very strange, I'll look whats going on but I don't completely control the building process as I'm using the official hass builder. |
Ok, just added the new missing module in a new update. I did not understood how could that be missing as there was no problem with pandas in previous versions. Anyway, adding that missing module solved the issue on my dev-env. |
Thanks, I can now load the pricing into the add-on, but the timings are a little off. If you have a look at the input I have a major price spike in one hour at 1730 in the second window: prod price $13.88 & load cost $15.36 / kWh (yes they are not typo's), but in the web UI they are scheduled to occur after midnight (00:30)
|
Hi, so the timings are off exactly by how much? |
Looks like it has shifted the data by 7 hrs and wrapped the later data
points into the earlier time slots.
I will adjust my scripts to inject at the same time.
…On Wed, 27 Apr 2022 at 17:13, David ***@***.***> wrote:
Hi, so the timings are off by how much?
Remember to send all the curl data at once
—
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AS4B3XS4ZFQB44YEA3RFKGDVHDSJDANCNFSM5UHOOBPQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Ok, and the first data point in the list that you send correspond to the data slot for the time when you are sending the optimization curl command? |
Looks like it is just loading the list in from midnight, it loads the first list item into 00:00 the second item into 00:30, ... and the fourty eighth item into 23:30.
Have a look at the unit_load_cost column: |
The data points I am sending are all forecasts for the next twenty four hours, so the first element is the forecast for the next 30 minute block. e.g. time now is 20:22, the forecast of $0.40 is for the next time period which starts at 20:30 {{(state_attr('sensor.amber_general_forecast', 'forecasts') |map(attribute='per_kwh')|list)}}
|
Ok thank you, I will take a look and fix this. |
I feel like we are getting close, I can now see my injected variable buy/ sell costs and well as PV forecasts into the system, albeit offset to midnight. I guess if I run injection once a day at 23:35 it will be correct, but of course the forecasts are changing every thirty minutes, so it will get stale. |
Hi, yes we're getting close! |
Success with 0.1.38. maybe a 30 minute offset to what I was expecting. Thanks for getting us to this point! I have now got relevant forecasts into the system and it is coming up with an optional solution, I'm currently running optimised for profit. I just need to work though the results to work out why it isn't scheduling my deferable loads during my solar production as I have excess solar and my sell price for excess solar is less than the buy price from the grid during the windows the deferable loads have been scheduled. |
Again thank you too for testing. |
When trying to pass forecast data all looks good from the command line:
However it doesn't get updated in the model and the logs complain about length needing to be 48, but then confirming length is 48.
The text was updated successfully, but these errors were encountered: