Not charging before peak agile period draw

[gcoan]

This is such a stupid thing, but I now don't have a 9.5kW battery, only my 5.2kW.

I reconfigured apps.yaml to remove the inverter details for the inverter that had the 9.5, leaving the 5.2 inverter in place, and dropped best soc keep down from 1.5 to 0.3.

predbat recomputed the plan no issues, but the house draw meant that the battery would be exhausted before the start of the agile peak period, but predbat plan to do anything to retain the charge and prevent peak draw - such as a pre-peak charge or freeze discharge before the peak.

I tried different battery loss figures and best soc keep as this sometimes has made a difference but I couldn't get predbat to plan this "properly" so had to put predbat into read only mode, charge from 2pm to 4pm, then put predbat back into managing the inverter/battery. At first the plan for tomorrow's battery activity was to do a pre-peak charge so I thought this was a one-off, but now that tomorrow's rates are available, predbat is again not predicting to charge the battery sufficiently to run me at least most of the way through the peak draw. I know that historical load of ~ 1-1.4kW every slot over the 3 hour peak indicates I will exhaust the 5.2 before the end of the peak, but to my mind charging at 20/21p before the peak rather than drawing from the grid at 36/38/40p has to be preferable.

Here's the plan extract and the logfile:

appdaemon (12).log

Running expert mode, 7.13.1, old version of appdaemon still

[gcoan]

Curious. I fiddled around with soc keep a bit more last night to see if increasing it to say 3 would cause more or less charging to get me through the peak, but it didn't. And turning on second pass made marginal difference either so I left it.

And this morning the plan now is showing for a pre peak charge up to 100%. Will see if it remains the plan, but it should have planned for this activity this last night as well.

[gcoan]

Upgraded to 7.13.5 and the charge pattern has changed significantly, and for the worse :-(

latest logfile appdaemon (13).log

charge freeze is turned on

[DJBenson]

I'm seeing huge gaps in charging in recent releases but I've also just had my AIO replaced (so my GivTCP entities changed names) so wasn't sure if it was that or something else.

EDIT: Removed image as it's misleading - I'm currently manually handling my battery due to the unacceptable charge schedule and the SoC issue.

EDIT2: I think the below is pretty much what you're asking but I'll leave it here anyway as I had a slightly different ask (i.e. to guarantee a certain SoC during the peak period).

As an aside, does anybody know if there is a setting which will guarantee the battery is charged for the peak period (4-7pm) as my current plan is running very close to empty at this time and I'd rather it had a higher state of charge, especially as I'm now suffering the SoC corrections again which renders the final 20% SoC unpredictable.

[springfall2008]

I think you want to increase soC keep if you want to hold more battery

[gcoan]

For me the issue is not wanting to retain more battery, its that I am surprised that predbat isn't retaining battery charge and allowing grid draw when the rates are lower, e.g. 13:00-16:00 so that the battery can then be released when the import rates are higher:

Currently min soc keep is 0.3 and best is 972p. I think of min soc keep as defining the "just in case" soc buffer to retain in case there is exceptional grid draw, not battery to retain for peak periods.

But I tried increasing it, to 3.0, best is now 1045p and there's a bit less discharging at preferential export rates as more of the battery is retained, but the plan doesn't change for the peak and the battery is exhausted before peak starts:

If I go really extreme and change min soc keep to 5.2 (the entire battery capacity), best is now 1052, there's more aggressive overnight charging, now starting at 22:30, no forced discharging, and the charge is retained through to 6:30,

But the battery is then allowed to fully discharge by 14:30, so all the peak period is drawn from the grid. Charging then doesn't resume until the cheap rates start again at 10pm tomorrow night:

In first 2 hours of peak the historical load is 4.96kW of consumption which would exhaust my current 5.2kW battery.

If predbat fully charged/freeze discharged the 5.2 battery beforehand from 14:00-16:00 it would cost (19.4+17.86+17.81+19.11)*1.3 (kW per half hour slot) = 96.43p

But this would save 1.3 @ 35.76 + 1.18 @ 40.99 + 1.19 @ 41.08 + 1.29 @ 40.99 = 196.62p of peak consumption

Which is no nearly £1 cheaper to pre-charge the battery before the peak.

I suspect there may be something to do with the way that the decision of what is high and low rates for charging is made?

Its currently 19:49. I also find the status at the moment is weird, the plan says charging to 14% but the actual activity is freeze charging with current soc=4%, target soc and reserve both set to 14% so its not charging the battery in this slot at all as the plan says it should be:

logfile appdaemon (14).log

[gcoan]

I think there's something wrong with the freeze charging logic

21:04, status=freeze charging, target soc & battery reserve=14% but soc=4%. Plan shows charging should be to 14% but its not as its freeze charging

I turned set_charge_freeze to false

No change, its still not charging and the logfile at 21:04 shows it still retains this status for this and the following run:

2023-11-22 21:10:33.395205 INFO pred_bat: Include original charge start 11-22 20:00:00, keeping this instead of new start 11-22 21:00:00
2023-11-22 21:10:33.396337 INFO pred_bat: Charge window will be: 2023-11-22 20:00:00+00:00 - 2023-11-22 21:30:00+00:00 - current soc 4 target 14
2023-11-22 21:10:33.397473 INFO pred_bat: Configuring charge window now (now 11-22 21:10:00 target set_window_minutes 30 charge start time 11-22 20:00:00
2023-11-22 21:10:33.399030 INFO pred_bat: Set window new start 1200 end 1290
2023-11-22 21:10:33.400271 INFO pred_bat: Next discharge window will be: 2023-11-22 23:50:00+00:00 - 2023-11-23 00:01:00+00:00 at reserve 4
2023-11-22 21:10:33.401565 INFO pred_bat: Setting ECO mode as we are not yet within the discharge window - next time is 11-22 23:50:00 - 11-23 00:00:00
2023-11-22 21:10:33.403094 INFO pred_bat: Inverter 0 Current Target SOC is 14.0 already at target
2023-11-22 21:10:33.407850 INFO pred_bat: Adjust reserve to target charge % (set_reserve_enable is true)
2023-11-22 21:10:33.416295 INFO pred_bat: Inverter 0 Current reserve is 14.0 already at target
2023-11-22 21:10:33.454513 INFO pred_bat: Completed run status Freeze charging

TBH the plan doesn't make a lot of sense to be charging in the 21:00-21:30 slot to 14% when the rate is currently 24.03 and then subsequent slots the rate drops, there's no financial benefit to charging, but it is what the plan says, which in reality it isn't doing!!

[springfall2008]

You probably need to put the charge rate back to full as freeze charge will have turned it off

the plan is a little odd I agree, what’s the bigger picture like?

[springfall2008]

I think the charge slot stays by inertia, there is logic to say once it starts don’t stop to avoid too many random fluctuations

[gcoan]

You probably need to put the charge rate back to full as freeze charge will have turned it off

charge rate was 2600, discharge rate is zero and battery reserve 14% same as target soc as I said. I'll change the discharge rate back to 2600 and battery reserve back to 4

the plan is a little odd I agree, what’s the bigger picture like?

The bigger picture is as per the earlier comment (min soc=0.3) https://github.com/springfall2008/batpred/issues/357#issuecomment-1823473827 the plan was for battery to be charged from 8-9pm when rates were 20p which would have seen me through the 24p period at 9pm, but instead of charging (as per the plan), it was freeze charging so soc is stuck on 4%.

The plan is for the battery to fully charge overnight tonight on the low rates and then discharge during tomorrow morning.

But if you look at what I posted yesterday evening https://github.com/springfall2008/batpred/issues/357#issue-2005253403 that plan was much the same, charge overnight (not fully) but in reality it didn't charge at all overnight, target soc and battery reserve were set to the same all the time and so soc (blue line) didn't rise at all

this is the same as is happening just now, its doing freeze charging not charging

to note though, this wasn't the original issue I raised, but it doesn't look right either

[gcoan]

the plan for this morning is to charge:

Currently (10:17) its freeze charging which is all its done this morning

I'm going to have to revert to an earlier version of predbat or turn it off if it can't ever charge the battery and keeps on freeze charging

[gcoan]

appdaemon (15).log

[springfall2008]

You can turn freeze off in expert mode

[springfall2008]

That said it’s probably pushing the charge later to cheaper slots, which may save you money

[springfall2008]

I notice you have a good amount of solar so it may actually charge without the grid, which I think would be cheaper ?

[gcoan]

Hi Trefor, thanks for your replies, I think something is seriously broken with this version of predbat though.

I turned freeze charge off yesterday, and tried today with second pass turned off, and all the time predbat says the plan is to charge but it sets freeze charge mode:

If you look at the logs from last night when there was no solar, same thing was happening, plan was to charge but actual activity was to freeze charge with target soc=battery reserve. The only way I was able to get my battery to charge from the grid was to set predbat to read only and manually initiate a force charge. You are right, the PV forecast is for a decent amount of sun this morning but that doesn't explain last night's behaviour or why the plan says charge when its actually setting freeze charge? (The PV is actually now too high as the solcast forecast is for both arrays and whilst both inverters are working, I currently only have one 5.2 battery on one inverter.)

[JonathanLew1s]

I also see something not quite right with the determination to charge and slot selection.

1. SOC keep is set to 3, yet the system plans down to the SOC reserve %. Shouldn't it plan to maintain SOC keep?
2. Charge determination is preferencing future estimated costs over known current costs. Last night it did not take full advantage of significantly lower than average import rates, based on gamble that tonights overnights rates will be equal. I have import metric set to 0.2 to try and make future estimated rates higher than current to no apparent benefit.
3. Follow on to above, the system is diverting some load to grid today, again based on a gamble tonights rates are cheaper than the solar export
4. Charge freeze is not resulting in the lowest slots being chosen. See below where at midnight its freezing yet charging later at a higher predicted rate.

[springfall2008]

SOC keep is set to 3, yet the system plans down to the SOC reserve %. Shouldn't it plan to maintain SOC keep?

Isn't 3 kWh just a bit above 30%, the plan seems to stay above this level doens't it?

The status may have been confusing, as you have 'Set Discharge During Charge' turned off that will turn off the battery discharge during a charge slot and that is being reported in the status as 'Charge Freeze' when it maybe isn't.

I have import metric set to 0.2 to try and make future estimated rates higher than current to no apparent benefit.

Do you mean the future rate adjustment setting or something else?

Follow on to above, the system is diverting some load to grid today, again based on a gamble tonights rates are cheaper than the solar export

You would need to use either the metric_future_rate_offset_import or use the Nordpool data to estimate tomorrows rates to avoid this.

Charge freeze is not resulting in the lowest slots being chosen. See below where at midnight its freezing yet charging later at a higher predicted rate.

I think you might be missing the inverter/battery losses in this picture which amount to at least 14% so a freeze charge at say 11.4p is equivalent to charging at 10p cost wise?

[springfall2008]

If you have time to test this beta release it could help: https://github.com/springfall2008/batpred/releases/tag/v7.13.7

[JonathanLew1s]

Apologies, that screenshot is after I set the SOC keep to 6 as a 15% BMS correction overnight Tuesday resulted in hitting 4% during peak hours yesterday. Suspected the plan did find a low rate slot between the correction and peak hours and planned down to reserve. Bumped SOC Keep and SOC Keep Best to 6 to have the system operate at the higher end of battery % to accommodate BMS issues despite regular cycling.

Metric future rate import is set and Set Discharge During Charge is enabled. I will install the beta now.

[gcoan]

Here is the plan on 7.13.6 (current status = freeze charge)

And after updating to 7.13.7 (current status = freeze hold)

There are several things that seem weird to me with this current plan:

• why charge and keep the soc at 100% in the 1630 and 1700 blocks, it would be cheaper to let the battery supply the house in these (the most expensive periods) and charge/hold charge at 1800, 1830 and 1900 or just let the battery run out and default to grid draw as the rates are dropping
• why force discharge at 1800 and 1830? Yes it's a good export rate but if this is being done at the expense of having to import from 1600-1730 when the import rate is higher, it'd be better to not export at all and let the battery support the house. I don't have an option to turn off discharging any more, but I don't feel I should need it as I should only be discharging when export>import and I have spare battery
• the 2030 charge seems unnecessary as the rates for all the following slots are lower

[springfall2008]

And after updating to 7.13.7 (current status = freeze hold)

I don't recognise freeze hold, what are you seeing exactly in Predbat status?

Can you share your appdaemon.log?

[springfall2008]

Future offset import is in pence, so 0.2 will have little impact - I'd suggest maybe 5p or 10?

[springfall2008]

I also don't understand, your rate_low_threshold says 0.85 but clearly the rates are above that, did you change it back to 0 afterwards?

Best soc min of 6 is going to break stuff, that means all charge slots must be 6 kWh or above. I think you want that 0 and Best SOC Keep to be 6

[gcoan]

And after updating to 7.13.7 (current status = freeze hold)

I don't recognise freeze hold, what are you seeing exactly in Predbat status?

Can you share your appdaemon.log?

Sorry, my mistake in typing, the status was (and is) Hold charging after I upgraded to 7.13.7

Here's the logfile covering the period after I upgraded to 7.13.7 through to now appdaemon (16).log

And here's the current plan, its now planning to charge from 16:00-18:00 at import rates 41-38p, seemingly to retain sufficient charge to discharge from 18:00-19:00 at 28p. Similarly, 20:30 and 21:00 charging at 21 and 20p to discharge then in the subsequent blocks at 17p

[JonathanLew1s]

Future offset import is in pence, so 0.2 will have little impact - I'd suggest maybe 5p or 10?

Thanks for that snippet, didn't grasp that from the documentation.

I also don't understand, your rate_low_threshold says 0.85 but clearly the rates are above that, did you change it back to 0 afterwards?

I read that to be 85% not .85p. 0.85 creates three distinct bands in the import rates and does appear to work to determine the low rate groups.

Best soc min of 6 is going to break stuff, that means all charge slots must be 6 kWh or above. I think you want that 0 and Best SOC Keep to be 6

Corrected and that helps, set that in desperation last night trying to get a charge.

Now have SOC keep at 4kWh and reserve at 4%. 19.5kWh system so 1kWh is roughly 5%, wouldn't expect that the result would plan to allow SOC lower than 24%. It currently plans to force discharge Saturday to get to 15%. Do I misunderstand the intention of SOC keep, being an artificial floor for planning.

[JonathanLew1s]

Octopus rates just dropped, still seeing some odd decisions.

Why is it not taking full advantage of the 22:30 rate to charge.

[gcoan]

As predbat wanted to keep charging /importing through most of the peak rate period rather than letting the battery reduce the grid draw I ended up setting it into read only mode and manually setting the inverter to Eco. I pretty good got through the entire peak on the 5.2 battery.

Afterwards predbat kept on wanting to charge the battery a little before letting it discharge to the home again, but as before it was doing this as the rates were dropping so it would have been more expensive than just leaving it to grid draw.

Here's the plan at 19:47. Version 7.13.7. Min soc keep =0.3 so that wouldn't account for the charges to 14%.

I tried downgrading to 7.13.3 and the plan is better, less unnecessary charging to fill the battery when rates are falling, but the 20:30 charge is unnecessary still

[gcoan]

Trying the latest version to see what differences it makes...

7.13.3, there's an unnecessary 9pm charge and no pre-charge before peak evening draw tomorrow:

7.13.8, lots of charging this evening. The 21:30 and 22:00 are both labelled as charging but from the soc it looks like they are freeze charging? It sort of makes sense to be doing charging after 21:30 in order to fill the battery and then export at 16.93

For comparison, 7.13.7 (best=935.4) shows not quite as much charging this evening but no discharging which doesn't make a lot of sense to do.

I just put 7.13.8 back (I do like the yellow BTW, better than the red) as I was going to turn predbat back on and take advantage of the planned charge and export, and the latest plan now shows no export at all tonight?? Weird.

[DJBenson]

Installed 7.13.8 last night. All looked OK until I woke up to an idle battery at 25p unit rates with 97% SoC.

Back to 7.13.6 and looks better.

[springfall2008]

@DJBenson, Can you share a logfile, it seems a little odd you have so much charging. Do you have something set to force the charge to be so high?

[DJBenson]

@DJBenson, Can you share a logfile, it seems a little odd you have so much charging. Do you have something set to force the charge to be so high?

Will dig out a log.

I've gone to great lengths to make sure I'm on default config so not sure what's driving this.

[DJBenson]

@springfall2008 it looks like I hadn't enabled AppDaemon logging. I've turned it on now but not sure if this will contain anything useful. Let me know and I can provide another version later.

appdaemon.log

As an aside when logging is enabled the log output in the addon seems to be suppressed (i.e. I can no longer see logs via HA) - is it possible to log to the UI and a log file?

[springfall2008]

I'm not sure if it can show both or not, you would have to check the AppDaemon documentation. Errors will still go to the HA log but the rest ends up in this logfile.

I think your issue maybe this:

inverter_loss(5 %) battery_loss(5 %) battery_loss_discharge (5 %)

This means 20% losses overall for charging to discharging which is going to skew things quite a lot towards keeping the battery full (It can't be empty due to metric keep being non-zero).

[DJBenson]

I'm not sure if it can show both or not, you would have to check the AppDaemon documentation. Errors will still go to the HA log but the rest ends up in this logfile.

I think your issue maybe this:

inverter_loss(5 %) battery_loss(5 %) battery_loss_discharge (5 %)

This means 20% losses overall for charging to discharging which is going to skew things quite a lot towards keeping the battery full (It can't be empty due to metric keep being non-zero).

From what I've been reading the round trip losses on the AIO are between 15-20% which is why I changed the inverter loss value. The other two are defaults (or were). I've removed the inverter_loss value to see what happens. The other two are set to 5.

[DJBenson]

Gone back to latest version with the inverter loss removed and the plan (to me) looks ok. It looks to be getting me over the "4pm hump" which is kinda my main concern. Still don't know what that "freeze discharge" status means as it's clearly discharging (look at the gauges).

[springfall2008]

https://www.loom.com/share/e55b578d08c7414788e88948325907fa?sid=279ff3e5-01a2-4f81-a316-b3d3b2697e8a maybe useful

[springfall2008]

From what I've been reading the round trip losses on the AIO are between 15-20% which is why I changed the inverter loss value. The other two are defaults (or were). I've removed the inverter_loss value to see what happens. The other two are set to 5.

Yes, it's actually correct. Also the default is 2p metric battery cycle.

This means charging at 20p and using it costs 24p including losses and then 28p including the cycle charge. Hence it's cheaper to be at 100% and use the grid (or freeze) for rates <28p.

However most people don't want to accept that reality and tend to see the ideal case ignoring these costs :)

[gcoan]

Personally I've set the metric battery cycle to zero. I've already bought the battery so I might as well use it. Whether it causes significantly premature aging by using it a lot is a future problem IMO. (And for the 9.5 and I'd assume the AIO its unlimited battery cycles so bit of a moot point anyway).

r/e the charge/discharge rates. I've heard similar feedback about 10-20% on the hybrid inverters as well. I have 5% charging and 5% discharging loss and 0% for inverter loss - so probably on the lower end. This generally gives 'reasonable' charging behaviour

[DJBenson]

From what I've been reading the round trip losses on the AIO are between 15-20% which is why I changed the inverter loss value. The other two are defaults (or were). I've removed the inverter_loss value to see what happens. The other two are set to 5.

Yes, it's actually correct. Also the default is 2p metric battery cycle.

This means charging at 20p and using it costs 24p including losses and then 28p including the cycle charge. Hence it's cheaper to be at 100% and use the grid (or freeze) for rates <28p.

However most people don't want to accept that reality and tend to see the ideal case ignoring these costs :)

Yeah I'm not obsessing about cost/impact on the battery, I've paid my money so whether it wipes its face is pretty much irrelevant.

[gcoan]

I wrote a long entry on comparing 7.13.8, .3 and .7 last night, but never saved it because I got side tracked with the inverter. predbat was setting the inverter to charge the battery (set charge slot, target soc&reserve soc both set to a value>current soc) but the inverter just sat there on 4% and it just wasn't charging. Spent ages on this, turning predbat into read only, trying to initiate a charge in the same way that predbat does (without using force charge), resetting the inverter to defaults, nothing worked. Quite by chance I changed the discharge rate up from zero to 2600 and the inverter started charging the battery. Set the discharge rate back to zero and it carried on charging ok until I changed the charge window times. Very very weird as to why setting the discharge rate should have affected the charging, but sorted now.

Anyway, feedback on 7.13.8. I left it installed last night. There were still some weird charging behaviour in the evening where it wanted to charge the battery a bit and then let it discharge despite the next agile slot being cheaper than the current one, so I had a couple of sessions of turning predbat into read only mode but after that the overnight plan looked OK so I left it running and it looks to have behaved appropriately.

The plan for today looks reasonable as well, charging up to fill the battery before the evening peak. Although maybe continue charging at 16:00 to 100% at 37p to avoid the grid draw when the battery is exhausted at 18:30 at 40p?

I'll see how it develops through the day.

[springfall2008]

Should we resolve this now and start a new issue for anything related to the latest release?

[gcoan]

Should we resolve this now and start a new issue for anything related to the latest release?

Yep fine. Current releases are charging fine before the peak for me