freeze charge, doesn't!

[gcoan]

Describe the bug
Plan shows freeze charge mode, but batteries are actually charging at full rate

I think the problem is that the charge start time is set for 13:30, its currently 13:58 so the inverters start charging.

I manually set battery pause mode to pause both to stop the charging, but had to do that twice to delay starting charging until the power up event as predbat reset it each time it ran

Expected behaviour
Freeze charge only allows charging from solar, not grid import

Predbat version
8.14.4

Environment details
HAOS
2x Gen 1 hybrid inverters each with their own battery

Log file
predbat.log

[darryl2k]

I just noticed that I have a similar issue. I have paused the battery.

[theblackcat9]

I think I've got the same problem with "Hold Charge".

As there has been more solar around over the last few days, predbat has been planning to "Hold charge" overnight during the cheaper off-peak period, so that the solar tops up the battery to 100% around 4pm to export excess solar during the peak period. I'm on Octopus Flux tariff. This is how I would expect predbat to work. However, what has actually happened is the battery has charged up during the off-peak period to nearly 100% meaning the solar tops up the battery to 100% around noon and is exporting the "excess" solar during the day export rate (12.74p/kWh) which is less than the overnight off-peak rate(14.47p/kWh), which is not ideal.

When predbat wants to "hold charge", it looks like it is setting the target SOC to a lower value than the current SOC. However, when this happens, my battery is charging from the grid until it reaches 100% or predbat does something different.
I did an experiment to set a timed charged from the givenergy portal, setting the target SOC to lower than the current SOC to see if the same thing happened and it didn't. It worked as expected, the grid supplied the house but the battery did not charge.
When I had a look at the givtcp control entities, predbat was setting number.givtcp_ch9999g999_target_soc as the target SOC and the portal set the entity number.givtcp_ch9999g999_charge_target_soc_1.
As the charge schedule is activated, I think the inverter is looking at the charge_target_soc_1 value which is at 100% and therefore charging the battery rather than using the target_soc value.

I'm using givtcp 3.0.4 and predbat 8.15.1 and have a single AIO.

Is this a bug in the way predbat is setting the target SOC or just in my apps.yaml?
The relevant parts of my apps.yaml are:-
geserial: 'ch9999g999'
givtcp_rest:
- 'http://192.168.0.xxx:6345'
I've also got a number of non-rest definitions including this one:-
charge_limit:

• number.givtcp_{geserial}_target_soc

Predbat status:-

Inverter changes from portal remote control log:-

SOC % history. Initial SOC at 2am was 67%. Target SOC for "Hold charge" was set to 63%

It means I'm now having to put predbat into read only mode overnight as I can't trust what it is doing.

[sammort]

I'm also seeing a planned "Hold Charge" prior to today's Octopus Saving Session is instead charging the battery from the grid.

[gcoan]

@springfall2008 does #2084 fix this?

[springfall2008]

@springfall2008 does #2084 fix this?

No it's unrelated

Freeze charge should set the target Soc to the current level, is it not doing that?

[gcoan]

@springfall2008 does #2084 fix this?

No it's unrelated

Freeze charge should set the target Soc to the current level, is it not doing that?

In the screenshot above it looks like target SoC was set to the current SoC on both inverters

screenshot

But both were still charging at full rate 🥺

[sammort]

@springfall2008 I'm seeing the same behavior again today, triggered by predbat planning to Hold Charge up to the planned Octopus Saving Session. Instead the AIO is charging at full rate from the Grid. (I'm putting predbat in read-only mode to avoid this behaviour)

predbat.log
predbat_plan.html.txt
predbat_debug.yaml.txt

In the logs, you can see from the timestamps starting 2025-03-12 12:15:39.842579 that I disable read-only and the system begins to charge from the grid.

[WyndStryke]

@gcoan I looked into this from the perspective of a Fox inverter, and made some observations. On the Fox side, the solution is to set the inverter's mode to 'back-up' which will hold it steady at the reserve_soc via the charge_freeze_service, but along the way I found some stuff which might be relevant to other inverters.

In particular, on the code path for inverters which don't support pauses or charge periods, or target_soc, it seems to be setting the discharge rate to 0, but stays in force-charge mode on the inverter (so setting the discharge rate has no effect). If it were to terminate charge mode and set itself to force discharge instead, with a zero discharge rate, then I think that might work?

Setting the target_soc to pick up the number.max_soc does seem to work overnight for the Fox, but the problem there is that a) on the Fox, number.max_soc is a hard limit which completely blocks all forms of charging, and b) it is not being reset to 100% and stays set to reserve_soc for the rest of the day (despite switch.predbat_inverter_soc_reset being set on). If it reset to 100% then this would also be a viable solution.

#2114 (comment)

[springfall2008]

From another thread, maybe 'enable AC charge upper limit' needs enabling on the AIO?