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
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