PredBat Discharge seems to favour earlier discharge slot, rather than most cost effective.

[Geheee]

Describe the bug I have noticed recently that PredBat seems to favour an earlier discharge slot, even when a higher paying slot is available later in the day.

Specifically, once the surge pricing begins at 4pm, PredBat will schedule this for discharge, at the expense at more lucrative slots say at 5 or 6pm (See Screenshot)

Expected behavior

I would expect predbat to schedule discharging for the highest paying timeslots

Predbat version

7.16.5 (and earlier. not quite sure then this started)

Environment details

GivEnergy Hybrid Inverter and 9.5kW battery HAOS on RPI Octopus Energy Agile for both Ingress and Export

Screenshots

Log file log.txt

[springfall2008]

Any chance you could try 7.16.3 and see if its any different in case it was a bug recently introduced?

[Geheee]

Hi Trefor, thanks for looking at this,

I've downgraded via HACS to 7.16.3, but the plan looks very similar, and is still showing a preference for earlier discharge slots at lower rates (in this instance it seems to want to discharge at 17:30 rather than wait until the higher price at 18:00

I've attached two runs as close as I could get together with both 16.5 and 16.3

Hope it helps...

7.16.5 16.5.txt

7.16.3 16.3.txt

[Geheee]

And no real difference on 16.1 16.1.txt

[Geheee]

More bisecting...

15.21 - not working 15.21.txt

15.12 - working 15.12.txt

[Geheee]

And back to 16.5 to check that it's not something that's changed the plan due to external events...

16.5_2.txt

[springfall2008]

Do you have expert mode enabled and if so is 'fast mode' turned on? (if it is then that could cause it)?

Can you try with calculate second pass turned off?

Also can you get a full log, all the ones above are clipped and don't include a full calculation cycle?

[Geheee]

Hi Trefor,

I did have "fast mode" turned on, but have now turned it off.

I have attached a log based on v7.16.8 (hopefully this isn't truncated now) appdaemon.log

The first few runs have "second pass on", and the last few runs (after 11:35am) have it turned off.

It doesn't seem to have changed the behaviour that much, it's hard to say, but it still seems to favour the very first peak discharge slot, for example:

2024-03-18 12:00:16.950021 INFO pred_bat: Best discharge window [ 18-03 16:00:00 - 18-03 16:30:00 @ 12.91p 99%, 18-03 18:00:00 - 18-03 18:30:00 @ 16.14p 58%, 19-03 18:00:00 - 19-03 18:30:00 @ 18.72p 57%, 19-03 18:35:00 - 19-03 19:00:00 @ 18.37p 40% ]

This example is only slight, as it only wants to discharge to 99%, but on occasion it's more pronounced, I'll leave it running and see if I can find a better example if useful..?

[Geheee]

If it helps, I think this is perhaps linked to the Nordpool pricing.

The plan looks reasonable before 10am, but after the Nordpool pricing comes in, it seems to favour the earlier discharge slots again

With Nordpool pricing

Without

Some before/after Nordpool data download logs from this morning Before appdaemon_before.log After appdaemon_after.log

[gcoan]

There could of course be a bug in the norddata pricing that's affecting today's forecast, but norddata is providing more accurate estimated prices from 11pm tonight and through the night (rather than just rolling over today's prices).

So we really need to see more of the plan showing the charging and load going through the rest of this evening and the night to see if there is a logical reason for the norddata pricing affecting today's plan.

If I look at my own pricing for last night, its giving overnight prices of 12, 13p peaking to 15 and then 22p at 6:30 am:

Without the norddata feed it will be assumed that tomorrow (Tuesday morning) prices will be the same as Monday morning.

With the norddata price prediction the peaks are a bit lower for Tuesday morning:

And this could be why the predbat plan changes. I've seen that small price changes or load changes can make the plan swing considerably if the profitability of one scenario is very similar to the profitability of another.

[Geheee]

The Nordpool pricing should be more accurate, correct.

But when it loads, for some reason the discharge slot jumps from the highest paying period between 4-7pm, to favouring a nearer 4pm slot, even when there are higher paying slots in just 30 mins time.

The period in question isn't in the Nordpool prediction range, it just seems like the addition of that dataset is causing the plan to favour a nearer term discharge

[gcoan]

I have a price override in my apps.yaml to dissuade predbat from exporting during the peak period - principally to improve my DFS saving session average, but I extended the rate period to 3pm as I found Predbat was often discharging just before the peak and I wanted to ensure I always have enough for the peak

  # To improve on saving sessions avoid export during peak periods
  rates_export_override:
    -  start: '15:00:00'
       end: '19:00:00'
       rate_increment: -5