Not taking account of metric_min_improvement_discharge as I'd expect it to do

[gcoan]

Describe the bug As can be seen in this plan Predbat is planning to force discharge for export at 13.68p after losses.

By the 21:30 and 22:00 slots the battery is exhausted leading to grid import at 13.89 and 13.67

It would be better to keep the battery charge in this and the later discharge slots.

metric_min_improvement_discharge was set to 0.2, I've increased it to 0.3 and this is the resultant plan

Expected behavior Only discharge when it is clearly profitable to do so and future imports are not more expensive.

Predbat version 7.16.7

Environment details HAOS Gen 1 hybrid x2 9.5 & 5.2 batteries

Log file Can you capture a log file from the time of the issue, debug mode is not normally required. If you are not keeping the full logs then please enable this in appdaemon.yaml (see the installation instruction in the Predbat docs area for details on how to do this)

[gcoan]

There's something more here, the valuation of discharging isn't being optimised correctly.

I left predbat in read only up to the peak to stop the unprofitable discharge

In the peak, inverter on idle, two discharges planned for immediately after the peak. The midnight cost (with battery empty) is £1.72

As I progressively force idle the slots predbat wants to discharge in

19:00, 19:30 and 20:00 force idle. Cost at midnight decreases to £1.63

20:30 force idle cost is £1.61

21:30 force idle cost is £1.55

[springfall2008]

Here's mine with calculate charge only:

And then again with calculate charge/discharge:

[gcoan]

yours looks as I would expect it to do, but the battery isn't getting exhausted and so the comparison of future grid import vs discharge isn't occurring - which is where I suspect the bug might be

Here's what my plan looked like with the Force Idle's still in place:

when I cancel the Force idle's, the plan changes to include two discharges, but when I look at the figures in detail, its discharging at an assumed 13.68p export rate to then have to grid import at 13.89 and 13.67 when the battery is empty.

This plan is 1p more expensive than my force idle plan which is neither here nor there, but with the metric_min_improvement_discharge set to 0.3, I wouldn't expect it to discharge as much?

And as I showed on the earlier comment, by adding more Force Idle's I was able to get the plan to improve on what Predbat had planned.

I have calculate region optimisation on, but tweak second pass, calculate plan faster both off.

Do you want the log file?

[springfall2008]

Could you re-test on 'main' for me?

[springfall2008]

Released here for now, this change removes part of the discharge freeze change which appears to have triggered this: https://github.com/springfall2008/batpred/releases/tag/v7.16.8

[gcoan]

I put the new 7.16.8 version in, didn't see the main version beforehand

Tbh looks the same

7.16.7

7.16.8

Still discharging to have to import soon after

[DJBenson]

@gcoan how are you getting that sexy looking plan card?

EDIT: found it 😀 https://github.com/pacemaker82/PredBat-Table-Card

[gcoan]

@gcoan how are you getting that sexy looking plan card?

EDIT: found it 😀 https://github.com/pacemaker82/PredBat-Table-Card

yep that's it

[gcoan]

Looking at the plan today, similar story after the peak period Predbat plans a force discharge at 19:00 for 13.68p effective rate only to then be needing to grid import at 21:00 at 14.29p and then 22:00 at 14.77p.

Maybe the battery would have been exhausted anyway by 22:00 but the import at 21:00 would have been avoided if the discharge hadn't happened

The above screenshot was taken at 13:01. As I finish typing this its now 13:09 and the plan has changed, the discharge now being at 19:30, but still same effect

[gcoan]

I had set 19:30 to force idle and the plan is now showing 19:00 as a force discharge, with same problem, the battery becomes exhausted and has to then grid import later on at higher rates than being achieved for the export

[gcoan]

Hi @springfall2008 any further thoughts on this?

Did it again today, discharging at an effective rate of 13.68p only to then run out of stored charge leading to import at 15:04

The battery charge should be held when future slots are more expensive to import than I get from the export

[mpartington]

Think there is definitely something amiss here. Mine just discharged down to 50%, then charged up at 14.2p in order to discharge again at 15 p (all.before.losses). I've also set metric discharge to 3p.

Edit.. Mine maybe related to 1 battery not reporting capacity.

[gcoan]

I've still got my min discharge improvement set to 0.3 and am still getting discharges both before the afternoon peak and afterwards that cause the predicted soc to drop to empty early in the evening and grid imports at more than the export rate.

I keep having to put force idle in to stop this happening and preserve the soc to the point where import rate is less than export. Happens most days

[mpartington]

I'm sure Trefor told me (albeit a long time ago) that the metric controls the profit in the slot, so if for example slots were combined then it would be the same for 30 mins as it would be for 5 hours. When I was on GO, I had to use much larger values to force it to charge to 100%.

Mine was set to 5p and it discharged all the way down to 20%, at which my battery has crashed to zero and I'm running on grid (latest beta firmware as well 🙄, was only installed this afternoon to be fair)

Edit... If I understand it correctly, doesn't a 0.3p metric mean it will discharge the battery if it can turn a profit of (just) 0.3p? I've now got mine set to 5

On Tue, 2 Apr 2024, 20:25 Geoffrey Coan, @.***> wrote:

I've still got my min discharge improvement set to 0.3 and am still getting discharges both before the afternoon peak and afterwards that cause the predicted soc to drop to empty early in the evening and grid imports at more than the export rate.

I keep having to put force idle in to stop this happening and preserve the soc to the point where import rate is less than export. Happens most days

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/861#issuecomment-2032931516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZQHXHM4ZOQAFP7A23DEFQLY3MAZVAVCNFSM6AAAAABE2KCB22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZSHEZTCNJRGY . You are receiving this because you commented.Message ID: @.***>

[gcoan]

That's interesting @mpartington, at the moment there's no reference to min improvement being over the combined slot in the docs (and I can add it if its confirmed), but it doesn't explain my behaviour.

I have combined charge slots and combine discharge slots both turned off so any profitability should be evaluated on a slot by slot basis. The predbat default for metric min improvement discharge is 0.1 to only discharge when there's a real profit, and at the moment mine is actually set to 0.2p (but has been set to higher figures), but set to 0.2 I should only be getting a discharge if its at least 0.2p better than the import rate.

But that is not happening.

I have an idea that metric_min_improvement_discharge is only evaluating whether its beneficial to discharge or not for each individual slot, not looking at the impact of that discharging on exhausing the battery earlier and thus causing grid import.

The screen shots I provided earlier show this behaviour. I can override the predbat plan and force idle slots that it is planning discharge in and end up with a more profitable plan than predbat has produced by default. Which goes against the whole purpose of predbat!

Also worth highlighting that with a flat rate 15p export plan there's no benefit to early exporting, particularly before the peak period. I have put a rate override in from 3pm-8pm but still find the plan runs the battery down before the peak and discharges soon afterwards.

Tomorrow's plan is not bad (compared to others I've posted on this issue) but starts discharging at 20:00 and runs the battery out in the 21:00 slot at 14.42p. With an effective export rate of 13.68p I would expect it'll be better to hold the charge and not start discharging until 20:30 so that I don't import at all in the 21:00 slot.

[mpartington]

The early exporting, either before or at the start of the peak period is something I get as well. If I see it, I also force an idle as agreed there is no benefit in exporting before the last possible moment, only more risk. This definitely seems an issue that needs a level of code tweaking/fixes.

This was from a discussion last September, but of course Predbat evolves fast...

[gcoan]

That was specifically about metric_min_improvement which I have set to the default of zero. It does mention multiple charge periods in a window but maybe needs to be more explicit. But I'm not using that

https://springfall2008.github.io/batpred/customisation/#battery-margins-and-metrics-options

Think it does need a code tweak

[mpartington]

I was assuming that the discharge metric was using similar logic, but could be wrong.

Just to add a similar observation on my system... Predbat is happy to (assuming losses) hold charge at over 19p then discharge it later for 13p

[dandwhelan]

I've found the same with.. 16.10 and 12

[springfall2008]

Closing this old ticket, please open a new one if you have an up to date question