Errant plan behaviour with 8.4.11, a semi-freeze discharge

[gcoan]

Describe the bug On 8.4.10 Predbat was planning freeze discharge for half of the power up event and then charging for the remainder. Upgraded to 8.4.11 and the plan (and behaviour) is a sort-of discharge freeze, but it isn't.

Plan shows flat SoC, but not set to freeze discharge or hold charge mode:

Inverters have charge rate of zero set but not Pause Charge (so are slightly charging):

I think the problem is this changed line in inverter.py:

If I revert this one line back, plan looks more like what I expect:

Expected behavior Normal behaviour, freeze discharge operating as normal.

Predbat version 8.4.11

Log file appdaemon.log

[SwiftRR]

Just when I thought that Freeze discharging has gone to bed .......

Screenshots below show v8.4.10 and v8.4.11. Virtually no difference other than the '99' disappearing from the plan. Notice that 99 has resurfaced though in the target of 63-99% The power diagram is typical for me with freeze discharging and PV exceeding load. Excess is exported to grid with a small trickle of about 28W to the battery. The givTCP 3.0.0 log shows Pause Disable or Pause Charge (with my CRITICAL graceful error preceding the Pause instruction). My plan has been Freeze discharge for most of the day with very few inverter tweaks.

I think that Predbat is using Freeze Discharge to prevent the battery being charged from solar with the inherent losses when involving my GE AC coupled inverter. There are fewer losses exporting directly from my SE inverter, so I think Predbat is trying to generate the most cost-effective plan. Predbat really wants to charge battery from the grid and export excess solar.

So nothing to add from me. v8.4.11 makes little difference from v8.4.10 for my setup.

Rob

[SwiftRR]

I have come across this quote from Trefor on his Predbat Facebook page. I may or may not be relevant ....

Risk of running out of battery Some users have reported problems where freeze discharging in the day leads to an empty battery before bed if the load prediction is not totally accurate. I've found that the PV10% scenario prediction doesn't help much here as freeze discharging has no impact if there isn't any spare PV to export. You have a few options

1. Turn off freeze discharge (the latest release has a toggle for this). This will prevent any freeze discharging in the day and export all your solar as forced export instead. This of course involves more losses but keeps your battery level until bed time.
2. Try setting load_scaling to 1.1 and load_scaling10 to 1.2 (rather than 1.0 and 1.1). This essentially makes the plan a little more pessimistic, you will still get freeze discharge if there is enough spare solar to cover additional load.
3. Increase Best SOC Keep to tell Predbat to hold more spare battery back. This will however prevent force export below the given battery level. Personally I'd favour option 2)....

Rob

[gcoan]

Just when I thought that Freeze discharging has gone to bed .......

Yes I was somewhat surprised to see the plan when I upgraded to 8.4.11. I first thought it was the change I had introduced to suppress the discharge freeze limit, but reverting this change it still misbehaved so I found the other change that Trefor made to inverter.py which I believe is the cause of the problem I saw. At the moment I've left the inverter.py change reverted out.

Screenshots below show v8.4.10 and v8.4.11.

Virtually no difference other than the '99' disappearing from the plan.

It may be that you have different switches on than I do which is why I saw these different weird results.

Notice that 99 has resurfaced though in the target of 63-99%

Yes I missed that out as I don't have the headings on my plan. I also saw that the 99% target still appears in the change of status alert that Predbat sends out so I will have to find and fix both of those.

I think that Predbat is using Freeze Discharge to prevent the battery being charged from solar with the inherent losses when involving my GE AC coupled inverter.

Correct

There are fewer losses exporting directly from my SE inverter, so I think Predbat is trying to generate the most cost-effective plan.

Correct. Also trying to prevent charging the battery off solar only to then force discharge it later on as that's two lots of battery losses incurred unnecessarily.

Predbat really wants to charge battery from the grid and export excess solar.

Not as simple as that I'd say, all depends on the rates. Yes charge from grid if that's cheaper (after losses) than charging with solar and losing out on export income.

Geoffrey

[gcoan]

Notice that 99 has resurfaced though in the target of 63-99%

Yes I missed that out as I don't have the headings on my plan. I also saw that the 99% target still appears in the change of status alert that Predbat sends out so I will have to find and fix both of those.

I've made a change to remove the misleading 'target 99%' part of the predbat status when Freeze discharging.

The status which is sent in the notification and appears at the top of the plan now reads:

Freeze discharging current SoC NN%

Normally these statii are "target %-%". I thought it useful to include the current SoC still but have changed the label to make it explicit what it is.

Will test it on my own Predbat tomorrow and if OK then I'll include it in a PR

[SwiftRR]

Please see my latest plan which goes right back to my first comment for the issues thread that we closed last night.

Although overnight rates are not 'low', I would have thought that the 1:00 - 4:30 slots could have been used to charge the battery rather than to leave it at about the same level (or as you have said, a flat SOC).

Freeze discharge seems to vicious. I will see how and to which extent predbat modifies this plan following Nordpool predictions. The status does look very useful but getting the right balance?

But I can see me increasing the load scaling and load scaling10. I don't really want to go back to v8.4.8.

Her's my overnight fix:

Rob

[gcoan]

my rates are about 0.5p/kWh more than yours and its varied between doing 2 or 3 charges in the lowest periods overnight and then either freeze discharging for most of the day or letting the battery SoC rise and then hold charging. Its swapped between the two so I suspect its quite finely balanced for me.

On your plan, yes Predbat could have charged the battery up a bit more overnight, and it looks like the overnight slots are a little bit cheaper than the effective export rate tomorrow, so maybe there's something dissuading it from charging?

Metric min improvement and metric min improvement discharge set to non zero? Metric battery cycle cost non zero?

What does the rest of the plan look like? If predbat fills the battery up, what's it going to use it for? There is a counter argument to not charge the battery unless it's going to be needed the next day. My forecast plan hours is currently 24 hours but extending this will predbat to 'see' the extra future load which will influence the plan.

At the moment I think I'm happy with the discharge freeze functionality - not withstanding the reason I raised this issue as I think a change made in 8.4.11 was incorrect/dubious.

you can turn discharge freeze functionality off now if you want to

[SwiftRR]

my rates are about 0.5p/kWh more than yours

Yes but outweighed by Yorkshire standing change of 67p !

What does the rest of the plan look like?

Before I force charged overnight, my plan for today also showed with Freeze discharge all through the day. From my first plan, you can see that my SOC reduced to 29% at 8:30 am. Plenty of flexibility for Predbat to discharge in evening (it often does). I am predicted good PV generation, as you can see, but notice that the SOC increases steadily during the day from 8:30 am to 4:30 pm by 10%, despite battery 'charging' being disabled with Freeze discharging. Is this a feature of AC inverters?

I probably force charged for too long but I felt this gave me more flexibility.

Metric min improvement and metric min improvement discharge set to non zero? Metric battery cycle cost non zero?

I have most settings at defaults shown in web UI. Metric min improvement = 0; metric min improvement discharge = 0.1 Also Metric Battery Cycle Cost = 0

If predbat fills the battery up, what's it going to use it for? There is a counter argument to not charge the battery unless it's going to be needed the next day. My forecast plan hours is currently 24 hours but extending this will predbat to 'see' the extra future load which will influence the plan.

I judged that real rates wouldn't be known until 4 pm and my battery SOC could have been really low at end of evening. Rates are anticipated to by poor. In my apps.yaml, I have forecast hours = 48

My losses are 0.3/0.3 and 0.4 (inverter). As nearly all of my PV is exported, should I lower the inverter loss?

I like the idea of Freeze discharging and its deterrent effect on charging the battery from PV, depending on grid rates. We are both questioning how Predbat is setting Freeze discharge. Is it too vicious?

Rob

[gcoan]

my rates are about 0.5p/kWh more than yours

Yes but outweighed by Yorkshire standing change of 67p !

Yeah, mine's 40p so you need to import a lot each day to make up the difference. Some days in winter I would do but not every day

What does the rest of the plan look like?

Before I force charged overnight, my plan for today also showed with Freeze discharge all through the day.

My plan looked much the same, freeze discharge predicted all day and keeping SoC fairly low. Predbat has a 'forward window' of I think 4 hours ahead where it does some things differently in the projection (can't remember what), so I've learnt not to believe the longer term plan too much as long as it sorts itself out in the short term plan.

From my first plan, you can see that my SOC reduced to 29% at 8:30 am. Plenty of flexibility for Predbat to discharge in evening (it often does).

I left Predbat to do its own thing last night, it (as planned at midnight) charged with 55p of import in the cheapest slots from 3:30-5:00 which raised my SoC from 7% to 40%, the SoC then dropped down through the morning until solar started. The originally planned freeze discharging wasn't applied and as the batteries are now nearly full, only now is it applying freeze discharge.

I am predicted good PV generation, as you can see, but notice that the SOC increases steadily during the day from 8:30 am to 4:30 pm by 10%, despite battery 'charging' being disabled with Freeze discharging. Is this a feature of AC inverters?

No, having looked at the code, I don't see any recognition of different inverter types. I think this is Predbat changing between Idle/Eco charging and freeze discharging WITHIN a half hour slot. Be interesting to see what happens in practice, how the status changes within the slot to confirm this hypothesis.

I have most settings at defaults shown in web UI.

Metric min improvement = 0; metric min improvement discharge = 0.1

Also Metric Battery Cycle Cost = 0

Same as me, those won't adversely affect the plan.

In my apps.yaml, I have forecast hours = 48

So do I. There's also input_number.predbat_plan_forecast_house which is set to the default 24 hours in mine. You could extend this one to say 30

My losses are 0.3/0.3 and 0.4 (inverter).

As nearly all of my PV is exported, should I lower the inverter loss?

Mine are 0.05/0.055 and 0.04. I increased the battery losses after reading something somewhere.

I'm sure you mis-typed those percentages and missed out a zero as otherwise it really won't want to use the battery!

I like the idea of Freeze discharging and its deterrent effect on charging the battery from PV, depending on grid rates.

We are both questioning how Predbat is setting Freeze discharge. Is it too vicious?

Maybe try turning it off if you don't want it on.

Rob

At the moment for me I'm OK with it. its taken a bit to get used to a low SoC overnight and as I said not immediately trusting the long term plan, but its behaving OK

Geoffrey

[SwiftRR]

I think this is Predbat changing between Idle/Eco charging and freeze discharging WITHIN a half hour slot. Be interesting to see what happens in practice, how the status changes within the slot to confirm this hypothesis.

Predbat plans can change drastically with time ............

Plan last night:

Actual status behaviour I have pieced together Predbat's status for me with details from 2 am this morning (5th Oct). This may provide evidence in support of your hypothesis.

Conclusion: Don't panic, Predbat knows best (usually) I am going to just let Predbat get on now without my interference, essentially running in Agile import/Outgoing fixed, using Predbat default configuration.

My initial plan for 5th-6th Oct based on Nordpool does not look wise i.e. not charging at all during nighttime predicted low rates) but Predbat should change this anyway. I will see ......

Rob

[gcoan]

I have pieced together Predbat's status for me with details from 2 am this morning (5th Oct). This may provide evidence in support of your hypothesis.

It is as I suspected would be the case @SwiftRR , split slot behaviour, swapping between Idle and Freeze Discharging within the slot

Glad to hear that you're trying to be hands off and trusting what Predbat does, I've stuck a few extra force discharges (extending partial slot discharge to full slot), but otherwise tonight its doing a great job of exporting and recharging the battery at lower rates, then repeating to end the night on a full battery for what looks like a poor sun day tomorrow.

However the above does indicate another small issue @springfall2008 Predbat plans a split slot behaviour of Idle and Freeze Discharging, but on the plan this was shown as FD for the entire slot.

And @springfall2008 if you could take a look at the initial thing I raised in this issue, I think a code change made in 8.4.11 looked wrong so reverted it as the plan execution was very weird

[springfall2008]

However the above does indicate another small issue @springfall2008 Predbat plans a split slot behaviour of Idle and Freeze Discharging, but on the plan this was shown as FD for the entire slot.

And @springfall2008 if you could take a look at the initial thing I raised in this issue, I think a code change made in 8.4.11 looked wrong so reverted it as the plan execution was very weird

The code change says if the inverter doesn't have a scheduled charge enable register then write the charge start/end time to midnight when disabling the charge window. Previously it would not do that for current control devices.

As GE inverters have charge enable time how could that impact?

[gcoan]

The code change says if the inverter doesn't have a scheduled charge enable register then write the charge start/end time to midnight when disabling the charge window. Previously it would not do that for current control devices.

As GE inverters have charge enable time how could that impact?

I don't know, all I can say is that after upgrading to 8.4.11 I observed what was planned as a freeze discharge, the charge rate being set to zero but pause charge was not set - which it normally is.

When I reverted this one line of change in inverter.py, the plan went back to "normal".

When we are next in Freeze Discharge I'll try changing the code again back and forth and see what happens

[SwiftRR]

However the above does indicate another small issue @springfall2008 Predbat plans a split slot behaviour of Idle and Freeze Discharging, but on the plan this was shown as FD for the entire slot.

Today, 'Freeze discharge' has been set in the Predbat plan all morning and afternoon (lots of nice sun). My status reports report that, and within every 30 minutes period, there is 20 min 'Freeze discharge' and 10 min 'Idle'. Any excess solar in the idle 'bits' seem sufficient to increase SOC by about 1% every hour. Although small, it would explain why the SOC can drift upwards during FD.

Rob

[gcoan]

@SwiftRR so it does appear to be operating as I thought, the plan shows Freeze Discharge for the entire slot but SoC increasing slightly, and in execution it alternates between Freeze Discharge and Idle

Which does point to an error in the display of the plan not showing the split slot arrangement correctly

I've not had any Freeze Discharge today so can't test whether it does the same, but in mine, my plans when FD was scheduled didn't show SoC increasing at all.

Rob, do you have 'calculate discharge on charge slots' on? Wondered if that was a difference? Mine is off

[SwiftRR]

Yes:

It is the default.

Snapshot of my status. Not every hour but Predbat has chosen a recurring time slot: