When topping up or holding charge for a saving session, surely there's no point in going beyond what the battery can dump to the grid for the duration of that session. Why does it overcharge the battery to try and run off the battery until 11:30pm. That's going to cost more due to inefficiencies in the charge/discharge of the battery than just running off the grid once the saving session is finished.
WillC I'm sorry but I don't see any issues with that plan.
Predbat is planning your battery so there is enough charge for the saving session, then doing a discharge in the saving session to give you the best earnings, then after that from 18:00 the battery is released and it gets to about 5% SoC by 23:30 when it starts charging on the overnight cheap rate.
You've got 13p of predicted cost before the saving session, and maybe that could have been met from the battery, but you'd have run out of battery before 23:30 then and it'd have incurred the same cost
You've got 13p of predicted cost before the saving session, and maybe that could have been met from the battery, but you'd have run out of battery before 23:30 then and it'd have incurred the same cost
This isn't true as charge/discharge isn't 100% efficient, typically between 80-90%, so it's better to run out of battery early than it is to charge before the event. The reason I was asking the question is because I noticed the battery charged for 30 mins earlier in the day. On top of this, it also increases battery degradation.
I admit we're talking very marginal gains here, but there's no harm in striving for perfection!
WillC In which specific time slot did it charge the battery? I'm not fluent in these charts, since I don't use predbat. It looks lto me like it ran from solar and battery until it hit the reserve of 61% at 15:30. Then paused the battery at 61% and ran from the grid until the saving sesson. Then started discharging the battery again.
you can change the costs of using the battery in predbat if you want to prevent it doing this when the benefit is marginal,
In the predbat docs -
input_number.predbat_metric_battery_cycle ? Higher numbers mean less charging and discharging but higher costs
DD is correct, it used the grid but did not charge based on that chart. The arrow is flat at 61% SOC, this was a freeze charge event not a charge event. Maintained battery at 61% by using grid to power house.
It’s hard to make any judgement without more information as to what predbat did and why. If you can attach the log file from around the time that predbat did the charging to the GitHub ticket, Trefor may be able to see why it decided you needed an extra battery boost.
It looks from the graph that you were on about 50% Soc when it charged you up to about 70%. Then in the saving session it discharged from 60-30%.
So possibly an alternative plan could have been to hold charge at 50% all the way through to the start of the saving session.
What were your best_soc_min and best_soc_keep set to, might have been trying to preserve the Soc above these.
geoffreycoan Thanks. I'll dig through it all tomorrow... I'm very new to all this and drowning in information currently!
