Low Power Charge Mode doesn't always self adjust to fill the available time period

[mpartington]

I understand the intent is that if "Set Charge Low Power Mode" is true, then Predbat will manage the charge rate , aiming to achieve the target SoC 30 mins before the end of the charge window. In my case this is 00:30 to 04:30

I have seen a number of instances on my system where it finished much earlier (up to 90 minutes). Predbat doesn't seem to realise that it is ahead of schedule and to further dial down the charge rate. I have since tweaked the charge profile in apps.yaml (to suit 3015) and reduced total charging losses to 4%. Following this, on 25th it finished at 3:20 (40 mins ahead of target and 70 before end of charge slot)

It was actually quite accurate this morning (26 Jan), finishing 42 minutes before end of charge window (so 12 ahead of target), so not sure if it may relate to size of charge necessary (frustratingly I did not record the logs). I have checked, and the amount or energy added each night is consistent with an approximation based on starting SoC, so no major errors there (or soc jumps)

Expected behavior Whilst inaccurate efficiency assumptions in the settings (or SoC readings) could initially lead to a faster of slower rate of charge than predicted, I would expect Predbat to compensate for this (up until the point the final 10% charge profile is limited by the BMS) by progressively reducing the charge rate per calculation cycle. On the graphed example (25-Jan), this doesn't seem to have happened as expected (unfortunately I only have the log for the very final part of that charge, where the BMS is likely more dominant in limiting the charge rate)

Predbat Version: v.7.15.1

Environment details

• AC3 with 2x 5.2kWh batteries running D0.203-A0.203 (new firmware) and 3015
• Standard HAOS installer
• Anything else?

Screenshots

Log file Logs for 25th plotted above from 3am attached. I will continue to log and add bad examples to better show the issue. 25_Jan.log

[mpartington]

Added battery charge Rate graph for same period. It doesn't fluctuate, but it is unusual that it increases the charge rate quite near to the end of charge, (before ramping down ) despite being ahead of schedule for the finish time

[mpartington]

Similar profile this morning. Hit 100% at 3.30am, (30 mins early- so quite high error in 4hr slot) charge rate is initially reduced passed 2am, but then goes back up. The big reduction only seems to be when it hits 90% and switched to the model charge profile.in apps.yaml. Plan was aiming 97% at 3.30. Log added below:

[mpartington]

27_LOG.log

Log attached and just to confirm this is running v7.15.2 (with the fixes referenced in), so confirmed no improvements for this .

[springfall2008]

So this doesn't seem wrong as such, the charge rate is only restored to full power once the target has been hit. The 30 minutes early seems a little bit in the noise given it's set to finish 20 minutes early. Should I maybe reduce the margin to 10 minutes?

[mpartington]

Maybe ive introduce some confusion. End of my charging timeslot is 4.30, so if we work to that then predbat is finishing 1hour before. So in a 4 hour slot, the battery is idle 25% of the time.

However I know you have hard coded it to finish 30 minutes before that i.e. at 4.00, hence why I was suggesting 30 mins early. I'm not really sure it can be classed as normal though, it must have a charge profile.its trying to match to achieve the end time. If it gets ahead of itself, it doesn't appear to be reducing charge rate. In fact, it actually increases in a few instances.

Edit, I see you said it's hard code 20 mins early Is a tolerance to charge slot finish time --20 to -60 minutes within your expectations? I.e. my go slot is 00.30 to 04.30 and it is in the noise to finish as early as 3.30?

[springfall2008]

I've made some tweaks on MAIN to try to make this more accurate and to add some debug information, can you run with main tonight and collect the log?

[mpartington]

Sure, thanks

[mpartington]

Finished a little later this morning(3.47am Vs 4.30 target), but unsure if this was because it started from a lower soc.

No changes to the charge rate made until around 90% to lower it. I would have thought every calculation, predbat would be calculating soc_kw to full/ charge time remaining and adaPting the charge rate.

Now it may only be worth changing the charge rate if there is a change over x watts (to prevent frequent small tweaks). The other thing I was wondering is every system is different in the values it will.accept,.for example, if you want it to charge at 1000W, it may well be set by the inverter to 1250W. Something to do with inverter using battery capacity divided by number of graduations. Is this impacting the current method?

Log file attached for 'main' appdaemon.log

[springfall2008]

I've just had a look through the logs and the calculated charge rate is much higher than minimum rate required:

min_rate 1253 returns 1624

min_rate is just the time charge amount left divided into the time left.

On top of this should be the 4% battery loss you set which would get you to 1306. The remaining difference is quite large and in theory is only down to either a) the battery charging curve in apps.yaml or b) a bug.

Can you share what you have set for battery_charge_power_curve ?

[mpartington]

I will check charge curve again against last nights data, but it seemed accurate against a number of nights I previously spot checked it against.

The need to enter a value for 100% seemed odd, as charge rate should be zero. However going off the example, I assumed this was the rate from 99 to 100% and then I worked backwards to fill the rest of the lines. However I doubt that would make a significant difference?

The percentage is based off my 3kW AC charge output

[springfall2008]

Notice later on the gap between min and predicted gets bigger

Find charge rate now 210 soc 8.1051648 window {'start': 30, 'end': 270, 'average': 9.0} target_soc 8.35584 max_rate 3000 min_rate 300 returns 1250

This is implying it could be down to the battery charge power curve? We are at 97% charge rate and it's saying you have to charge for 50 minutes at 1250w.

I wonder if the charge curve is really a cap and not a scaling, and that's the mistake I've made in the model. e.g. at 96% if the value is 0.51 does it really mean you can't charge at rates higher than 51% of max rather than you will charge half speed.

[mpartington]

Not the cause, but I notice the battery is unable to charge at the modelled values initially as predbat is demanding a lower charge rate.

Between 96 to 97% it is limited to 1251W (1251/3000 = 0.42), which is consistent to how I think I've completed the table. If 100% should be zero, then they would all shift a place if that makes sense.

[springfall2008]

The confusion over 100% is because that's the rounded SOC% when modelled, really its 99.5% to 100%.

That said I think I found the issue, if 99% is set to 0.5 in the curve then Predbat is assuming that if you set the charge rate to 1000 you will get 500. I think this is incorrect and really the 0.5 means you can't go above 50% of the max charge rate

[mpartington]

Fingers crossed.

So just so I get it right in the calibration table, would the 0.42 calculated be placed at the 96 or 97% line? If 96%, what would be entered at 100% (as it would be zero based on the number of steps)

[springfall2008]

I think the 0.42 is at 96, although maybe it should really be at 96.5 and my logic is confused.

The problem is the battery only reports in 1% steps but in reality you can charge the battery when at 100% as the reported value is being rounded.

[springfall2008]

I've made a fix on MAIN, can you re-test again tonight? I think if it's right it should be within 10 minutes of the target and maybe I need to increase the margin again if its too close.

[mpartington]

Brilliant, thank you!

I'll also move all my charge rates one place earlier and duplicate 99 and 100%

On Sun, 28 Jan 2024, 10:16 Trefor Southwell, @.***> wrote:

I've made a fix on MAIN, can you re-test again tonight? I think if it's right it should be within 10 minutes of the target and maybe I need to increase the margin again if its too close.

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

[gcoan]

Would you be able to write up how you calculated the power curve so I can add it to the documentation?

Thanks Geoffrey On 28 Jan 2024 at 10:19 +0000, mpartington @.***>, wrote:

Brilliant, thank you!

I'll also move all my charge rates one place earlier and duplicate 99 and 100%

On Sun, 28 Jan 2024, 10:16 Trefor Southwell, @.***> wrote:

I've made a fix on MAIN, can you re-test again tonight? I think if it's right it should be within 10 minutes of the target and maybe I need to increase the margin again if its too close.

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

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[mpartington]

This is how I did it,

1. Find an example where the battery has been continually charged to 100% at the maximum inverter power setting.

Recommended to use either an overnight charge or where solar is sufficient to provide the maximum charge rate for the last 10%

2. Plot SoC and battery power (sensor.givtcp_serialnumber_battery_power) between 90 and 100%

3. Read off the charge power at each of the steps shown

   

4. Determine the maximum AC power that the inverter can charge the battery : • e.g. AC3 = 3000W, • Gen 1 Hybrid =2,500 W • Etc

5. Calculate the value for the charging curve as a % of the max charge rate for each soc percentage

6. Example in the table <html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

Table SoC | Interpreted to be power between | W from Battery Power Graph | Charging curve as a function of the max charge rate | example for AC3 -- | -- | -- | -- | -- 100 | 99 to 100 | 421 | 0.14 | 421/3000 = 0.14 99 | 98 to 99 | 698 | 0.23 | 698/3000 = 0.23 98 | 97 to 98 | 974 | 0.32 | .. 97 | 96 to 97 | 1251 | 0.42 | .. 96 | 95 to 96 | 1528 | 0.51 | etc 95 | 94 to 95 | 1850 | 0.62 |   94 | 93 to 94 | 2080 | 0.69 |   93 | 92 to 93 | 2357 | 0.79 |   92 | 91 to 92 | 2633 | 0.88 |   91 | 90 to 91 | 2872 | 0.96 |  

[mpartington]

Obviously the fact I am taking a 100% point whilst the SoC is reading 99% could cause confusion. So I tried to say in the table that 100% is the rate the battery charges at to move from 99 to 100%. I think this is slightly at odds with Trefors code, but for sake of simplicity I can't see it making too much difference

Probably needs a bit more thought on how to present

[springfall2008]

I’d say 99 is the average charge rate when the battery reports 99%. I can probably fix the code

100 probably should be the same as 99 as it’s hard to measure, but does happen

[mpartington]

I’d say 99 is the average charge rate when the battery reports 99%. I can probably fix the code

100 probably should be the same as 99 as it’s hard to measure, but does happen

sounds sensible. I've changed my apps.yaml as follows. Hopefully adding the additional 90% point doesn't break anything....

[springfall2008]

I had a go at automating this, the version on 'main' will compute the curve if you have data in your history for it.

Interesting I never get to more than 95% of the max charge rate, do you see the same?

https://github.com/springfall2008/batpred/pull/658

2024-01-28 20:09:28.784601 INFO pred_bat: Find charge curve with sensors sensor.givtcp_sa2243g277_soc_kwh and number.givtcp_sa2243g277_battery_charge_rate and predbat.status and sensor.givtcp_sa2243g277_battery_power 2024-01-28 20:09:33.886039 INFO pred_bat: Find charge curve has 22.0 days of data, max days 22 2024-01-28 20:09:33.897422 INFO pred_bat: Charge Curve Percent: 99 at 01-27 05:24:00 took 3 minutes charged 0.1 curve 0.14 average_power 351.0 2024-01-28 20:09:33.898745 INFO pred_bat: Charge Curve Percent: 98 at 01-27 05:21:00 took 10 minutes charged 0.1 curve 0.14 average_power 351.0 2024-01-28 20:09:33.900062 INFO pred_bat: Charge Curve Percent: 97 at 01-27 05:11:00 took 7 minutes charged 0.1 curve 0.32 average_power 812.0 2024-01-28 20:09:33.901378 INFO pred_bat: Charge Curve Percent: 96 at 01-27 05:04:00 took 6 minutes charged 0.09 curve 0.41 average_power 1042.0 2024-01-28 20:09:33.902685 INFO pred_bat: Charge Curve Percent: 95 at 01-27 04:58:00 took 5 minutes charged 0.1 curve 0.41 average_power 1043.0 2024-01-28 20:09:33.904020 INFO pred_bat: Charge Curve Percent: 94 at 01-27 04:53:00 took 4 minutes charged 0.1 curve 0.5 average_power 1272.0 2024-01-28 20:09:33.905353 INFO pred_bat: Charge Curve Percent: 93 at 01-27 04:49:00 took 3 minutes charged 0.1 curve 0.68 average_power 1733.0 2024-01-28 20:09:33.906664 INFO pred_bat: Charge Curve Percent: 92 at 01-27 04:46:00 took 3 minutes charged 0.09 curve 0.77 average_power 1963.0 2024-01-28 20:09:33.907969 INFO pred_bat: Charge Curve Percent: 91 at 01-27 04:43:00 took 3 minutes charged 0.1 curve 0.77 average_power 1964.0 2024-01-28 20:09:33.910253 INFO pred_bat: Charge Curve Percent: 90 at 01-27 04:40:00 took 2 minutes charged 0.09 curve 0.95 average_power 2424.0 2024-01-28 20:09:33.911595 INFO pred_bat: Charge Curve Percent: 89 at 01-27 04:38:00 took 3 minutes charged 0.1 curve 0.95 average_power 2424.0 2024-01-28 20:09:33.912911 INFO pred_bat: Charge Curve Percent: 88 at 01-27 04:35:00 took 2 minutes charged 0.1 curve 0.95 average_power 2424.0 2024-01-28 20:09:33.914240 INFO pred_bat: Charge Curve Percent: 87 at 01-27 04:33:00 took 3 minutes charged 0.1 curve 0.95 average_power 2425.0 2024-01-28 20:09:33.915559 INFO pred_bat: Charge Curve Percent: 86 at 01-27 04:30:00 took 2 minutes charged 0.09 curve 0.95 average_power 2424.0 2024-01-28 20:09:33.916897 INFO pred_bat: Charge Curve Percent: 85 at 01-27 02:29:00 took 2 minutes charged 0.1 curve 0.95 average_power 2424.0 2024-01-28 20:09:33.918206 INFO pred_bat: Charge curve can be entered into apps.yaml: {99: 0.14, 100: 0.14, 98: 0.14, 97: 0.32, 96: 0.41, 95: 0.41, 94: 0.5, 93: 0.68, 92: 0.77, 91: 0.77, 90: 0.95, 89: 0.95, 88: 0.95, 87: 0.95, 86: 0.95, 85: 0.95}

[mpartington]

Not sure it's working for me First run: 2024-01-28 20:27:55.880945 INFO pred_bat: Find charge curve with sensors sensor.givtcp_ce2146g269_soc_kwh and number.givtcp_ce2146g269_battery_charge_rate and predbat.status and sensor.givtcp_ce2146g269_battery_power 2024-01-28 20:28:07.051694 WARNING pred_bat: Coroutine (<coroutine object Hass.get_history at 0x7f9c577c40>) took too long (10 seconds), cancelling the task... 2024-01-28 20:28:07.056280 INFO pred_bat: Note: Can not find battery charge curve, one of the required settings for soc_kw and charge_rate do not have history, check apps.yaml

I then restarted appDaemon and got this, but only partially complete:

2024-01-28 20:37:15.767312 INFO pred_bat: Find charge curve with sensors sensor.givtcp_ce2146g269_soc_kwh and number.givtcp_ce2146g269_battery_charge_rate and predbat.status and sensor.givtcp_ce2146g269_battery_power 2024-01-28 20:37:26.603445 INFO pred_bat: Find charge curve has 15.0 days of data, max days 15 2024-01-28 20:37:26.648455 INFO pred_bat: Charge curve can be entered into apps.yaml: {}

Does it only run once? Not appearing on 20:40 run

[springfall2008]

It only runs once as it takes a while to get the history it seems a little pointless to repeat every cycle.

I suspect you don’t have data as you have been using low power mode for the past 15 days?

[mpartington]

Should be a few days still at full charge rate in last 15 days

[springfall2008]

Can you show predbat status here and confirm its reporting as charging ?

[mpartington]

Ah, I know why! I'm purging a load of data more frequently to keep database size under control. I decided I didn't need to keep predbat data beyond a couple of days, so it won't be available. I can maybe exclude status from that

[springfall2008]

Interesting, it was a quick hack to figure out if the battery was really charging from grid if it was from PV. If you can suggest an alternative sensor I could also change it.

[mpartington]

Only GivTCP one I can think of is

switch.givtcp_ce2146g269_enable_charge_schedule

Predbat turns it on and off around the charge schedules, however not sure if that would work for me as I override it back on.

On Sun, 28 Jan 2024, 20:57 Trefor Southwell, @.***> wrote:

Interesting, it was a quick hack to figure out if the battery was really charging from grid if it was from PV. If you can suggest an alternative sensor I could also change it.

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

[gcoan]

Interesting I never get to more than 95% of the max charge rate, do you see the same?

On my Gen 1 hybrid which is supposed to be 2.6kW, it seems to charge pretty consistently at 2422-2425W but discharge at 2575-2581W, sometimes a bit more, I've seen it rounded to 2.7kW on occasions.

@mpartington thanks for the explanation about the charge profile, I had a look at my own and had never noticed it is ramping down charge rate as well although on my 5.2 battery its only from 96-100%

I will add this to the docs depending on whether Trefor can automate determining the curve or not, useful if he can.

BTW, one request @springfall2008 , what about multiple batteries? This might be part of a broader enhancement request for different batteries and inverters, e.g. my 5.2 mis-represents itself as 5.22kW and doesn't report the 80% DoD, but my 9.5 doesn't have this issue. At the moment there's only the ability to enter a single value that applies across all the batteries.

[mpartington]

I don't think multiple batteries is an issue here, the method to calculate would be the same, but maybe the curve would look a little different compared to a single battery, or even the same setup on a different powered inverter. Basically it maps the charge profile specific to the set up analysed. I have 2x 5.2s on an AC3.

Might need to repeat the exercise if you added, removed or even updated the BMS firmware.

Presumably for the mixed battery scaling case, you would need to workout the total usable capacity and apply an appropriate scale factor.

The difference in the charge/discharge values is because Giv display the DC power for the battery, so it's lower than the AC rating during charge due to conversation losses and the opposite during discharge where the DC power is higher to achieve the AC target.

My max (DC) charge is 2875 W (ish) from 3000W AC, so probably similar to the 95% max Trefor is seeing.

On Sun, 28 Jan 2024, 21:59 Geoffrey Coan, @.***> wrote:

Interesting I never get to more than 95% of the max charge rate, do you see the same?

On my Gen 1 hybrid which is supposed to be 2.6kW, it seems to charge pretty consistently at 2422-2425W but discharge at 2575-2581W, sometimes a bit more, I've seen it rounded to 2.7kW on occasions.

@mpartington https://github.com/mpartington thanks for the explanation about the charge profile, I had a look at my own and had never noticed it is ramping down charge rate as well although on my 5.2 battery its only from 96-100% image.png (view on web) https://github.com/springfall2008/batpred/assets/142018870/1711e64c-199b-480c-a351-65a9488f081e

I will add this to the docs depending on whether Trefor can automate determining the curve or not, useful if he can.

BTW, one request @springfall2008 https://github.com/springfall2008 , what about multiple batteries? This might be part of a broader enhancement request for different batteries and inverters, e.g. my 5.2 mis-represents itself as 5.22kW and doesn't report the 80% DoD, but my 9.5 doesn't have this issue. At the moment there's only the ability to enter a single value that applies across all the batteries.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/650#issuecomment-1913734963, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZQHXHORQ7D47YVWNPJXGULYQ3C27AVCNFSM6AAAAABCL2GZHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTG4ZTIOJWGM . You are receiving this because you were mentioned.Message ID: @.***>

[mpartington]

I've made a fix on MAIN, can you re-test again tonight? I think if it's right it should be within 10 minutes of the target and maybe I need to increase the margin again if its too close.

Massive improvement this morning. Finished 20 minutes before, so almost to plan.

I wonder if we are double accounting losses on the curve and this accounts for the final 10 mins. We are inconsistent in units, as using the DC charge rate (post.actual loss) and the max AC charge rate (pre loss) as a ratio. The DC charge will already include the charge losses. Hence why Trefor only sees a 0.95 max ratio, rather than 1.

Graph and log file below

appdaemon29Jan.log

[springfall2008]

I've updated the auto-compute on MAIN to publish the curve in a format you can cut/paste into your apps.yaml, and it's based around 1.0. It then suggests a battery rate max scaling value. The battery loss is accounted for already but not the inverter loss which shouldn't really impact it (e.g. my inverter is 3.6kw but the battery only charges at 2.5kw)

[mpartington]

Could you share the example output for your system? Just wondering how to workout manually. Although your system is rated for 2.5kW AC charging, the values used to calculate the profile are already in DC (and will be lower)

A single battery rate scaling falls down, because the battery power is in DC, it will be lower than AC nominal for charging but higher for discharge. You would need a separate one for charge and discharge if I understand your proposal

[gcoan]

Thanks Trefor I’m wondering if we need the power curve in apps.yaml now if predbat can calculate it itself based on battery actual data, why not use that instead of people needing to copy from the log to the config file ?GeoffreyOn 29 Jan 2024, at 09:04, Trefor Southwell @.***> wrote: I've updated the auto-compute on MAIN to publish the curve in a format you can cut/paste into your apps.yaml, and it's based around 1.0. It then suggests a battery rate max scaling value. The battery loss is accounted for already but not the inverter loss which shouldn't really impact it (e.g. my inverter is 3.6kw but the battery only charges at 2.5kw)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[JonathanLew1s]

Temperature playing a role in limiting charge rates also? Interesting thread over at Givenergy forums https://community.givenergy.cloud/d/3892-low-charging-rate/9

0.2 x 9.5 kWh = Max charge rate at 10-20c of 1.9kWh (per battery)

0 at 0C 0.1 at 0-10C 0.2 at 10-20C 0.5 at 20-25C 1.0 at 25-45C 0.5 at 45-55C 0.2 at 55-60C 0 at 65C

[mpartington]

I suspect on an intentional slow charge we would be less likely to be limited by temperature, but a good point and could impact the charge curve calculation.

I don't believe the rates above are correct for 3015, I have 2 x 5.2kWh batteries and have never been limited to 0.1C between the 5 and 10 deg I have seen my cell temps drop to (that would have been very obvious).

The rates Paul quoted were the ones I understood were being used in the BMS,.so 0.25C between 0.and 10 (although still don't match my reality). For me this is theoretically 2.56 kW max charge, which is just below the max DC from my 3kW inverter limit. Although it still.charges higher (I'm normally above 5 Deg, so maybe there is another undocumented step)

Whereas 0.1C would limit me to just 1.06kW

Conclusion, I'd be wary about hard coding this into Predbat, although some people are undoubtedly seeing drops in charge rates.

[springfall2008]

I'm counting this as fixed for now. Not sure I want to look at temperature compensation just yet :)