not respecting Min Improvement Discharge

[Boffinboy]

Describe the bug V11 does not respect the Min Improvement Discharge, running discharge slots when he gain is below the threshold

See image comparison of v11 vs v10 with same Min Improvement Setting (in my case, 18, as I only want to for major gains i.e. DFS, or when electricity is negative). v10 does not discharge, v11 does charge and discharges that it should not

[gcoan]

I had reported #861 about problems with min improvement discharge not being taken account of properly, lots of cases where battery was discharged only to then need to grid import later on at a higher effective rate.

At the moment the agile rates are so low that I can't meaningfully see whether the same issue is occurring with 7.16.11. At the moment it appears to be charging and discharging appropriately for profit for me (something it wasn't doing before on 7.16.10)

Do you have charge on discharge slots turned on? I have it turned off to avoid excessive battery cycling when import rates are low. Might be worth turning it off for you (if it's on)?

[Boffinboy]

I do have charge on discharge enabled. That should not matter though, I had a min discharge improvement of 18p in both pictures…. If it’s meant to apply per discharge or per 30 min slot (stated v10 and v11 logic respectively) then the discharges should not be happening that 7.16.11 seems to have introduced. Seems like the v11 fix has broken something. For now I’ve rolled back to 10

re: your issue, it does seem like a difference between optimising a slot, vs optimising the whole plan

[mpartington]

Same problem I think (or a variation). I've got the min discharge improvement set to 5p, but it is planning a charge, followed by discharge for a very small profit (less than a penny/kWh) V7.16.11

[mpartington]

And rolling back to v7.16.10 produces a better looking plan with much less import in the 19.00 slot (not really sure why it needs any)

[gcoan]

Same problem I think (or a variation). I've got the min discharge improvement set to 5p, but it is planning a charge, followed by discharge for a very small profit (less than a penny/kWh) V7.16.11

@mpartington I think yours is actually working correctly to spec.

Predbat is importing at 12.17p/kWh effective price for a total of 12p of import

Then exporting at 13.04p/kWh effective price for a total of 20p of export

The min discharge improvement is (from 7.16.11) calculated on the total amount of improvement over the slot

20p-12p = 8p profit, above your 5p threshold

My own predbat isn't importing at all in the 19:00 slot; the change in weather, more sun and turned the ASHP off two days ago, we've just gone through the evening peak and the battery is almost completely full still - home demand was still supplied from solar 👍

I'll need to think what to change my own min discharge improvement to, but at the moment its working much better than 7.16.10

[mpartington]

@gcoan Not sure I completely follow that logic. On the top screenshot I am importing at 12.17, which is costing me 12p (so must be importing around 1kWh).

I then sell it back for 13.04p, so a grand profit of 0.87p per kWh imported then exported at those prices. The 20p profit could equally have been made by just discharging what was in the battery. It seems it doesn't have a value for the cost of energy in the battery, maybe it's just averaged

The need to import at all is at best marginal, maybe I need to change the import metric instead (currently 0)?

V7.16.10 subsequently updated again to remove any export in that slot, which seemed the best strategy

[mpartington]

Also see what you think turning calculate secondary order slots off. It's meant to push discharge later in the day and closer to.next charge period (Trefor confirmed current strategy on a flat export tariff is to discharge on the highest import cost slots, to leave the lower ones free, which explains why it's always during the peak.period).

I've only created one plan before the low rates.took.over, but it seemed to be less profitable and still didnt seem to choose all the latest slots to export

[gcoan]

I then sell it back for 13.04p, so a grand profit of 0.87p per kWh imported then exported at those prices. The 20p profit could equally have been made by just discharging what was in the battery. It seems it doesn't have a value for the cost of energy in the battery, maybe it's just averaged

I don't have all the answers! Was principally playing back how I understood the new release to work which is working on profit on the slot rather than profit on each charge/discharge. Since the evaluation isn't on per charge/discharge now, looking at profit per kWh isn't as relevant any more. As you said roughly 1kWh is being imported but then approx 1.5kWh is being exported which is part of how predbat gets to the 20p profit for 12p import (and you can see the SoC drops over the two slots).

Predbat does I believe assign a value to stored SoC based I assume on some form of weighted rolling average price. Solar charging at zero cost or the export price? Don't know.

But how this stored SoC value gets included in the metric_min_discharge_improvement calculation, I also don't know. Would need @springfall2008 's advice !

One consequence of the change of approach to metric_min_discharge_improvement is that we may need to increase its value, but as I had previously reported in #861, I didn't think it was working holistically over the plan, I was seeing lots of examples of exporting at 13.5p after losses only to have to import later on at a higher rate.

The need to import at all is at best marginal, maybe I need to change the import metric instead (currently 0)?

Yes agree I don't know why that import was done. I would personally avoid using matric_battery_cycle_cost as this puts a drag on using the battery and the whole idea should be that the battery is used when its profitable to do so.

Also see what you think turning calculate secondary order slots off. It's meant to push discharge later in the day and closer to.next charge period (Trefor confirmed current strategy on a flat export tariff is to discharge on the highest import cost slots, to leave the lower ones free, which explains why it's always during the peak.period).

Calculate secondary order slots is so new its not even in the documentation yet!

I tried changing it, the plan for tonight was entirely unchanged. Tommorrow's plan with calculate secondary order on:

And with it off:

Its near identical in activity, and total cost for the plan period almost the same.

I didn't know that predbat's strategy on a flat export tariff is to discharge on the highest import cost slots. It's not clear that I have seen in the documentation that this is how it works, but it does explain a lot of the angst I had with predbat on 7.16.10 before the rates dropped of late.

I have set an export price adjustment of -5 in the peak and actually slightly before and after the peak to (a) avoid peak discharges for DFS and (b) to preserve my SoC for later.

A lot of the time I was seeing discharging immediately before or after the peak period which goes against (b), preserving the SoC in case of unexpected additional load. I found myself having to add Force Idle commands in to stop predbat discharging what I saw as unnecessarily

Maybe when the rates get back to normal I'll be able to see more the impact of the new calculate secondary order slots

[mpartington]

Maybe when the rates get back to normal I'll be able to see more the impact of the new calculate secondary order slots

Yes, it's very much a beta, Trefor sent it to me Saturday morning, so not much chance to test before the rates went crazy. I was a bit surprised to see it included in v7.16.11.

It's worth confirming calculate secondary order slots = on is as per the existing method. Need to turn this off to test the new experimental mode.

With it off, I'm sometimes seeing more import on higher rate slots (maybe the very low rates are impacting), so not sure it's the finished article yet, but the more people who test the better

[mpartington]

I've looked at 4 combinations metric_min_discharge_improvement set to 0.1 and 2 and calculate secondary order slots = on or off. Using the current method (calculate secondary order slots = on ), the value at the end of the day ends up very similar for both metrics.

However under the new method that is meant to push discharge later ((calculate secondary order slots = off), the amount of discharge is massively restricted in both cases in comparison and the battery ends up being much fuller at the end of the day. Interesting what happens once tomorrows rates are known and if this changes.

Interesting that metric_min_discharge_improvement also seems to affect if the ((calculate secondary order slots = off )plan will predominantly hold charge, or allow a steady discharge over the course of the day. It seems to affect home usage as well as forced export Higher values seem to give a higher final battery SoC, which makes some sense. The question being, why isn't the same behaviour seen with calculate secondary order slots = on. Here the battery is run down to similar levels. Coming back to the original OP, I wonder if this is relevant...

Really could so with an export plan option, it's a pain to cut and paste them together

EDIT... Not sure how much you can read into this as they change all the time. I think I'm going to trial for a few days: calculate secondary order slots = off metric_min_discharge_improvement = 0.1

[gcoan]

I just had a look at my own plan, metric_min_improvement_discharge is set to 0.2 from before and I had accidentally left calculate secondary order OFF

Turning it back ON, the plan looks the same activities but the discharging planned for 11:00 and 11:30 is deeper with secondary order ON

On the face of it, the plan looks more profitable with secondary order ON, but given that the cost today for the current slot improved by 4p for two runs of predbat only a couple of minutes apart, it doesn't look like the switch really had much financial improvement either way.

I probably won't be able to see any long term benefits or not of this switch as the inverter with my 9.5 battery on it stopped talking to the battery on Thursday. Waiting for GE to decide that they need to replace it (which seems to be the fix according to others that have the same issue on the community forum). So I only have the single 5.2kW 80%DoD battery which is really only enough to get me through the evening peak. I've also turned the ASHP off a couple of days ago and so its consumption is still reflected in the load history/prediction. Will take until later in the week to come out of the data.

[mpartington]

I probably won't be able to see any long term benefits or not of this switch as the inverter with my 9.5 battery on it stopped talking to the battery on Thursday.

Argh, thats a pain, sorry to hear that!

I think what I've learnt today is to ignore the initial plans. Mine (secondary order OFF) has decided it wanted to hold charge for most of the day after all (which did make sense as rates were ~15p). It's changed its mind multiple times and is now planning a discharge at 2 am, which to be fair is exactly what I asked Trefor to code (make it as late as possible). It does make it a bit harder to compare, but it does discharge down to 13% by 3.30 am (and start of cheapest rates). So I do think it's doing what is says on the tin. It still feel a little less aggressive on discharge, but maybe that's OK.

What its doing next seems largely sensible

Not so much tomorrow afternoon, but I expect this will change. I would be discharging deeper earlier, to ensure max charge on the 2 cheapest slots, rather than discharge

[gcoan]

A quick update from me.

Now that the ASHP is off the 5.2 battery and the later is proving enough to last through the agile peak.

Predbat started a discharge at 20:00 which I Wouk prefer it didn't do as it then risks soc running out whilst the rates are around 14p, more than the effective export rate

Turned secondary order OFF and the charge was removed and instead discharge now planned for just after midnight which is much preferable

[Boffinboy]

Can someone else try putting theirs really high instead of marginal numbers and see what happens? Mine was 18p so there should no way have been import-exports in the 30 minutes slots shown in my screenshots (which delivered 1 or 2 p benefit). There is something clearly wrong with the implementation in 7.16.11 based on my screenshots, but perhaps it only becomes evident when the value is set very high.

[gcoan]

Here's my current plan with metric min discharge set to 0.2

the charge and discharge at 22:00, shouldn't be happening as effective import rate is actually slightly higher than effective discharge rate

I then progressively tried different min discharge values:

setting it to 10p, I get a discharge at 02:00 that only shows 2p income?

setting to 5p, discharges of 9p and 2p profit (the second one the SoC gets to 4% minimum so maybe that's understandable ??)

setting to 3p, the discharges are all around 10p profit

[Boffinboy]

Thank you for doing that. Very strange behaviour, as in a number of scenario they don’t exceed the threshold you’ve set. It’s worse at the higher threshold. Hopefully Trefor sees this and can investigate.

[gcoan]

Yes there is definitely some form of correlation between metric min discharge improvement and which slots are chosen for discharge, but it doesn't appear to be working "as described"

[SwiftRR]

Here's my snapshots for metric min discharge at 0.1p and 0.2p. Both with secondary order switch set to OFF.

Tried several times but 0.1p produces best cost outcome for me

Rob

[Boffinboy]

Am still seeing same behaviour in latest version 7.22.3 I have Metric min improvement discharge set to 18 and am getting discharges that do not exceed 18 either for the slot, or for the entire period. It seems likely the calculation is going wrong.