Predbat going into Freeze-charging rather than using battery

[SwiftRR]

Describe the bug
Many of us are observing the same behaviour, as shown in my plan this evening:

It doesn't seem to be right that the grid is being used rather than the battery, which would be cheaper. I observed the same early this morning when import was 18p and my battery SOC was 100. The status was freeze charge, the grid being used rather than my battery. I have input_number.predbat_metric_battery_cycle set as 0p kWh.

Some are contemplating unenabling the freeze charging switch. I don't want to do this as the freeze charging option can be useful.

The situation seems to arise when

• the battery is full/nearly full and
• the import price is close to the export price.

Expected behavior
Freeze charging when cost effective.

Predbat version
v7.17.6

Environment details

• GE 3.0 AC coupled inverter daily chained to two 8.2 kWh batteries
• Standard HAOS installer (2024.3.3) on Raspberry pi4

Screenshots
See above.

Rob

[mpartington]

Just curious, why do you think using the battery would be cheaper? Personally I think the plan shown is correct.
My assumptions would be that if you discharge the battery now, then you will likely fill it back up on Solar. However, if you were to export this solar directly, then you would earn much closer to 15p, so Predbat is using the grid (with no battery losses) at a rate lower than this.

On top of that, you would also need to consider the cost of round trip battery losses - only the charging losses (and not full round trip) are shown in the plan on import. The export losses are only applicable to forced export from the battery and exporting solar directly is much more efficient than what is shown.

Import at 18p may be a closer call, but depends on the losses you've assumed, or prehaps if Predbat predicted on the best10 model there may be a chance of the battery running out and even higher rates would be required. For example on my AC3, I assume 15% + 0.5p on the metric cycle. So if Predbat is going to use the battery and refill on solar, this costs be 15*1.15 + 0.5 = 17.75. So I'd expect Predbat to use the grid up until this threshold.

The other option is to force the slots to idle if you really do want to use the battery

[SwiftRR]

Interesting and I am more than fine with finding out that my logic is wrong!
I have tried to follow the example in https://springfall2008.github.io/batpred/predbat-plan-card/#debug-mode-for-predbat-plan
My logic was that 15p equates to 13.82p actual export, the bracketed value.
..... and that any import < 13.82p would be cost effective.
For example, at 06:00 am, an import at 14.68 p would give me back 13.82 p on export, a loss.
I have losses set up as 4/4/4 my metric cycle is 0p and best 10 set at 1.15

After I observed this plan, I changed the status of 06:00 am and 06:30 to force idle.
Predbat the changed the plan for 07:00 for Charging.
After these changes, the costs were:
06:00: 0p
06:30: 0p
07:00: 13p
So across all 3 slots, my change plan saves me 1p against Predbat's freeze charge plan, which accrues to 14p across the 3 slots !

Following Trefor's recent upgrades, the PV and Load columns have gained bracketed values but documentation doesn't refer to these. So I am unsure what they mean or whether they also need to be considered*.

Feel free to tell me if, and where, my logic is flawed.

*These marginal differences are always going to be a problem, with plan and PV not matching the plan.
I don't know whether my logic is sound but this is what I have worked to and the reason why I was concerned when values.
Overall, Predbat works very well for me and this is a minor issue, albeit something that predbat is working on all the time.

Rob

[mpartington]

I definitely see where you're coming from. It's hard to explain, but the 15p has been devalued to 13.82 because it has been discharged from the battery, so this has cost you 1.18p vs exporting solar directly (or maybe slightly less if Trefor assumes the 4% inverter loss). You would then need to charge the battery back up, so at 13.67, true cost is 14.83, an extra 1.16. So an additional cost of 2.34p

On the plan where you set the slots to forced idle, what was the battery SoC at the point you compared costs? If could be that the freeze charge plan maintains at 100%, and the other discharges say to 80%. You would then need to consider the extra value held in your battery on the first plan when comparing the two.

With regards to the discharge (I can't recall where, or I'd include a snip), but Trefor has definitely confirmed the export in () is only if you use/force discharge the battery. So rather than getting your 15p export if you directly exported, the conversion losses only mean you get 13.82.

"For example, at 06:00 am, an import at 14.68 p would give me back 13.82 p on export, a loss" - yes, this is why it is inefficient to use the battery, and that 13.82 p is based on your 15p export rate minus losses (15*0.92). Consider using 1kWh, using directly from the grid will cost 14.68 p. However if you charge your battery with that same 1kWh and then use it, it will cost more because you never get as much out as what you put in.

So from your settings, the 1kWh discharge your losses are modelled as 8% (4+4) and to refill it is also 8% (4+4). this gives a round trip loss of 16% - every 1kWh you get out of your battery, you need to put 16% more into it. So in this cost example, to charge the battery at 13.82*1.16 = 16.03p/kWh. So it's cheaper just to use the grid at 13.82/kWh

As you're likely to have excess solar later and you will get 15p export, that's why I based it on 15p above. I think the only time I wouldn't expect a freeze charge is if say there was a very low slot rate later, where it was still cheaper to use the battery and recharge even with the round trip losses. In that case I'd expect Predbat to do a discharge freeze, to export the excess solar

The load and PV brackets are the load10 & PV10 values, so your worst case scenario that (i think) occurs 10% of the time.

Hopefully Trefor will see this (sure he will) and confirm if what i'm saying makes any sense :-D

[SwiftRR]

Thanks for your advice.

I will read through this a few times to get some understanding into my head.
These freeze options are really confusing.

Meanwhile, my conclusion is that I shouldn't worry and I should just let Predbat do its thing! I look forward to Trefor's words of wisdom.

It is far easier to follow when the Agile rates are very different from 15p, as they were in early April.
Currently, with Agile rates close to 15p, except for 4pm-7pm, my battery SOC spends most of its time on 100. But I am still in credit nearly every day courtesy of my solar (and I have a heat pump and no gas). I would never have done as well without Predbat to do all the heavy lifting for me (and of course Trefor to instruct Predbat).

In Predbat's predictions, do you know whether the low and high thresholds are considered (which I really don't fully appreciate)?

Rob

[mpartington]

Someone else may have a better way to explain, but I'm fairly confident in the logic. Unfortunately I don't have a clue on how the thresholds are considered either - that one doesn't make sense to me.

[gcoan]

@mpartington you are correct, the export figures in brackets represent what you would get back if you force discharge and export from the battery - incurring the inverter loss % and the battery discharge loss %. And then as you say, to replenish the battery you again incur the inverter and the charging loss %'s.

Whereas if you don't discharge the battery and instead directly export solar you'll only incur the inverter loss %.

So its not as simple as just comparing import and export figures to work out verify the predbat plan. I can have another look at the documentation to see if I can make this clearer (and I need to add about the bracket PV10% & Load 10% figures).

Have to admit that I too am having trouble with some of the freeze charging behaviour and whether its the optimal plan or not...

Tonight's plan:

The red ringed rates are all Freeze Charging and causing grid import at 16p or greater. To me these seem wrong, its predicted to be very sunny tomorrow so I will easily refill the battery if the battery discharges in these slots rather than grid imports, at the cost of delaying when I will start exporting excess PV at 15p minus 5% inverter losses = 14.25p

Total import for these 4 slots is 1.59kW for 24p.

Replenishing this 1.59kW into the battery will therefore loose out on 1.59*13.68p = 21.7p export income.

So it looks like it would be 2.3p more beneficial to idle these slots rather than freeze charge.

The battery achieves 100% SoC in the 9:00am slot. Note that cost at the end of the 9:30 slot is -£4.95.

If I set these slots to force idle:

The battery reaches 100% SoC now in the 9:30 slot with the cost at the end of that slot being -£4.91 - indicating this plan is 4p MORE expensive rather than LESS expensive 🤷‍♂️

Suggesting Predbat had got it right originally, but this doesn't match my expectations/calculations !

[mpartington]

Have you also considered the charging losses to refill your battery on the average cost of the next charge slots? May make up that difference you're missing.

Ideally Trefor would add a 'round trip' cost colomn (aka cost to use the battery) as well, but i think he said it was complicated to model.

My plan for tonight seems reasonable, highest hold charge is 16.76 p.

My cheapest charge rate is 14.11p X my round trip losses of 15% = 16.22 +0.5 (battery metric) = 16.72. Maybe Predbat averages the chosen charge slots, so that could be a little higher. However it seems to fit with a cost effective plan, based on my settings.

[SwiftRR]

At least it is not just me that is confused, questioning whether predbat has got its plan right. The answer seems to be 'Yes', despite some slots looking to be counterintuitive.

With recent updates to predbat, coinciding with rates close to 15p, the freeze charging status seems to be used much more, with plans in which SOC is mostly 100.
This morning, I thought that I had sorted this out in my head .... but then the logic goes again.

I have just been comparing the import and export bracketed values which originate from the unbracketed values. I have always rejected any import values >15p but is the correct logic to treat 15p as the centre point and to look for 15 ± x (where x is dependent on losses – mine are currently 4/4/4.
Or does Predbat use the movable low threshold value rather than 15p?

I am glad that I flagged this as an issue!
Looking at Geoffrey's analysis, I am leaving decisions up to predbat.

Rob