AC coupled + Separate Solar (AIO type installations) - feature to assess future load requirements and freeze battery charge to allow export direct to the grid instead of charging battery and dumping later.

[arfond]

Some more information in this post - https://www.facebook.com/share/p/hJ3QvPordVScN5Pr/

My install is fairly typical of AIO plus solar. Round trip of solar to AIO battery and then to export is not very efficient: DC > AC (at hybrid string inverter), AC > DC (at AIO to battery), DC > AC (at AIO for export).

More efficient would be to check if battery has enough to see through to the next cheap slot, if it's fine, hold charge and export all solar directly - takes the AIO out of the loop completely.

[springfall2008]

Do you have Hybrid toggle turned off? What is battery_min_rate set to in apps.yaml? Do you have new firmware toggle enabled in GivTCP? What does your plan look like?

[arfond]

Hi. "Inverter Hybrid" is turned off yes.

inverter_battery_rate_min is not set in apps.yaml - should it be?

"new firmware" toggle looks to be not available in GivTCP v3.

Attached some pics of the plan looking ahead - missing the time when battery was charging from solar. You can see where this imported solar is planned to be discharged later.

[ablack89]

I'm in a similar situation - AC coupled with a separate solar inverter. Usually, I don't see any freeze discharge and the battery will charge back up to 100% from solar and dump later. Today is the exception though - it actually is applying a freeze. The only difference I can think of is that solar output is much lower than it has been - is this anything to do with the logic which tries to avoid clipping on hybrid inverters? I have the hybrid switch turned off though, and my inverter_limit is set to 8000 (I have a 3kW AC coupled, and a separate 5kW non-GE solar inverter).

[arfond]

Another example I see now - PredBat thinking it's better to charge the AIO and discharge it later when I'm fairly sure it's more profitable to export it

[mpartington]

It's not necessarily that it will even discharge later. I'm afraid I don't have a clear example, but today my charge finished at 4pm. As you can see it has plenty of charge to get to the next slot at 10pm. However, rather than freeze the discharge (sell solar for 15p and charge on grid later at 10.8p), it keeps filling the battery with solar. (Not much of it around today).

I forced a discharge freeze around 16.10

[bensebborn]

Here ls an example

It charges the battery to 100% early in the day

later in the day you can see 90 mins of export before the next cheap period

would be better to just freeze the battery at say 85% earlier in the day and export from then, reducing the amount being discharged later

[springfall2008]

I put something on 'main' to test with a new (expert mode) switch called 'switch.predbat_calculate_freeze_region' which when enabled might help to obtain more freeze discharges. Can you please test it?

[arfond]

Thank you. Terrible solar day tomorrow but looks to be working. Will report back in a few days.

I put something on 'main' to test with a new (expert mode) switch called 'switch.predbat_calculate_freeze_region' which when enabled might help to obtain more freeze discharges. Can you please test it?

[mpartington]

Seems to be working for me as well. Tomorrow's plan looks much better. Probably needs a few days of good solar to confirm

[gcoan]

@springfall2008 probably a typo on the name of the new switch option, should be 'calculate' rather than 'calculation' to match the other switch names and the entity id:

[arfond]

@springfall2008 - afraid it's not working this morning. New switch is on.

[mpartington]

Seems to be working again for.me. The choice not to charge at 1pm is a little cavalier, however is correct based on the load that is predicted for rest of the day (best10 drops to around 20% soc at the next evening charge). I'll definitely give it a little boost then

[springfall2008]

New version on 'main' for testing

BTW: I removed the switch I added (it's now just on) it was just for testing and I don't want it to actually end up being another option to support

[arfond]

That's made a difference!

[mpartington]

First issue, it seems to be resetting my forced overrides. As my electricity is on a cheap period, I want to use the grid, as I know my load will be much higher than predicted -using tumble dryer (so I Forced freeze charge). Predbat has overridden this with a freeze discharge, which is not cost effective.

log attached, happens at 13:10

predbat.log

[springfall2008]

Update on 'main' again please re-test

[gcoan]

I've got the opposite problem, its been a poor solar day today and not particularly cheap tonight so going to need a small charge overnight to get through the night.

Tomorrow not great solar either and the forecast suggests that I will again run out of battery charge tomorrow evening and thus incur the (relatively) expensive overnight grid import tomorrow night.

Yet predbat has decided it wants to do 3 slots of freeze discharge to export some of the limited solar I will get

In case it was the main() release doing this I reverted to 8.4.8, but much the same, slightly different times but I again run out of solar overnight tomorrow night

[mpartington]

So Predbat is doing exactly what has been requested, but I have a question....

Octopus has messed up switching me back to GO and has put me on a much older fixed version. I'm tempted to remain on it, as I use so little peak, the standing charge and off peak savings easily out way the extra peak cost / loss of an off peak hour.

It currently means there is only a 0.5p difference between charging from solar / the grid. For me this isn't necessarily enough not to always charge from solar.

I've tried adjusting metric_mattery_value_scaling and metric_min_improvement to encourage it to charge the battery using the solar (rather than export), but no success. Below screenshot is today's plan (I have had to factor PV up to get any excess)

Any ideas what to tweak? I guess I could raise soc keep (currently 2kwh) or reduce the export rate to say 7p (They still got me on the 15p at the moment(so using override), but risky to assume that will not retrospectively be corrected).

I think the feature is working perfectly (optimisation logic completely makes sense), but this is just a use choice I can't seem to configure. I'm mainly thinking of those days where you get a higher than predicted load, and would have been grateful to have had more solar charge (and not pay 40p)

[gcoan]

It currently means there is only a 0.5p difference between charging from solar / the grid. For me this isn't necessarily enough not to always charge from solar.

With AC coupled the losses for solar and grid charging will be the same so predbat isn't going to choose solar charging over grid if grid charging is slightly cheaper as its a least-cost optimisation. Only way I think you could get it to favour solar charging is to scale the PV generation up as you have done.

For me today, the plan isn't a good plan again. Another poor solar day and Predbat decides it wants to freeze discharge my solar for ~ 14p export rate and grid charge this afternoon at ~19.8p effective rate, rather than store the solar in the battery to preserve against grid import tonight at ~16p.

And if solar generation is greater than predicted (as it was first thing), all that extra solar will be exported.

Predbat's initial plan, £1.79 cost at midnight tonight

I put a load of force idle's in, giving a lower cost of £1.76 at midnight and the SoC lasting later in the evening

[arfond]

It's not perfect for me either. What I've noticed is that on restart the plan looks good - like below, a long charge freeze. Then after say 15 mins or so it reverts back to charging from solar.

[mpartington]

I think it's reverting because the forward load prediction is higher than the remaining solar for the slot. So it assumes no spare solar to export.

Having played around with settings for a few days, I think this is a great option, but suspect it will be a bit marmite. Everyone has a different opinion of the best plan and Predbat has typically kept soc high on tariffs like agile, so this will be a new way of thinking (and seem wrong). However, I think there needs to be a level of user control on the number of discharge freezes set, ideally through existing options.

In my situation, there is only 0.5p/kWh between charging on solar Vs grid, so I will likely favour the security of a higher soc and less export Vs using peak rates (so fewer discharge freezes). If I was on IOG and 15p export, it would be different and I would want to export more.

What seems to be working well for my situation is increasing the soc keep metric, although that may not be an answer to those on Agile. What hasn't worked is increasing the battery value metric, I assumed adding greater value to stored energy may have prioritised charging over export a bit more.

Increasing the soc keep metric does produce an odd plan though, where it sets a freeze, discharge even when there is no solar.

[arfond]

Yes, agrees @mpartington - I think a level of manual intervention will be needed as it is quite a different approach to agile.