Potential optimisations around planned export to minimise writes

[mpartington]

Firstly thank you for all the work you have done already in this area following the STTG video. I've noticed that the major contributor to writes is now the forced export at the end of my plan .prior to charging up on the cheap rate. It feels like this is an opportunity for further improvement and I wanted to share my thoughts based on observations.

Last night it required 23 write requests to discharge what remained in my battery, which seemed excessive. Ironically this did include my automation halting a spurious calibration at 23:10 (said to be triggered by too many writes 🥴)

I noticed the following contributors:

• Despite having calculate secondary order off, the discharge slots were not planned concurrently (Obviously this means Predbat needs to switch between modes)
• The finish time was pushed back every 30 mins, rather than just specifying the end slot of the total discharge period
• The reserve was frequently changed, rather than setting the final value
• GivTCP seems to be recording multiple writes for the same command, is Predbat making too many requests?

My thoughts for improvements

• Ensure discharge slots do not split, are as late as possible and are always concurrent when calculate secondary order is off (possible bug as I thought this was the intention)
• Auto combine 30 min slots.(As you have done with charge), at the moment the end time is changed every 30 mins - just use final time.
• Could a discharge period covering the whole day (e.g. 00.00.01 to 00.00.00) be set and then only the 'enable discharge schedule' toggle be turned on / off as needed
• Maybe feature to finish within a +/- X minute time window would allow it to schedule with more flexibility, without needing to frequently stop/start to hit an exact finish time (similar to the change on low power mode to finish early).
  • You wouldn't want this on Agile, but on IOG, I don't care so much if discharge continues into the cheap slot (so long as no car charge is scheduled). I can schedule high drain appliances accordingly avoiding the first 30 mins.
  • Now I realise this could also be due to having an incorrect discharge rate modelled, but my calibration chart looks ok
• Set the reserve as the final target value, rather than changing potentially every run
• We've had a previous conversation, where it was confirmed it is necessary to enable reserve to support some of the Pause/Hold functions, has this/could this be decoupled? The new Pause function doesn't need it

Not saying any of this is necessarily possible, but wanted to spark discussion

Logs from the period
write_log_inv_1.log

predbat1.log

[mpartington]

Slot scheduling with Secondary order off (it did enact this). I would expect no break to have been planned.

[mpartington]

Example of the slot times being changed and the reserve values. Additionally, why are the commands being repeated multiple times? Is this causing multiple writes, or just a recording issue

[mpartington]

Definite bug with calculate second order slots turned off. Had 2 short and unnecessary discharges, where it should all be at the end of my peak period (second one included in log)

predbat.log

[springfall2008]

Interesting I made a fix on 'main' for just these cases this morning, can you give it a try?

[mpartington]

Interesting I made a fix on 'main' for just these cases this morning, can you give it a try?

Will do. I've noticed it still wants to split my discharge slots with secondary order either on or off (makes no difference).

However if I change SOC Keep from 0.5 to 0.4, it combines them. Any idea what's going on there?

Edit, setting to 0.6 also seems to work, but gives just half a slot

[mpartington]

Feedback on main (version 03-Dec)

Firstly despite fiddling with SOC keep, I ended up with split discharge times rather than on continuous block. I ended up adding a manual forced export from 23:30 until 01.00 (to give soc time to settle at empty)

I don't really understand why the GivTCP logs are different (do they ignore REST?), but I saw some unnecessary discharge slot setting, especially around 4am, whilst the battery should have been charging

predbat.1.log
predbat.log

[springfall2008]

Discharge fix on 'main' for testing

[mpartington]

Discharge fix on 'main' for testing

Thanks, just loaded. What's the best setting to push the discharge slots together and as late as possible?

This is calculate secondary order slots off

and on

[mpartington]

Hi @springfall2008 , I've uploaded the logs for last night as it's probably easier for you to see the writes.

It seems better, but 2 observations

1. As on the chart, the discharge is frequently started and stopped. Not sure what I can do here, I've set my discharge battery curve to 1.05 to try and get Predbat to over predict the discharge rate (and therefore be slightly behind the required rate) to avoid the need to stop, but that didn't seem to work.
2. Unsure why it is changing pause modes here, seems unnecessary
   

predbat (1).log
predbat.1 (1).log

[springfall2008]

I'm not sure that will do anything, 4: 1.05 means that you will discharge 5% faster than normal when your battery reaches 4%?

Can you change metric_battery_scaling_discharge to adjust the predicted discharge speed up/down

[mpartington]

Ah, I did wonder if it was just at 4%.

I don't think that metric exists does it?

[springfall2008]