-
-
Notifications
You must be signed in to change notification settings - Fork 44
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
Strange charging prediction AC3 #1630
Comments
Additional info after doing some changes to apps.yaml Even if I simplify the rates section by
I still get some really weird predictions between 13:00 and 14:00
|
Why do you think its predicting to take nothing from the grid Lee? Your predicted load is greater than your PV prediction for those slots so your battery will discharge to meet that load. Those two slots look OK to me. BTW I think you may have a problem with your rates_import setup, the start and end times should be aligned to 30 minute slots https://springfall2008.github.io/batpred/energy-rates/#rate-bands-to-manually-configure-energy-rates Your end times are XX:59:59 which Predbat probably doesn't understand as it does everything in 30 minute time periods. They should be XX:00:00 - i.e. the time that the next slot starts. |
OK, bad wording I used. The original issue, first post, is that predbat is aiming to use expensive grid power when there is no need. It could wait for an hour by using battery before charging from cheap rate. My second post was suggesting that the prediction was wrong, but you are suggesting that the prediction is correct, and therefore supporting that one way or another it will take expensive energy from the grid during the expensive time when there is no need. I have now changed the times so they are all XX:00:00, and the result is the same. How do you interpret what is happening between 13:00 and 13:30? Why does predbat predict to take expensive energy (18p, nearly 1kWh) from the grid when there is no need. In fact it is even predicting the SOC to go up from 91 to 92. Inverter is 11kW, battery is DC coupled. So load greater than 11kW will have to come from the grid, but between 13:00 and 13:30 the load prediction is nicely below that threshold. Today being sunny is not a great time to retest the issue relating to the original post. Maybe the XX:00:00 will have an impact but cannot test for now. For that I will try again on a cloudier day.
|
You're correct, on the face of it, load over the 30 minute slot is 3.84kWh, PV is 3.29kWh, SoC is rising by 1%, so why the small amount of grid import? I can only assume it either due to some of the underlying 5-minute predictions going over the inverter limit, or a bug as you have suggested. What we are seeing on the predbat plan is the 30 minute aggregate figure, but as I said before there is an underlying 5-minute prediction model. It might be useful to look at the history of the load sensor for that time period and see how much it spikes? Your cumulative load for the 13:00, 13:30 and 14:00 slots is quite high so it's possible that there are peaks within that that are predicted to cause grid import. Might also be worth looking at the history of the battery activity/grid import for that time period yesterday to see whether it did import or not. Probably worth attaching the predbat logfile so Trefor can see if the logfile indicates anything else as to why there is grid import 👍 for changing rates_import, it probably wasn't linked to the plan things but it can only help getting it configured correctly |
Describe the bug
Charging in an expensive time instead of waiting until the next hour which is cheap.
Expected behaviour
Based on the prediction, I would expect to satisfy load from battery until 14:00 and then charge the Battery from the grid.
In the end I left predbat on Read-Only and I controlled Inverter manually to start charge from 14:00 without issue.
Predbat version
1.2.1
Environment details
Inverter - GIV-3HY-11. 3 phase
Batteries - 19.94kWh
Stanadard HAOS in VMWare
Screenshots
Log file
Apps.yaml -
apps(2).yaml.txt
Log File -
predbat(9).log
The text was updated successfully, but these errors were encountered: