Closed mpartington closed 7 months ago
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
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:
Log attached and just to confirm this is running v7.15.2 (with the fixes referenced in), so confirmed no improvements for this .
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?
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?
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?
Sure, thanks
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
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 ?
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
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.
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.
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
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)
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.
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.
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: @.***>
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: @.***>
This is how I did it,
Recommended to use either an overnight charge or where solar is sufficient to provide the maximum charge rate for the last 10%
Plot SoC and battery power (sensor.givtcp_serialnumber_battery_power) between 90 and 100%
Read off the charge power at each of the steps shown
Determine the maximum AC power that the inverter can charge the battery : • e.g. AC3 = 3000W, • Gen 1 Hybrid =2,500 W • Etc
Calculate the value for the charging curve as a % of the max charge rate for each soc percentage
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">
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
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