Low Power charge finishes too early (Low priority issue)

[mpartington]

Describe the bug When "Set Charge Low Power Mode" is on, Predbat is hard coded to charge the battery at a rate that will finish 10 minutes before the end of the charge window. My experience is that it consistently finishes 20 mins early. I have changed settings to try and tweak this, but best I can get is to 14 mins early, and that includes changing the margin in predbat.py to 5.

Losses trimmed down to 2% Inverter and 2% charge on the attached log file. This only made around 2 mins improvement from the previous night where they were both set to 4%. The battery charge curve used was created by predbat and matched my own manual calculations. The only think I did override was the scaling factor to 1 from the 0.91 that predbat recommended (otherwise this would make it finish even earlier)

Expected behavior To finish the charge closer to the 'Margin' set in predbat.py

Predbat version v7.16.2 xxxx

Environment details

• 1x AC3 & 2x5.2 batteries
• Standard HAOS installer

Screenshots [

Log file appdaemon.log](https://github.com/springfall2008/batpred/files/14472654/appdaemon.log)

[springfall2008]

Is this now fixed?

[mpartington]

Not sure, I've just tried it with some extra IOG slots and it is finishing way too early.

Might not be accounting for them in the calc, I'll also try on a normal 23.30 to 05.30 period next few days

predbat.log

[mpartington]

Looks like it's not working with IOG extra slots, charging full speed most of the time

[mpartington]

IoG slot was to 6am, it finished at 5.15. More of a concern is the clunky way it is setting the charge power, frequent changes from high to low and even stopped charging a few times.

[mpartington]

I think I found 2 issues that were causing this to fail

1. I had set all my charge slots manually (using the overrides). I did this to prevent any discharge within the period, as I don't want it to interfere with tumble dryers.etc.
2. The combine starts slots MUST be enabled, otherwise it doesn't calculate for the full period

Not sure if these are bugs or limitations , but either causes the issue

[mpartington]

To add to previous comment. It appears if you force all the slots to charge, it then sets freeze charge and doesn't consider these as part of the overall charge slot.

Secondly, when I tried to combine slots, it didn't combine them into a single slot, this resulted in it calculating the low rate charge for the SOC target set for each of the 3 charge slots, rather than 1 single. I don't know if this was a consequence of forcing and then cancelling the slots earlier, as tonight's charge is currently showing as 1 big slot (as expected)

Tonight (one big slot)

With nice charge constant rate for whole period

Not using combined slots breaks it, as it seems to just consider each 30 mins slot, which doesn't lead to same result (presumably the soc target is a little too high for each slot, which leads to a compound error

[mpartington]

Additionally, related to the very original reason for raising the ticket, it still finished 20 mins before the end of the charge slot - to a bit early

last nights behaviour

[gcoan]

Additionally, related to the very original reason for raising the ticket, it still finished 20 mins before the end of the charge slot - to a bit early

If the charge finished 20 minutes early then I don't think that's a bad result. A much better result than the charge being mis-calculated and finishing 20 minutes too late.

There's a granularity to setting charge/discharge rates on the inverter so when Predbat commands a rate of say 2813W charging, GivTCP writes this as a charge rate of say 34 to the inverter. If I remember correctly the charge/discharge rate gets scaled from 0 to 50. So with these steps in charge rate, it's never going to be perfect.

Also for me I find as well as the charge and discharge rate tail-off at full and empty, the normal rate can vary, presumably depending on internal cell temperatures within the battery. Most of the time I see 2.4kWh charging but sometimes 2.5 and sometimes a touch lower. Predbat of course can't know about this, it can only recalculate the charge rate instruction every 5 minute run.

With all this variability, personally finishing 20 minutes early I'd say is an acceptable result. If Trefor can tweak it further then great but wouldn't want this at the risk of missing the charging window.

[mpartington]

The fact it is recalculating every 5 mins is why it should be able to accommodate all these unknowns, variables and rounding errors. It consistently finishes 20 mins early, which suggests to me there may be a possible tweak needed to the logic. When I first raised this Trefor suggested changing a hard coded value (that sets the target 10 mins before). I changed this to zero and I think it only made a few minutes difference to the finish time, not the 10.mins it should have.

20 mins early isn't bad, hence why raised as a low priority. That hasn't changed, and given the backlog of open issues (many of them trivial) I would be happy for Trefor to close (he's too nice with entertaining suggestions / non core FRs 🤣)

It's certainly better on a 6hr slot than the 4hr I had previously.

Maybe now more important is a change to how the consecutive (available) slots are grouped when this is active, however that also seems to work if set to combined. Problem with combined is it leads to issues with ad-hoc charging such as before saver sessions (if they are worth doing this year). Maybe that is fixed

Happy to close if it falls below the line

[mpartington]

Unfortunately my 'combined charge slots' have split again. Might be the extra IOG one or something else. Means it's not low power charging across the full window