Export Slots On Octopus Go

[nbullus]

Describe the bug
Octopus Go has a simple Peak and Off-Peak period. There is no financial or user benefit of exporting any battery until the end of the peak period prior to a recharge. Sometimes the plan creates 2 issues:

1. Export slots appear randomly in the middle of the peak period.
2. The last end of day export is not pushed out to the 00:00-00:30 slot but remains in the 23:30-00:00 slot.

Expected behaviour
Export slots (if any) should all be at the end of the peak period to avoid running out of battery before the battery recharges in the off-peak period.

Predbat version

Main - 8.8.3(?)

Environment details

• GE AIO
• Standard HAOS installer

Screenshots

End of day export finishing early:

Random export slots in the day:

Log file
Can you capture a log file from the time of the issue, debug mode is not normally required.
If you are not keeping the full logs then please enable this in appdaemon.yaml (see the installation instruction in the Predbat docs area for details on how to do this)

Debug Log File from 10:00 this morning - rname .txt back to .yaml

predbat_debug_10_00_00.txt

[springfall2008]

Great, the new debug method worked and I was able to reproduce your plan:

[springfall2008]

So I think the behaviour is due to 'combine_export_slots' being True and thus the slots being too big

[springfall2008]

That doesn't fully fix it however, debugging

[springfall2008]

Fix released as v8.8.3

[nbullus]

Ok. Without it on the export at end of day is split and intermixes, I.e, charge, export, charge, export, charge , export, charge and so on. Better to do what it shows , ie charge, export, charge.Sent from my iPhoneOn 8 Dec 2024, at 15:27, Trefor Southwell ***@***.***> wrote: So I think the behaviour is due to 'combine_export_slots' being True and thus the slots being too big —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[nbullus]

I've turned off 'Combine Charge Slots' and installed latest release, but my plan looks the same. I still have rogue exports appearing in the day and the last export of the day is still finishing 30 mins early.

[nbullus]

Got Export at 22:30 which shouldn't be present. End of day looks OK apart from the fact it's still not planning on charging battery to 100% SOC but rather 86% which is not enough for me. I can increase load scaling which may help push it up but wanted to leave it the standard values until you have had chance to take a look at it. New debug file uploaded.

[nbullus]

predbat_debug_14_00_00.txt

[mpartington]

Here's one from me. Discharge on charge slots is switched off, so shouldn't be doing this. I'd expect it to discharge without the charge cycles in-between with this set. Log to follow

[mpartington]

predbat_debug_16_35_00.txt

Btw. These save as .yaml files, which cannot be uploaded to GitHub. I've changed extension to .txt

[mpartington]

I'm afraid I don't have the debug logs, but you can see how many random very short extort periods have been set today.

predbat.log

predbat (2).log

I might have caught the last one..

predbat_debug_21_30_00.txt
predbat_debug_21_35_00.txt

[mpartington]

Another 2 min discharge (5 mins after I turned debug off). Now its planning split slots, rather than combine.

predbat_debug_22_10_00.txt

[springfall2008]

Fix on 'main' for testing which appears to resolve Nigel's issue. Will re-test Matt's one now

[springfall2008]

Appears to fix Matt's case too

[mpartington]

Here are the files for the discharge in the charge slots (with setting off)

predbat_debug_20_35_00.txt

predbat_debug_20_40_00.txt

[mpartington]

More random and very short export slots, annoying and burning unnecessary writes. @springfall2008 , this is latest version on main, so unfortunately no fix :(

Relevant Debug
predbat_debug_16_30_00.txt
predbat_debug_16_25_00.txt
predbat_debug_17_00_00.txt
predbat_debug_16_55_00.txt

predbat1.log
predbat.log

[springfall2008]

Another version on 'main' for testing which may help

[mpartington]

Another version on 'main' for testing which may help

Thank you, not much left to export tonight, will be running on fumes, but will leave debug on and feedback tomorrow

[mpartington]

Actually, might have one already. Seems to have stopped combining charge slots as well. Edit..Strangely turning off 'combine charge slots' seems to result in them combining

few examples of the export slot setting too early
predbat_debug_20_20_00.txt
predbat_debug_21_05_00.txt
predbat_debug_21_55_00.txt

And next calculation it's moved to where it should be?! Very random - edit, seems to keep flipping

[springfall2008]

So I understand why now.

The optimal export amount is less than 10 minutes worth which is the minimum export slot size, however if you do it at a time with higher predicted load then you end up exporting slightly less which then prevents you running out of battery. The slot moves around depending on the exact load prediction and what battery you might have left (which changes as you use it).

Not sure on the right solution, I could make the minimum export slot bigger e.g. 15 minutes or we could try a bigger metric_min_improvement_export but that is scaled with slot size also

[mpartington]

Just checking is this in relation to the numerous 2-3min exports I'm seeing, or the example above (or maybe it's the same issue 🙂)

I'll try changing the discharge metric to 5 as a first step.
Wouldn't changing the min export slot just push the problem to a different pinch point? I guess I don't really understand why it can't just be ordered in time, so if it wants to discharge for 10 mins at 23.20 and it only lasts 5 mins, not the end of the world. What is frustrating is these 5 mins bursts happening earlier and more than once

Thanks for looking into it, happy to test any fixes you think may help

[springfall2008]

The earlier slots are because those have higher load predictions meaning the really export less.

I could make the minimum slot size 5 minutes also, but its more register writes....

[springfall2008]

New release for testing:

https://github.com/springfall2008/batpred/releases/tag/v8.8.5

Lets hope its not broken stuff.

[mpartington]

No, definitely not suggesting going down to 5 mins slots. I'm on 1 write today so far and want to keep that streak 😉.

Absolutely no excess today, but fortunately it hasn't tried to random discharge either (export metric at 5o). A larger export slot may make sense, but is there anything stopping combining a smaller and larger e.g. a 30min.+ 5min =35.

I don't see too much issue with any size slot, but ideally if it could be scheduled to end at the transition to cheap rate and work backwards from there for the start time, when all import & export slots are the same.

Hopefully the export metric will have a similar influence.

[nbullus]

v8.8.5 still doing random exports for me. Turned my automation back on to stop exports in daytime.

[mpartington]

v8.8.5 still doing random exports for me. Turned my automation back on to stop exports in daytime.

Have you changed input_number.predbat_metric_min_improvement_export to 5?

Upload a debug file id you catch it, or leave debug turned on for a while. Just need to make sure you regularly clean it out, as it adds up quickly in terms of file size

[nbullus]

v8.8.5 still doing random exports for me. Turned my automation back on to stop exports in daytime.

No. Just spotted v8.8.6 was released so will see how this version behaves as the min improvement export is now 5p by default

[mpartington]

You still need to manually change it, if you are using expert mode and we're using something different

…

On Fri, 13 Dec 2024, 15:37 nbullus, ***@***.***> wrote: v8.8.5 still doing random exports for me. Turned my automation back on to stop exports in daytime. No. Just spotted v8.8.6 was released so will see how this version behaves as the min improvement export is now 5p by default — Reply to this email directly, view it on GitHub <#1704 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZQHXHP42AY7D6U7MCB4TND2FL5KZAVCNFSM6AAAAABTHCZJT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNBRG4YTQNJYGA> . You are receiving this because you commented.Message ID: ***@***.***>

[mpartington]

Latest version and recommended settings

predbat_debug_12_30_00.txt

It went next update of the plan, but unsure how long it was planned for prior

[PianSom]

Still having random import and export slots here on 8.8.9 - see pattern in blue ovals below.

Also, green ovals show early export leaving a shortfall later in the evening. (I was away last night, so load would have been lower than forecast - so not that.)

Happy to supply debug file if helpful.

[mpartington]

Are you using expert mode, if so have you set Metric Min Improvement Export to 5 as well?

[PianSom]

Are you using expert mode, if so have you set Metric Min Improvement Export to 5 as well?

Yes, and yes

[PianSom]

I am on IOG (so cheap 11.30-5.30). At this time of year my battery is usually empty by the end of the evening. One very odd thing is that I can almost guarantee that every night I will have a short charge-then-discharge cycle in the period 11.30-midnight - for reasons which completely escape me.

[mpartington]

I'm afraid the return of the split discharge.
Unfortunately no debug yaml, but have attached normal logs

predbat1.log

[mpartington]

Another poor plan, unfortunately lots of stop start already. I don't know why load is zero, but that should cause more export.

Before and now plans

predbat_debug.yaml.txt

[mpartington]

And another itteration

predbat_debug.yaml.txt

predbat0.log
predbat1.log

[springfall2008]

I think its fixed on latest

But you should probably set: metric_min_improvement_export to 5

[gcoan]

I think its fixed on latest

Christmas Day 🎄🎅, don't you get time off Trefor ?

Happy Christmas

[mpartington]

Thanks Trefor, hope you had a great day yesterday (hopefully away from too much Predbat debugging)

The new version does seem better, only 1 break in discharge. I already have set metric_min_improvement_export to 5, but will increase the Battery rate max scaling discharge a bit more.

Just when you have time, do you know why Predbat goes into hold exporting at a SOC of 6%? This is repeatable and probably a good idea if Predbat is managing discharge, as prevents using the peak if it finishes a few minutes early.

However I sometimes want to force discharge until it stops discharging to allow the battery to settle and perform its OCV checks in an idle state. I've noticed it still stops at 6% even using the manual overrides. It'snot empty as it continues to supply the house for another hour (below screenshot). I guess it could be the BMS, but I probably need to Pause Predbat and just use GivTCP to set the discharge to check that

The screenshot below is last night, with no overrides set, to show the behaviour

predbat_debug_23_25_00.yaml.txt

predbat_debug_23_30_00.yaml.txt

[springfall2008]

I'd guess its because you have best_soc_keep as 0.5 and hence going any lower would violate that? Maybe turn that to 0 to disable keep?

[mpartington]

I did try that on the first chart above (where I did manual export slots). It unfortunately didn't make any difference

[springfall2008]

I've made a new release with some tweaks that after reducing soc_keep to 0.4 gets me to this based on your YAML:

[mpartington]

Seems to have fixed my export to empty, in fact I ran out with 1 min to go. I guess just need feedback that it does still respect a higher soc keep. Additionally the discharge was in a single slot, which minimises register writes and late as possible 👍 (although I see some beta firmware has already been released for AIO, and gen 2 & 3 to address this. Just waiting on gen 1)

Interesting how my 2x5.2s reduce discharge rate for the last 15mins. Shows how difficult it is for Predbat to model all these different systems as a one size fits all set of config

[springfall2008]

You can model the discharge rate using the discharge curve?