Eliminating the 15m charge/Export slots

[pacemaker82]

Describe the bug

I am trying to reduce or remove the 15m charge/export slots in the plan to 30m increments of charge or export (I presume it will also reduce writes to register too).

I've switched switch.predbat_calculate_export_oncharge off, but this gives me a plan that has eliminated all exporting:

Interestingly, if I change the plan generation to 24 hours only, it shows a big export straight after charging (assume thats some kind of defect with the plan on 24 hours as no idea why you would export in the morning like that)

Expected behaviour
I want the plan to change the 15m charge/export to a 30m charge, then a 30m export, then a 30m charge etc..

Predbat version

8.11.2

Environment details

• AC3 w/ 9.5 kWh battery
• HA GREEN
• Anything else?

[gcoan]

Expected behaviour
I want the plan to change the 15m charge/export to a 30m charge, then a 30m export, then a 30m charge etc..

The most efficient plan would be a long charge, then a long discharge then a long charge finishing at the end of the cheap rate period with the battery at 100%

'long' is relative but basically to reduce inverter writes you don't want to be swapping between charging every 15 or every 30 minutes, just as few times as possible overnight

[pacemaker82]

yep agree - if there is a 2.5 hour window to play with as there is in my current plan, I would expect a big chunk of charge, a big chunk of export. I dont mind having one 15/15 split but having them consistently for 2.5 hours seems an odd choice.

[gcoan]

have you got combine charge slots on?

[pacemaker82]

Yes I do. Just looked at my plan and its now decided to do this, which is "closer" to what I expected. This is with switch.predbat_combine_charge_slots ON and switch.predbat_calculate_export_oncharge ON

Changing switch.predbat_calculate_export_oncharge to OFF gives me this:

[gcoan]

have you tried turning combine charge slots off, this is giving the long charge block and maybe preventing the exporting happening

[pacemaker82]

With both turned on I have this:

If I then remove the switch.predbat_combine_charge_slots I get this

Turning both off I get this:

[pacemaker82]

strangely with having them both turned ON (with 24 hour plan in YAML), its planning to do a full export until the cheap window closes, also the day ends at 5.30am not at 24 hours. If I turn off switch.predbat_combine_charge_slots I get a full 24 hours plan and a less ridiculous plan.

[johnwb87]

I also dislike predbats tendency towards this oscillatory behaviour. I use a little bit of Metric Battery Cycle Cost to help tune some of this out. Start with 0.5 and see if it makes much difference.

[cyberkryten]

I've also noticed some odd plan durations when I was playing about with the charge slots - never really figured out why but I'll try and have another look.

If you have 3 hours after you have hit max battery then it doesn't really make a difference if it does 15min on/off repeatedy or a single 90min on/off in terms of the end result, however Predbat will achieve a (slightly) more accurate discharge on the smaller slots because it is adjusting, so any unexpected load (eg heating system kicking in) will be accounted for quickly which is, I suspect, why the default is the short slots.

Another advantage is that if there is a power outage, going 100>90% three times means the minimum battery level is 90% whereas 100>70% once means you could be left with 70%

However, I don't think charging to 100% is most efficient as the last few % are often slower - I've tried adjusting the battery curve but that doesn't seem to stop it - it would make sense for it to go from wherever the battery curve is <1 but it doesn't seem to do that (I was expecting it to shift to 95>85%).

Inverter writes is another good reason to do the bigger slots with fewer changes - lots of tradeoffs!

[cyberkryten]

OK, so I tested again. The only difference between the 13:45 plan and the 13:55 plan is that I had changed both predbat_combine_charge_slots and predbat_combine_export_slots to be set to True.

Firstly, why does that change the end time of the calculations? I've noticed this before but surely that doesn't make sense and suggests there's a bug somewhere.

Also, why does that stop Predbat from exporting from 16:30 to 20:00? On the original, it starts that period at 99% and plans to export for the entire four hours getting down to 9%

Once the combine_slots are changed to True, it abandons that plan and for some reason only intends to export briefly, starting the next cheap rate period at 20:30 with 47% battery.

The upshot is that when arriving at 08:00 tomorrow, the yo-yo charge/discharge cycle has a 'cost' of £2.57 but due to less planned export the combined plan has a 'cost' of £3.56. I'd like to combine the slots but the plan is far more expensive when doing so.

Combine False:

Combine True:

[johnwb87]

Regarding calculations. It is somewhere in the documentation and Trevor mentions it occasionally. The plan is only fully calculated up to a few planned charges ahead. So if it schedules several charges then the accurate plan doesn’t go as far into the future.

On your wider point a good place to be on IOG import and fixed export is combine charge=true and combine export = false.

As far as price the combine plan looks expensive because it isn’t exporting before the cheap rate starts. Potentially a symptom of combine export slots. Or perhaps just my next point;

I also find that generally two runs of the plan are needed to see something sensible after a setting change is made.

[cyberkryten]

I've been struggling to figure out how it works and which settings are best. Whilst the actual figures are wrong on my system (due to ad-hoc IOG slots disappearing) the comparison is all I have when changing the parameters. That does make it hard to compare changes later in the day as the total never matches the plan because of that issue.

Having both = false should be more accurate but only because the in-day adjustments are more frequent and granular to account for solar/load differences. I don't really understand why the planned figures differ so much.

With a given load and solar forecast and unchanged IOG hours, the amount of import/export should be very close between the combined and not combined as the amount of import/export planned will be the same, just divided up differently, so I was expecting the cost to be similar. The plan hasn't changed much after more/longer runs, unless you mean enabling predbat_calculate_second_pass is required?

If I put combine_export back to false, then I again get lots of charge/discharge cycles overnight - this has two issues:

a) lots more register writes (unclear on SE but better safe than sorry)
b) The Battery is going 100>90>100 a lot and the last few % charge slower and so it isn't as efficient doing that three times as it is doing 100>70>100

[PianSom]

I am on IOG (with an AIO) and have been since Dec 23. I started using Predbat about a week after starting with the tariff, so now have more than a year of trying to get Predbat to work the way I want it to - so far without success. I almost never use IOG's "Bonus" charging slots.

At the start I went with Trefor's defaults, though after a few months decided that the very frequent changes between charging and discharging could not be at all healthy. More recently, I have settled on using the defaults, other than

• switch.predbat_calculate_export_oncharge - TRUE
• switch.predbat_calculate_export_high_import - TRUE
• switch.predbat_combine_charge_slots - TRUE
• switch.predbat_combine_export_slots - TRUE

I pretty much always end up with an overnight plan like this -

This is close to what I want - I want to minimise costs while avoiding extensive battery directional switching. But there seems to be nothing I can do to stop Predbat doing the "23:30-00:00" shuffle - a 15 min charge then discharge. Perhaps there is something hard-coded which makes midnight "special" within Predbat? Perhaps it is the way the Octopus integration returns the tariff? I have no idea, and have not managed to get Trefor to engage.

[gcoan]

there seems to be nothing I can do to stop Predbat doing the "23:30-00:00" shuffle

I know its not letting Predbat handle it all automatically, but what if you set a force charge at 23:00 every night?

I used to have a similar behaviour of Predbat doing a 3pm discharge that I stopped with the following automation:

alias: "Predbat: stop 3pm discharge"
description: ""
mode: single
triggers:
  - at: "23:00:00"
    trigger: time
actions:
  - data:
      option: "15:00:00"
    target:
      entity_id:
        - select.predbat_manual_idle
    action: select.select_option
  - delay:
      minutes: 1
  - data:
      option: "15:30:00"
    target:
      entity_id: select.predbat_manual_idle
    action: select.select_option

[cyberkryten]

I'm looking at this again today and trying to break it down, changing one flag at a time to figure out what the combine flag is doing. Looking at Export alone, there's definitely something wrong with the way Predbat is calculating export slots when I set it to combine them as it moves them far too early in the day.

For some reason has put the evening export at 17:00 to 20:00 - I don't understand why it has moved that export slot so that it finishes three hours before the cheap rate starts. That makes no sense, because any increased load in the evening will cause grid import during the high rate period - I think that's probably why I'm seeing issues with the final costs.

Something about combine_export_slots is moving that export away from the end of the period which is not correct as it should be at the end (which will move through the evening depending on load) but this way there's no way to adjust as the export will happen far too early.

Having gone through the code, does anyone know why the export slots are hard limited to 4 hours? It seems like that could cause issues when they are combined for me - I have 29kWh of batteries and a 3.68kW export limit, so could, in theory export for almost 8 hours during the summer

                    if find_high and (rate_low_start >= 0) and ((minute - rate_low_start) >= 60 * 4):
                        # Export slot can never be bigger than 4 hours
                        rate_low_end = minute
                        break 

Combine Export OFF:

Combine Export ON:

[cyberkryten]

I decided to change the code to increase the export slot limit to 8 hours and thought that might fix the early slot issue but it actually made it worse!

Having changed that, it moved the slot to begin four hours earlier at 13:30, but that does mean there is 8 hours between the end of the slot and the rate change.

Odd.

Being curious, I changed it to 2 hours and that then move it to start at 19:00, ending two hours before the rate change.
One hour and it moved to 20:00 ending an hour before.

But, the comment suggests that the intent is to limit the overall duration of an export slot - this is now set to two hours, but the slot is still the same length of 3 hours that it always was, so this hardcoded limiting is not affecting the slot length but merely it's positioning within the possible export windows.

Setting it below the other hardcoded value that is used in the calculations self.export_slot_split = 30 means no export at all is generated in the plan.

I don't think it is working as intended but can't quite figure out how to change things so it does.