Battery didn't charge properly, probably because of dynamic slots

[brettjenkins]

Describe the bug
The battery last night didn't charge properly, never got to 100% by the end of the night.

I think this is an issue with intelligent octopus and it's dynamic slots. Because generally it's been charging fine when it's a usual night now (23:30-05:30) that I've fixed the charge rate, but last night was different. I had driven the day before and the battery on the car was low. So octopus was giving me additional slots to charge, but these slots I noticed change a lot throughout the night, so I wonder if predbat thought it had more time at a cheap rate but that changed, pulling up the rug of its plan?

I wonder if somehow I have to simplify the logic around these dynamic slots? Treat them as additional slots to recharge the battery but not do any fancy things like export because you can't rely on them?

Expected behaviour
I expected to end the night with 100% battery.

Predbat version

8.31.9

Environment details

Sigenergy 12kw inverter
2x "10kw" batteries
Docker install
Import limit of 18kw

Predbat hasn't been configured to directly know about the car, because the car is wired on the other side of my consumer unit so my battery can't see it's load and so it won't drain the battery (is this correct). I have a direct octopus integration, I'm using the tesla integration with octopus, so octopus should know the SoC of the car.

I don't think the import limit played a part here, because even if we got close to it, the EV charger is the device that ramps down if it needs to, so that should give us more slots if anything as octopus should see that.

I created this as an issue rather than asking on Facebook so I can provide all my logs etc.

Screenshots
History view

There were probably more slots planned, but this is all I can see now at 10:31

For context this is a normal, non charge night, which is what I would expect.

Log file
predbat(1).log

Predbat debug yaml file

predbat_debug2.yaml.txt

[gcoan]

predbat should cope with dynamic changes to the octopus intelligent despatches, replanning the battery activity based upon what Octopus plans

one thing I notice from your debug file is that you have not configured the watch list in apps.yaml

this means that when octopus changes an OIG slot, predbat will not pick that change up until the next scheduled run of predbat. If you configure the watchlist then predbat will be triggered to auto run as soon as the OIG slot sensor changes

[brettjenkins]

predbat should cope with dynamic changes to the octopus intelligent despatches, replanning the battery activity based upon what Octopus plans

one thing I notice from your debug file is that you have not configured the watch list in apps.yaml

this means that when octopus changes an OIG slot, predbat will not pick that change up until the next scheduled run of predbat. If you configure the watchlist then predbat will be triggered to auto run as soon as the OIG slot sensor changes

Hey,
Thanks for the reply. I'll try adding it as a watch list item, but my understanding is it recalculates every 10 minutes anyway, so it shouldn't have been that far behind? It looks like predbat thought it had more time to charge than it ended up having, so couldn't get to 100%

[gcoan]

you are correct predbat does recalculate every 10 minutes so the impact of not adding the watchlist just means predbat is 'behind' OIG, and adding the watchlist resolves this

potentially an issue with predbat not updating correctly for OIG still

[brettjenkins]

How often does the octopus direct integration update? Presumably it caches data for some time? For example I just plugged in, and octopus gave me a charge slot NOW. Predbat didn't pick it up, I tried restarting the octopus component, nothing, had to restart predbat for it to see it and start charging. I wonder if this is part of the problem?

[gcoan]

good suggestion and spot of a potential fix. There is definitely caching in place to avoid overloading the Octopus servers, but shouldn't be caching for fast moving entities like the OIG slots.

@springfall2008

[bsharlotte]

Hi Brett,

I'm on a big learning curve here but experiencing a similar problem to you. If I unplug my car midway through a cheap slot, I can find my home battery (Givenergy in my case) is not charged, predbat had planned to charge it later because it assumed the car was going to stay plugged in and didn't expect the cheap slots to be removed. Ideally, if I plug my car in and get a cheap slot, I'd like predbat to start the battery charge straight away so if I do unplug the car, my house can run off whatever charge I put into the home battery.

Best I can understand is that Predbat is playing safe and trying to protect overload of my grid connection. If it can avoid charging the battery when the car is charging it will and this means it defers battery charging because the car is charging. I read predbat monitors car charging (via ohme in my case), house consumption, and battery charging, but it can only control the battery charging and it won't rely on the charger ramping down (because it can't predict this either). Providing this total is not going to trip my main house fuse, I'd like predbat to charge the battery straight away and not wait till later when the cheap slot may unexpectedly disappear.

Does that sound like the same situation and use case as you have? If so, I think its not so much a bug and more a design feature of Predbat to be conservative. Perhaps there is a way we can tune this?

BenS

[gcoan]

Hi Ben

Your analysis is well thought through, but wrong.

Predbat does not "play conservatively and defer charging" nor does it "try to protect overload of the grid connection" because IOG slots can and do change rapidly, several times a night. Each time the IOG slots change predbat will replan its activity based upon the revised slots and (if its financially beneficial, which it usually is), will start charging in any cheap slot.

What appears to be the case is that with Predbat Octopus direct (whereby predbat talks direct to the Octopus API) rather than using the BottlecapDave Octopus integration, there is some caching going on so Predbat does not identify the slot changes,
You haven't said whether you are using Predbat Octopus Direct or the Octopus integration but I suggest if the former then if you change to Octopus integration then you will get different behaviour.

That's why I have marked this as a bug