‘Sawtooth’ changes to inverter charge rate with low power mode and temperature charge curve

[gcoan]

Describe the bug
First night running 8.11.0, temperature curve defined in apps.yaml

Observed from the sensor history that there are 3 periods, each 10 minutes long when the inverter charge rate drops from being a max rate charge to a lower rate, and then jumps back up again. 3:40-3:50, 4:30-4:40 and 4:50-5:00

May be the same behaviour as commented by @johnwb87 #1844 (comment)

Expected behaviour
Single consistent charge rate overnight with low power mode, achieving batteries at target soc by the end of the charge period.

Predbat version
8.11.0

Environment details
HAOS 2025.1.3
2x Gen 1 hybrid inverts, one with a 9.5 (G) and the other a 5.2 (H)

Screenshots
Its not temperature related as the battery temperature was at 18-20 throughout

Log file
predbat.1.log

Predbat debug yaml file
1110.txt

[gcoan]

Needless to say this behaviour is also putting the number of inverter writes up quite a bit.

Predbat status was Charging from 01:30 to 05:30

At 01:30 the inverter writes count increased from 3264 to 3274 at the start of charging, 5 writes per inverter, which seems reasonable.

But then between 01:30 to the end of the charging period at 05:30 the inverter writes had increased to 3325, so a further 25 writes per inverter.
Appreciate that low power charge mode can increase the number of inverter writes as the rate can be stepped through the charge period, but this seems excessive

[johnwb87]

Yes seeing this also. I had low power mode and a temperature charge curve set last night. This is different to the knee I’m seeing in the prediction and the battery prediction card.

I am on IOG and had the car plugged in last night. That does tend to confuse predbat quite often with it not just ploughing on as far as battery charging. As can be seen by the three zero Grid to battery periods. I had one each of an Export, Hold for Car and Demand during the low rate period. I can see that the slots moved around a bit heading into the first one. The demand period is particularly confusing as I'm discharging from the battery during a low rate.

Log attached which finishes during the 3 o'clock hour, but the bulk occured before that. Remind me do I need debug on to be able to grab that file as well.

predbat.1.log

[gcoan]

Similar pattern today of 10-minute changes of charge rate in otherwise solid charging blocks

predbat.2.log
predbat.1.log

[springfall2008]

Looking at my system I see two things going on here, the first is GivTCP seems to glitching reading max power charge rate when its not set that way.

If I ignore that I see when the charge gets closer to the target the rate sometimes goes up to max and then back down again. I'm looking at a fix to keep the current rate if it doesn't actually matter. Will test it myself tonight.

[springfall2008]

Please re-test with this new release that seems to help, but isn't perfect: https://github.com/springfall2008/batpred/releases/tag/v8.11.2

[johnwb87]

Thanks Trefor. Auto-update on here, so already installed and will report back tomorrow.

[gcoan]

Thanks Trefor, I have installed 8.11.2 and will see how it does

[gcoan]

8.11.2 much better on the first inverter, the charge rate remained constant overnight. Just two bits of weirdness on the second inverter at 3:30 and 4:05ish. Suspect this in part caused by the second inverter battery being almost full, but nevertheless there was no need to change the charge rate on inverter 2.

Normal behaviour seen on both batteries doing the stepped charge as approaching 100% SoC

predbat.1.log

[johnwb87]

Not much improvement for me. But I did have the car plugged in on IOG. Haven’t looked to see if the slots were moving around. But I still find it strange that IOG does throw out the battery charging within the core hours that don’t change.

I also appreciate that predbat tries to do some overnight export because of the 7p import and 15p export. Maybe I should just turn combine charge slots on.

[gcoan]

8.11.3 similar pattern as the night before, a pretty good job at keeping a solid charge going with a couple of charge rate changes on H and one on G

It does look as if H could have been set to a lower charge rate than it was as it finished overnight charging to 100% two hours earlier than G

predbat.log

[gcoan]

There is definitely something weird going on with the charge rate being stepped down unnecessarily when the battery nears to 100% SoC.

Today both batteries started charging from 12:30, H was almost full (so filled quite quickly) but over the last 90 minutes there have been 6 changes made to the battery charge rate

predbat.log

[johnwb87]

I find quite often that the charge rate is stepped down as if responding to the fact that the planning has allowed for the charge curve.

Always seemed a bit unnecessary but I imagine it is because the low power charge calculation then realises it can go to that lower rate not being aware it’s been planned for and it will happen anyway.

If the mission is less changes and registry writes then lower power charge needs to be aware of the charge curve. If it already is then perhaps a hard cut off of no more low power charge calculations and changes once into the charge curve affected high SOCs.