PredBat currently assumes that battery charge/discharge is 100% efficient

[WillCalderwood]

Is your feature request related to a problem? Please describe.
As above, I believe that PredBat assumes that battery discharge is 100% efficient, so, if for example your rate is 10p kWh, running from the grid will cost you that, but to charge 1kWh and discharge it again will have inefficiencies, usually around 15%, so to get 1kWh out the battery will cost you 11.5p,

Describe the solution you'd like
Alter the calculations, so charging the battery costs 15% more than running off the grid.

Additional context
I noticed this when PredBat overcharged before an Octopus Saving Session aiming to run out of battery at 23:30, when holding the charge at a level where it could dump to the grid for one hour and then run off the grid later in the day would have been more efficient.

[RobinCu]

Hi Will,

Predbat calculates battery charge/discharge losses and inverter losses and incorporates them into its planning. The entities are configurable on the dashboard. More info: https://springfall2008.github.io/batpred/customisation/#battery-loss-options

You can also see the assumed cost of import/export on the Predbat Plan card by switching on switch.predbat_plan_debug (more info here: https://springfall2008.github.io/batpred/predbat-plan-card/#debug-mode-for-predbat-plan

If it still doesn't look correct, you can post a 10-minute cycle of logs or just screenshots of your settings, we can confirm if it looks OK.

There's a lot of info to absorb in one sitting in the documentation due to the high configurability of Predbat, but I'd recommend another read-through after a few days of set-up, as things start to click once you see it up and running and again after a couple of weeks.

Re: your additional context, this could be for a few reasons, you may need to adjust input_number.predbat_metric_battery_cycle (expert mode) or the losses. Again, a log showing your current settings would help troubleshoot that.

[WillCalderwood]

Thanks for the great feedback. I'll look into what's going on more deeply and take a copy of the settings next time it looks like it's scheduling a charge when I don't believe there's any benefit.

[WillCalderwood]

It has decided to charge the battery again today, when pausing discharge would most probably have been more effective. Screenshot of plan and the log file attached, if anyone can tell me what's going on?

predbat-log.txt

[gcoan]

For most of the plan Predbat is holding the charge at 53%.

Although it says Charging, the target SoC is 53% and the SoC is remaining constant through to the start of the saving session.

Thereafter the Soc is released to support house load and it looks like it runs out at the start of the overnight cheap period.

Which leaves the small bit of charging from 49% to 53% at the start of this plan. Which could have been avoided, holding the battery at 49% through to the saving session and then releasing it thereafter, in which case it would probably have run out before the cheap period and you'd have had a to grid import then - but without the cost of the charging loss that occurs in the predbat plan.

Losses would probably be about 1p of the 17p import cost.

So not as perfect a plan as it could be

[springfall2008]

One thing to add to this discussion is I would inclined to turn off 'combine_charge' if you want to do any day time charging otherwise the slots will be rather large in your tariff.

[WillCalderwood]

Thanks for the tip. I'll take a look.

Another dubious decision, I guess because PredBat assumes it's forecasts are accurate. Discharging at 9pm is risky due to uncertainty in the forecast. As long as there isn't more in the battery than can be dumped in the last 30 minutes, then it should be held until then. I don't know if the forecasts take a degree of risk into account, but when running out of battery costs 2x the export value, then ideally that needs to be factored in.

[WillCalderwood]

One thing to add to this discussion is I would inclined to turn off 'combine_charge' if you want to do any day time charging otherwise the slots will be rather large in your tariff.

I'm trying to work out what combine_charge is? I'm guessing you mean 'combine_charge_slots'? I can't find any documentation and I'm struggling to work it out from the code.

[springfall2008]

Yes sorry combine charge slots, when off slots are all 30 minutes but when enabled they get joined together if they are the same rate

[springfall2008]

https://springfall2008.github.io/batpred/customisation/#battery-margins-and-metrics-options

switch.predbat_combine_charge_slots Controls if charge slots of > 30 minutes can be combined. When disabled they will be split up, increasing run times but potentially more accurate for planning. Turn this off if you want to enable ad-hoc import during long periods of higher rates but you wouldn't charge normally in that period (e.g. pre-charge at day rate before a saving session). The default is enable (True)

[RobinCu]

Another dubious decision, I guess because PredBat assumes it's forecasts are accurate. Discharging at 9pm is risky due to uncertainty in the forecast. As long as there isn't more in the battery than can be dumped in the last 30 minutes, then it should be held until then. I don't know if the forecasts take a degree of risk into account, but when running out of battery costs 2x the export value, then ideally that needs to be factored in.

The default plan assumes that the average load / PV forecasts are accurate and that aims to give the maximum return. However, there are several ways that you can de-risk the plan:

1. You can increase best_soc_keep, which is a soft target. https://springfall2008.github.io/batpred/customisation/#battery-margins-and-metrics-options. Add a best soc keep of 1kWh and it will aim to keep 1kWh available for unexpected load.

2. You can also adjust input_number.predbat_load_scaling to 1.2 so the plan will incorporate 20% more expected load. https://springfall2008.github.io/batpred/customisation/#scaling-and-weight-options

3. Similarly, you can scale PV forecasts with input_number.predbat_pv_scaling.

All the above will "play it safe", but you'll notice the predbat.best_metric (cost) will increase (risk versus reward).

Finally, if you want to avoid discharge too early, you can add a rate export override to apps.yaml:
e.g.
rates_export_override:

• start: '21:00:00'
  end: '23:00:00'
  rate_increment: -10

[WillCalderwood]

Perfect. Thanks for the tips. I'll have a play.

[gcoan]

Finally, if you want to avoid discharge too early, you can add a rate export override to apps.yaml: e.g. rates_export_override:

• start: '21:00:00'
  end: '23:00:00'
  rate_increment: -10

Hi @RobinCu I've been updating the predbat documentation, and added your tips to the FAQ's, but just thinking about it again, the rates_export_override as you have it could potentially give the wrong results.

The negative rate increment dissuades Predbat from discharging in the 9-11pm slots which are the end of the 30p rate. Predbat could well just discharge the battery at 8-9pm now, and then if house load is higher than predicted, it'll be a worse situation and importing again, but earlier.

I think a better config would be:

rates_export_override:
  - start: '22:30:00'
    end: '23:30:00'
    rate_increment: 10

so to encourage holding the charge as long as possible and discharging (at the pretend more favourable export rate) from 10:30-11:30pm.

Obviously can adjust start/end times to suit.