Charging before cheap rate for no reason

[WillCalderwood]

Describe the bug There's a saving session today, and PredBat is holding charge for that, but it's then charging after the saving session, for which I can see no reason.

Expected behaviour Don't charge at 4x the price when there's no benefit.

Predbat version 7.16.2

Environment details

• Inverter and battery setup GivEnergy inverter and battery

• Standard HAOS installer or Docker VirtualBox install

predbat-log (2).txt

[gcoan]

Agreed, it's charging enough after the saving session to ensure your battery doesn't run out until after the start of the overnight cheap period, but after losses are included, this isn't optimal.

What are your loss percentages set to and input_number.predbat_best_soc_min and predbat_best_soc_keep?

This isn't happening on my predbat, it just lets the battery discharge after the saving session, so suggests its something in your config that's causing it to think its worthwhile to charge

[WillCalderwood]

My settings are mostly defaults. Charge Loss 3% Discharge Loss 3% Inverter Loss 4%

I'm not sure where to find predbat_best_soc_min and predbat_best_soc_keep.

[gcoan]

If you look in settings / integrations / entities you can search for these two.

They are prefixed inputnumber.predbat... On 29 Feb 2024 at 16:32 +0000, Will Calderwood @.***>, wrote:

My settings are mostly defaults. Charge Loss 3% Discharge Loss 3% Inverter Loss 4% I'm not sure where to find predbat_best_soc_min and predbat_best_soc_keep. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>

[WillCalderwood]

predbat_best_soc_min = 0 predbat_best_soc_keep = 0.5

[gcoan]

Thanks Will,  your losses are a bit on the low side,  but even so, Predbat still should have thought it wasn’t profitable to charge when it did.Your best Soc values are not what’s causing the planned charging so sorry I can’t see anything obviously wrong.Can you attach the logfile that covers the period when the plan was created, or even anything up to before it started the charging after the saving session.  Trefor might be able to see what caused itOn 29 Feb 2024, at 16:52, Will Calderwood @.***> wrote: predbat_best_soc_min = 0 predbat_best_soc_keep = 0.5

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[WillCalderwood]

I included the log file in the first post. Thanks.

[springfall2008]

The reason for this charge is an artifact of the change I made to the way soc keep works, now if you have a discharge then it must obey the keep value, but this means the algorithm has planned a charge to follow the rules. What you will find is the charge will never happen as once the discharge completes the keep won't need to be followed for the next 4 hours and as that time never comes it wont even happen (until cheap rate kicks in)