Maximising Export - UK Octopus IQ GO - avoid solar recharge when able

[andyD3344]

Is your feature request related to a problem? Please describe. Overnight Cheap rate charging as expected, similarly discharging at the end of the day to reap spare capacity. However in the summer months, when load is low, solar production is high, there is no need to allow ECO to recharge the battery during the day, as enough capacity exists to last until cheap rate starts again, and the model knows that

Describe the solution you'd like Maybe treat solar export as a cost, (lost opportunity), allowing the model to freeze discharge where capacity and costs allow

Describe alternatives you've considered I have tried playing with metric cycle cost, etc to get the behaviour i am after, my best solution so far is to combine discharge slot - which results in eco mode running from 05:30 until around 18:00 - when the system force discharges for around two hours and then runs on eco again until 23:30. if i don't set combine discharge slot on - that forced discharge shifts until the period immediately prior to the cheap rate commencing - which doesn't ethically correct.

Additional context Add any other context or screenshots about the feature request here.

[springfall2008]

There is a 'metric self sufficiency' for this purpose, but keep in mind it will be more expensive than fully charging overnight.

[andyD3344]

Hi Trefor,

I thought the metric of self sufficiency would do the opposite of what I am after.

I have a daily load (during summer ) of less than 8kW. I have a usable battery capacity of 13.5kW. Dishwasher, car, Hot water and vacuum cleaner can all be charged/run during the cheap rate session overnight.

I wish to fully charge the battery (0.07p) and then run the house load from the battery during the day preventing charging and thus maximising export.

(As even with cycle losses the overnight stored electricity is cheaper than the loss of income from export )

Have I misunderstood the metric, I thought it would prevent / reduce overnight charging relying more / entirely on solar.

Andy Downs

On Thu, 1 Aug 2024, 10:41 Trefor Southwell, @.***> wrote:

There is a 'metric self sufficiency' for this purpose, but keep in mind it will be more expensive than fully charging overnight.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1337#issuecomment-2262606376, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHDVXUZFXQDDVZYI5RPGFKLZPH7EZAVCNFSM6AAAAABLZ6RY6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRSGYYDMMZXGY . You are receiving this because you authored the thread.Message ID: @.***>

[springfall2008]

If you have metric battery cycle set to 0 I would expect 100% overnight charge unless you are likely to get clipping during the day. What do you see by default? I thought you were asking to charge less at night not more.

[andyD3344]

I do get 100% charge at night. I get a period of forced discharge immediately before the cheap rate period if combine discharge is off, or at 6pm if combine discharge slots are on. I prefer the latter.

I have followed the predbat documentation and your YouTube video from December where you cover the octopus outgoing tariff.

The behaviour I am trying to get rid of, are periods of solar charge during the day that take the battery back up to 100% when it's not needed. This happens irrespective of the combine discharge slots switch position.

For example it is currently charging the battery from solar in the 14:30 slot to take it from 99 to 100. The predicted load and solar makes that unnecessary. I realise at this time of year these extra wee cycles of solar charge are small.

Our array is reasonably large I guess, we have 11.6 split over three arrays, the solar production on a sunny day is sufficient to cover our needs so the battery only drops between 05:30 and 6:30 and again after sunset (ISH). I would prefer the battery was prevented from charging unnecessarily from solar. Maybe this isn't possible?

On Thu, 1 Aug 2024, 14:10 Trefor Southwell, @.***> wrote:

If you have metric battery cycle set to 0 I would expect 100% overnight charge unless you are likely to get clipping during the day. What do you see by default? I thought you were asking to charge less at night not more.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1337#issuecomment-2263003479, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHDVXU4T4ZK6QI5MAQ5PAG3ZPIXTBAVCNFSM6AAAAABLZ6RY6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTGAYDGNBXHE . You are receiving this because you authored the thread.Message ID: @.***>

[gcoan]

Try manually setting a freeze discharge at the time slot you want predbat to stop charging but let the batteries meet house load if it exceeds solar generation?

If this does what you want you could write an automation to manually set select.predbat_freeze_discharge to the time slots you want to stop charging the battery. Run it at an appropriate time each day.

[andyD3344]

Thanks,

Yes I had already tried the manual freeze trick it worked.

I'll edit one of my old automations accordingly

On Thu, 1 Aug 2024, 15:26 Geoffrey Coan, @.***> wrote:

Try manually setting a freeze discharge at the time slot you want predbat to stop charging but let the batteries meet house load if it exceeds solar generation?

If this does what you want you could write an automation to manually set select.predbat_freeze_discharge to the time slots you want to stop charging the battery. Run it at an appropriate time each day.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1337#issuecomment-2263214266, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHDVXUYWFN7UYF5WVJKLHJTZPJAPXAVCNFSM6AAAAABLZ6RY6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTGIYTIMRWGY . You are receiving this because you authored the thread.Message ID: @.***>

[springfall2008]

I guess I don't understand why you wouldn't let predbat do the job, if you hit 100% battery then it's less charge time at night? Like you say increasing metric battery cycle should work. You could also turn off "calculate discharge during charge" to prevent exporting during the charge times

[andyD3344]

I was wanting to let predbat manage it all (and have my eye on predheat for when we turn the ASHP back on), I took from Geoffrey's comment that wasn't possible.

I had already prevented discharge during charge so the overnight charge cycling doesn't happen, so that's all good.

I'll play with the metric battery cycle to see if I can that to achieve the desired behaviour, to be honest it's only a minor annoyance, this morning it was raining early on - the battery had solar charged fully by 09:00 and then behaved all day - it only took .65kWh over three slots to get back up to 100%. I do have combine discharge slots on - that causes the forced export to happen at 6pm and then discharge to load for the rest of the evening until the cheap rate slots.

The reason for raising the issue was that I was trying to see if I was missing something from the configuration or whether what I was after was not possible.

On Thu, 1 Aug 2024, 21:01 Trefor Southwell, @.***> wrote:

I guess I don't understand why you wouldn't let predbat do the job, if you hit 100% battery then it's less charge time at night? Like you say increasing metric battery cycle should work. You could also turn off "calculate discharge during charge" to prevent exporting during the charge times

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1337#issuecomment-2263876880, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHDVXU675UFWEHQUZKOAW4DZPKH2ZAVCNFSM6AAAAABLZ6RY6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRTHA3TMOBYGA . You are receiving this because you authored the thread.Message ID: @.***>

[springfall2008]

What export rate do you have?

[andyD3344]

My rates are as follows, 22.41p import 15p export Over night cheap rate 7p

I have the octopus integration so predbat gets the info from there.

On Fri, 2 Aug 2024, 11:29 Trefor Southwell, @.***> wrote:

What export rate do you have?

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/1337#issuecomment-2265069617, or unsubscribe https://github.com/notifications/unsubscribe-auth/BHDVXU6Z5GSBOHJSOL2ML3LZPNNQBAVCNFSM6AAAAABLZ6RY6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVGA3DSNRRG4 . You are receiving this because you authored the thread.Message ID: @.***>

[springfall2008]

So in your case charging to 100% at night and exporting in the day makes the best financial sense. I also get in a little export at night sometimes.

[BenCathro]

I’m in a very similar position to Andy. Same tariff, same battery system (AIO), no configuration errors that I can see and I’m struggling to stop the battery from charging up from solar during the day. The plan knows export is 15p, and import is 7p so It should charge to full overnight and dump excess before cheap slot (even with metric battery cycle set to £0.01) but that’s not happening. I must be doing something wrong but I can’t figure it out.

From reading the docs and watching Trefor’s videos it seems like using “freeze discharge” switch might get the results I’m after but I can’t find it in the settings. The only Freeze discharge option is the “freeze discharge only” switch which I think works differently.

[gcoan]

using “freeze discharge” switch might get the results I’m after but I can’t find it in the settings

There isn't a switch for freeze discharge, its a mode that Predbat can plan for a specific half hour time slot. You can manually force Predbat to freeze discharge for a period by selecting the time from select.predbat_freeze_discharge

You can select multiple time slots (one after another), or if you want to do this every day you could write an automation that runs at say 7am to select the particular slots you want to freeze the charging in.

[BenCathro]

Thanks for the reply gcoan.

What confuses me about that is that predbat should be making things as cost efficient as possible with my current setup. The most cost efficient plan would be to export the battery at £0.15 down to my SOC Keep of 1kwh before the 23:30 6 hour £0.07 import begins. Charge it back up at £0.07, rinse and repeat.

It shouldn't need overriding with automations as Trefor mentioned further up the thread. There may be some configuration mistake I've made and I'll keep tweaking to see if ai can solve it.

Trefor might have been using a beta build when he filmed this video as he specifically talks about enabling the set discharge freeze switch to get the result I'm after.

[gcoan]

Looks like Set Discharge Freeze doesn't exist as an option any more in my Predbat. Trefor has been reducing the number of option settings where the logic was in the main code.

There is 'switch.predbat_set_discharge_freeze_only'

Can you share what your current plan is and current config so we can see where the issue might be?

[BenCathro]

I really appreciate you taking the time to help.

I've been reviewing my config, experimenting to try and figure out my issue and I've solved one part of it. I'd missed a zero on my inverter_limit when I transition from App Daemon to Add On Install. 1200 instead of 12000. That's why the battery was only dumping a portion of capacity before the cheap slot.

Now I'm left trying to figure out how to configure the system to export all of the solar instead of putting the energy through the battery, losing a percentage to inverter losses, before exporting to the grid at the end of the day. I would assume Predbat would do this if it was cost beneficial but I don't have an understanding of the logic yet.

Info for understanding my config and plan: Battery: AIO with Gateway Solar: 6.0KW Panels and Inverter Tarif: Intelligent Go Goal: Charge Battery during cheap slots, run house on battery during expensive slots, export all Solar.

Here's my dashboard config and resulting plan in screenshots. Let me know if there's a better way to share it here. You can see first thing that the battery is being topped up by the solar. This top up is not required for my forecasted load and seems cost inefficient.

(I'm also getting confusing charge limits during the cheap slot due to having an Ohme Charger and having to use the Ohme integration to get things to work properly for intelligent go active slot detections. That's a separate issue though that I'm still trying to self diagnose.)

[BenCathro]

@gcoan - My assumption is that the goal myself and the Original Poster are after is not currently possible with the way PredBat is coded. I've seen this question posted in a few places by different people while I've been searching for an answer and there hasn't been a solid answer.

This kind of makes sense as the main point of Predbat is to forecast load and solar for charging/discharging the battery and not just exporting everything.

Would it be worth putting in a request for a switch to export all solar when it's not predicted to be required? With our tariff setup it is the most cost efficient method. I guess the switch could be set to only appear when Tariff export >20% import and battery capacity > average daily load during expensive slot.

That way Predbat would just operate the battery import/export, stop the battery exporting during bonus IOG slots and allow configuration for Octopus sessions.

[gcoan]

@BenCathro I've looked at your settings and they all look reasonable.

A potential theory for why you are not getting the behaviour you want from Predbat is that it is charging the battery up to 100% because it thinks you will need it in the future, and thus its best to charge it up rather than export it.

You might try increasing input_number.predbat_forecast_plan_hours from the default 24 hours to 36 or 48 so that Predbat has a longer view forward and thus (based on your projected load and solar generation) it can decide it doesn't need to fill the battery up.

Could you post before and after views of the predbat plan to see if this gives a better result?

[mpartington]

Just to add I've also seen this regularly, where it would be more cost effective to pause the battery charge via solar and just export the excess solar, as there is already sufficient soc to even cover the best10 scenario.

I have tried every combination of settings I can think of (and I like to think I have a mature understanding) without success. I don't think I've ever seen a freeze discharge in my plan. I assume it's code related and the optimisation engine isn't quite right for this aspect. If I can be bothered I sometimes set a manually forced discharge freeze