Predbat lets the battery discharge when 'hold charging'

[gcoan]

Predbat has set the mode to hold charging which should be holding the battery charge, but it is in fact discharging:

I believe this is caused by there being a discharge schedule set that covers the current time period. If I change the discharge period end time, the discharging stops (the soc had reached 4% as well, but I have seen this happen before that changing the discharge time to not include 'now' stops the discharging when in hold charging)

The whole behaviour in this half hour slot is a bit weird, it turned charging on, then hold charging, now back to charging again:

19:35 charging 19:40 hold charging (but doesn't) 19:45 charging

Here's the logfile: appdaemon (2).log

Gen 1 hybrid inverter

[gcoan]

19:50 back to "hold charging". but its not actually holding, its discharging again. Blows my theory about the discharge times, must be because the battery reserve isn't set to > 4: its just discharging the battery it charged 5 minutes ago !

[gcoan]

This morning its hold charging correctly with battery reserve set to 100%:

Looking at the history of battery reserve and battery charge/discharge power at 19:30 slot yesterday evening and during the night, can especially see that the battery charged then discharged repeatedly in the 19:30 slot, and maybe a bit occurred in the night as well

[slopemad]

It could be similar to the ticket I just raised at #443 where reserve and target soc are the same?

[gcoan]

I did wonder that myself @slopemad . I have seen this behaviour as well where the soc bounces either side of the reserve.
In the past I've seen a lot more "progressive charge" behaviour rather than charge to 100% which can tend to make this happen more especially if current soc is only just under target soc. My current plan is showing more "big charges" though so I think the behaviour has changed:

The particular issue above was predbat changing its mind about the plan every 5 minutes it ran. Swapping from a charging plan to a 'hold charging' plan, but as I noted, some of the hold charges are with 4% reserve and so the battery then discharges. As you say, not good for battery cycles (as well as being not efficient with charging losses etc)

[springfall2008]

Would setting the reserve say 1% higher than the hold level have any impact?

[springfall2008]

If someone gets a chance to try this fix on main that would be great: https://github.com/springfall2008/batpred/commit/8700fcd6bb2c0c05c68a96d3a1d72e58386c5ef1

[slopemad]

Would setting the reserve say 1% higher than the hold level have any impact?

Probably...

If someone gets a chance to try this fix on main that would be great: [8700fcd]

OK, so I was stil on 7.13.26, so I've just upgraded to 7.14.6 and will then see how that looks then have a try of this beta.

[gcoan]

If someone gets a chance to try this fix on main that would be great: https://github.com/springfall2008/batpred/commit/8700fcd6bb2c0c05c68a96d3a1d72e58386c5ef1

I'll try this fix Trefor

Here's the previous plan on 7.14.6:

And after upgrading to main:

All the hold charges are with the soc on 4% so it might be a bit before I see what difference it makes

[slopemad]

I did some testing (without installing beyond 7.4.16) of various different values of target soc and reserve, and found the only way to reliably stop it going through regular charge and discharge modes was to set reserve to 100. Setting reserve to target + 1 (or +2) was not reliable for whatever reason.

[gcoan]

@springfall2008 I'm running the main version 8700fcd

Two observations of behaviour today.

First at 13:10, plan was hold charging with limit 33%. Actual soc was 44% so the battery discharged down to the 33% reserve. Following slots were cheaper so this may well have been a sensible plan, maybe a bit confusing to call it hold charging when it's actually discharging to a limit?

[springfall2008]

Yes its a naming thing, hold charge is when the charge % is above the target and so it will hold at the given level once it's reached. Any ideas how it could be better described? I use the word 'charge' to mean importing from grid and 'discharge' to mean exporting currently.

[gcoan]

Second set of observations at 1930 onwards, the plan oscillated between charging and hold charging every 5 minutes, but the hold charges were all with reserve 4% so the battery would discharge the soc gained in the previous 5 minutes of charging. Two issues I think, why keep swapping to hold charging when the subsequent agile slot was mor3 expensive so it would have mad3 sense to charge for the full slot and then discharge the subsequent slot. Second issue is hold charging but soc set to 4%, so causing discharge.

19:36, just changed from charging to hold charging (but actually discharging) for the first time

19:42 changed back to charging again

19:45 plan changed again to hold charging (at 4% reserve)

19:51 freeze discharging now

By 20:00 of course the battery was empty so despite it setting freeze discharging it was actually grid importing

[gcoan]

Logfile from 13:00: appdaemon.log.2.txt

And 19:30: appdaemon.log.1.txt

[gcoan]

Yes its a naming thing, hold charge is when the charge % is above the target and so it will hold at the given level once it's reached. Any ideas how it could be better described? I use the word 'charge' to mean importing from grid and 'discharge' to mean exporting currently.

I think the problem is that 'charge' implies its charging, whereas its not, it could well be discharging.

Maybe 'hold battery level'? But even then its open to mis-understanding because its only 'hold' when the battery reaches that level and if its above, it'll still discharge. 'hold at level'? Implying its holding a specific level rather than holding the current level?

[springfall2008]

Well tracked down I think I have found the bug, during a charge freeze when charge hold is enabled it disables charging and tries to hold on the reserve, but the reserve is set to the target (4%) rather than the current SOC and so it fails.

I'm going to push a fix to main shortly.

Also in your log you still have tweak optimisation enabled, I think I might just remove it as it doesn't help.

[springfall2008]

I've made a fix on main, please can you beta test it for me?

[gcoan]

Well tracked down I think I have found the bug, during a charge freeze when charge hold is enabled it disables charging and tries to hold on the reserve, but the reserve is set to the target (4%) rather than the current SOC and so it fails.

I'm going to push a fix to main shortly.

Also in your log you still have tweak optimisation enabled, I think I might just remove it as it doesn't help.

Great thanks Trefor, that does sound like it.

Do you know why it's swapping between charging and hold charging over the slot, why not just charge for the whole period?

Load for the next period is 1.43kW, which needs 27% charge of the 5.2 battery to support that. Even if the battery charged for the full 30 minute slot, it'd only charge 1.3kW into the battery so a full charge would have been justified I'd think?

I turned the tweak optimisation on as the advice in the docs was that it could give slightly better results with agile tariffs https://springfall2008.github.io/batpred/customisation/ Happy to do set it either way

[springfall2008]

Well tracked down I think I have found the bug, during a charge freeze when charge hold is enabled it disables charging and tries to hold on the reserve, but the reserve is set to the target (4%) rather than the current SOC and so it fails. I'm going to push a fix to main shortly. Also in your log you still have tweak optimisation enabled, I think I might just remove it as it doesn't help.

Great thanks Trefor, that does sound like it.

Do you know why it's swapping between charging and hold charging over the slot, why not just charge for the whole period?

Load for the next period is 1.43kW, which needs 27% charge of the 5.2 battery to support that. Even if the battery charged for the full 30 minute slot, it'd only charge 1.3kW into the battery so a full charge would have been justified I'd think?

I turned the tweak optimisation on as the advice in the docs was that it could give slightly better results with agile tariffs https://springfall2008.github.io/batpred/customisation/ Happy to do set it either way

I think the swapping is as the hold isn't working, hopefully that will go away now.

Let me know what you think, I can put the tweak back if it helped but it seems to had broken other stuff

[gcoan]

I've made a fix on main, please can you beta test it for me?

Will do. Might be tomorrow before it next tries hold charging

[springfall2008]

I've made a fix on main, please can you beta test it for me?

Will do. Might be tomorrow before it next tries hold charging

I just spotted a bug, the nice re-format script showed I missed some brackets - now fixed!

[gcoan]

I've made a fix on main, please can you beta test it for me?

Will do. Might be tomorrow before it next tries hold charging

I just spotted a bug, the nice re-format script showed I missed some brackets - now fixed!

Had installed 8ff5fdc

Installed now d5c4dee and will see what it does

[gcoan]

Was able to see hold charging tonight. The specific issue of 4% reserve didn't happen but it didn't quite go to plan (and the plan looked a bit dubious)

22:30 charging for the entire slot, which was correct as it was the cheapest slot of the night

But 2300 was planned to be a hold charge slot at 52% soc. I thought it would have been better to discharge in this slot as the import rate is 14.33 rather than hold charge. Plenty of other lower price slots in the evening to recharge in, and 01:00 and 02:00 both lower prices than 2300 but these are Eco discharging slots, but yet 2300 isn't?

2300 went into hold charging, soc 54, réserve 53 so started discharging a bit

2305 plan updated to label this a charging slot but status remaining as hold charging

2307 battery continues discharging, soc now 49 but réserve 52 🤷‍♂️

2311 changed back to charging mode

I can get the logs tomorrow. Still got tweak set on

2355 soc currently 74% and charging, good, but the plan shows 0030 as a charging slot still, holding soc at 100% when the rate is 14.57, then releasing it in the next slot when the rate is 13.89? Would have made better sense to discharge in both slots?

[springfall2008]

I think some of it comes down to losses, discharging effectively incurs a round trip loss (as you have to charge it back later as well). If you turn on plan debug you can see the rates after losses.

Tweak plan was removed although maybe I should keep it as an advanced feature for now to see if it helps or not...

[gcoan]

I'm moving the points I was making about future slot plans to a new issue #449, so as to keep this one focussed on battery discharging when in hold charging mode.

@springfall2008 Should I install the latest 7.14.7 or remain on the main branch?

I will have a look what happens next time hold charging is planned/executed

[springfall2008]

I'm moving the points I was making about future slot plans to a new issue #449, so as to keep this one focussed on battery discharging when in hold charging mode.

@springfall2008 Should I install the latest 7.14.7 or remain on the main branch?

I will have a look what happens next time hold charging is planned/executed

I released what was on main this morning but with the tweak optimisation still supported and some other documentation updates so yes please update.

[gcoan]

OK, I have upgraded to 7.14.7

The battery's currently holding nicely at 91%

I'll try to take a look this evening as the flip-flopping between charging and hold charging usually occurs after the evening peak when rates are going up and down

[gcoan]

I think this is fixed now, I'm not seeing the hold charges being set to 4% soc which was causing a full discharge.

I do see some discharging when in hold charge, eg this morning, plan was Hold Charge to 91% but actual soc was 98% so the battery discharged down which is fine. Maybe the label "hold charge" is a bit misleading and not always obvious what the intent is (compared to Freeze Charge and No Charge)

[gcoan]

Thanks for the fix

[gcoan]

Predbat 7.14.11

I'm seeing predbat again failing to hold charge and the inverter cycling between charging and discharging. Seems that it doesn't hold at the battery reserve as you can see the discharge dropping below it

20:41 hold charging. Reserve 23 but soc already 21 and continuing to discharge

20:57 charging back up from 17%

Battery soc and power in/out over this period:

[gcoan]

21:45 predbat is freeze charging and this appears to be working fine, the battery is idle. Only difference I can see to hold charging is that Enable charge schedule is turned on

Maybe for my gen 1 hybrid inverters the hold charging as predbat does it doesn't work and I need to freeze charge instead?

[slopemad]

If Predbat configures the inverter with a reserve of, say, 23 and the battery SOC continues to discharge below that, then I think that'd be a problem with the GivEnergy system rather than Predbat? Predbat could work around it, but it's surely up to GivEnergy to honour the settings it's asked for? I have seen this with my own G1 inverter too and raised it in the FB group in the past.

Previously I've suggested that for a 'Hold Charge' (I.e. you don't want any more discharging), the reserve should be set to 100. Setting it to 100 seems to change the Givenergy mode from "Eco" to "Eco (Paused)" and so, no discharging at all, rather like setting the discharge rate to 0. I'm not sure if this is a different behaviour for G1s rather than later models?

I've mostly been running PB in read only mode for a while, because whilst pricing has been incredibly flat, it doesn't necessarily want to charge up in the cheapest slots. For example, right now...

Surely out of all this, instead of charging from 77% to 91% at 09:30 at 17.68p, it'd be better to hold at 77% and take advantage of all those juicy 16.xp slots this afternoon? (The actual plan I've set automations for is to allow it to drop to 60% in the slots which are over 19p, and charge back to 88% between 1 and 2pm, hold at 88 until 4pm, and then set reserve to 4%. My plan feels like it'd be cheaper than the one Predbat has set.

[springfall2008]

Previously I've suggested that for a 'Hold Charge' (I.e. you don't want any more discharging), the reserve should be set to 100. Setting it to 100 seems to change the Givenergy mode from "Eco" to "Eco (Paused)" and so, no discharging at all, rather like setting the discharge rate to 0.

Annoyingly some inverters refuse to be set to 100% reserve so I've had to make the default 99% (can be changed in apps.yaml). And setting discharge rate to 0 seems to still have some discharge (around 200w).

@Gcoan - I should probably try the hold charge with the scheduled charge turned off?

[gcoan]

@springfall2008 I have to say I don't understand it. Last night as shown above https://github.com/springfall2008/batpred/issues/435#issuecomment-1856591298 hold charging definitely wasn't working, but earlier in this issue https://github.com/springfall2008/batpred/issues/435#issuecomment-1850144361 I have screen shots where hold charging was working and the battery wasn't discharging below reserve.

In both cases scheduled charge wasn't set. The only difference I can see between the two is that in the non-discharging example the current time was not within the charging period set on the inverter, whereas on the last night example where hold charging didn't hold, the current time was within the inverter charging period. In both cases the inverter wasn't within the discharge period start/end times.

This makes no sense to me. @slopemad I agree, it looks like an inverter bug and at best predbat has to work around it. I can't see any hope of GivEnergy finding and rolling out a bug fix for this in anything like a reasonable time frame..

I've also just turned predbat into read-only as well and set the battery to Eco to let it support some of the higher rate load this morning. Its very marginal, would have thought it'd have been better to hold/freeze charge at 09:00 and through the morning (then charge in the afternoon) rather than charge the inverter at 20.95p when cheaper slots are coming

[gcoan]

Predbat was hold charging the battery this morning ok

I tried moving the charging window to outside of the current time, both before and after the current time, and no matter what I did, it carried on hold charging and the battery didn't discharge.

I took some more screenshots of the inverter settings so when it next fails to hold charge I'll see if I can work out what's different and repeat the test

[slopemad]

@gcoan I don't understand, what are you asking it to do? The battery reserve is 52%, the SOC is 51%, the battery isn't discharging, which sounds like desired behaviour from that current configuration?

[gcoan]

@gcoan I don't understand, what are you asking it to do? The battery reserve is 52%, the SOC is 51%, the battery isn't discharging, which sounds like desired behaviour from that current configuration?

Absolutely @slopemad this is the correct desired behaviour this morning, the battery charge was held. But yesterday evening it wasn't held, it discharged below reserve soc and I don't know why. Was trying to find what was the triggering conditions, but couldn't work it out

[slopemad]

That is definitely a bug I've seen in GivEnergy, so it isn't the fault of PB that the GE isn't working right. PB could work around it by setting the reserve soc to maximum (100 or 99 on those inverters which don't work with 100). But then, I've also seen problems with the inverter going into Eco (Paused) mode and then refusing to go back into regular Eco mode without a reset and reboot.

[slopemad]

So my G1 is on 3006, and whilst I've noticed missing SOCs before, I've never looked at it particularly deeply and indeed, I now consistently see that several SOC points are missing : these ones: 10, 16, 22, 28, 34, 40, 46, 52, 58, 64, 70, 76, 82, 88, 94 (I don't know if different battery combinations cause different missing SOCs?) I guess that when Predbat sets the target or reserve to be one of these values, we end up with oscillation or otherwise unpredicted results.

At 13:25 I set target soc and reserve to 77, and ensured the inverter was in a charge window with enable charge turned on, and this is what I saw, a tiny bit of charge leaking in, but no discharge observed, so no oscillation...

@springfall2008 perhaps there could be some kind of apps.yaml setting where a user could define a list of missing SOCs, and so if Predbat wants to set the target and/or reserve to one of these values, then it actually sets it to either one above or one below?

[mpartington]

10, 16, 22, 28, 34, 40, 46, 52, 58, 64, 70, 76, 82, 88, 94, 99% were missing for me as well (I have 2 x 5.2kWh), but it did vary a little depending on types / multiples of batteries that different testers had.

The good news is that it is fixed in all the latest battery firmware updates and all numbers are available, although I realise not everyone is always keen to update the BMS if things are working well.

[slopemad]

Yep, I have a couple of 5.2 batteries, and while I think about it I'm also missing 99. QUite impressive they managed to invent a computer which can't count. It doesn't even appear to be a logical place for a naturally occurring rounding error to be introduced.

My main aversion to doing the upgrade is that no doubt it'll start doing the big calibrating import between 4pm and 7pm.

[springfall2008]

Start the calibration after peak rate and will be done by morning On 18 Dec 2023, at 21:51, slopemad @.***> wrote: Yep, I have a couple of 5.2 batteries, and while I think about it I'm also missing 99. QUite impressive they managed to invent a computer which can't count. It doesn't even appear to be a logical place for a naturally occurring rounding error to be introduced. My main aversion to doing the upgrade is that no doubt it'll start doing the big calibrating import between 4pm and 7pm.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[gcoan]

closing this as not seen it happen for a long time and not sure where the issue was going