Dynamic ESS does not charge fast enough to reach target SOC

[kudos50]

The Cerbo does not seem to instruct the Multi’s to charge fast enough to reach the schedulers target soc. The scheduler calculations seem OK and conclude a 15% increase per hour during buy opportunities. In my setup that translates to about 11,5kW per hour.

This week, with an abundance of MPPT charging power added on top of 3xMP5000, the DESS configured 13kW charge is well within reach. No further DVCC charge restrictions have been configured on the system.

In practice, the MPPTs charge over 5kW but the multi’s start OK every 15mins but end very slow. So total charge is about 12kW at start but only 7 or 8kW later in the window. Mostly resulting in a gain of only 11 to 12% instead of 15% per hour

If I change the setup to keep batteries charged, the system will charge at over 15kW for hours at a time.

[kudos50]

This must be somehow related to the new battery soc precision. At the risk of over complicating things in chat, this is what happened just now:

Schedule was fine. Numbers added up AND reflected as such on the 15min windows on the Cerbo for the whole charging plan. Again all well within system capacity and config.

11 - 12	--> 32% > 47% (matches 7) (35,81 > 39,62 > 43,43 > 47,23)
12 - 13	--> 47% > 62% (matches 11)
13 - 14	--> 62% > 78% (matches 15)
14 - 15	--> 78% > 88% (matches 19)

First, just before the charge was supposed to start at 11:00am the Scheduler did something impossible. I have tried 2 browsers and the app, all the same result. The targetsoc for 12:00AM was changed to 59%. From 32% to 59% is impossible with this configuration. On top of that, window0 kept 32% targetsoc causing the system to set there waiting till 11:15 which still had the 35,81 target. Basically all values from above remained the same, just 15mins later.

The system started charging at 11:15 and as precision is set to 0 due to the use of Pylons the targetsoc was rounded to 36%. At exactly 11:30 the battery said 36%, active window changed to 1 and targetsoc is 40%. A few seconds later, the windows got updated in the background, active window changed to 0 again but targetsoc was lowered to 39%. A quick check learned that 39,62% was now changed to only 38,81%.

If that happens almost every 15mins it explains why my system never makes the plan for the end of the day. The scheduler seems to continuously adjust targetsoc for the next window down. As in my case precision is 0 and 1% = 0,77kW.

@dognose Would you please mind having a look at this. I cannot take this investigation any further. I cannot be sure but I have a strong feeling this started with the precision implementation a while back.

[kudos50]

I have been following the window updates for a bit now and my earlier remark still holds. I have now caught several repetitions in which targetsoc is reached at the end of window where active window changes to 1 temporarily. As this still represents a decent percentage, charging speed is OK. As soon as the windows get updated and window0 becomes active again, the targetsoc is lowered significantly. In some cases even 0,8% resulting in a full 1% drop of targetsoc. Which in turn means the Multi’s will immediately reduce their charging speed.

For the first hour that I have monitored (11 - 12) using the numbers in the previous post, the result was only 42% instead of the original 47% target.

All and all very hard to believe I’m the only user with a big pack and precision 0 that is experiencing this problem. Mostly likely others just haven’t noticed it yet.

[dognose]

Hi,

just saw this thread, and I already replied you in the PN. Pasting here for other readers of affected systems as well:

---

Hi,

I’ve had a look at your system. The chargerate calculated is fine, and the chargerate the battery reports matches this calculation within usual margins, that is all fine.

The Issue you are seeing is arrising from a combination of “things” that play a role here: Battery Size, configured maximum charge rate, your systems integer based soc and the 15 minute window length.

So, what happens exactly:

• You have a very big battery (76.8 kWh)
• You have configured a chargerate of 13 kW.
• Your system only reports integer soc values.

Now, with a maximum chargerate of 13 kW, your system could mathematically charge 3.25 kWh per 15 minutes. 3.25 kWh of a 76.8 kWh battery is 4.23%.

Now, the scheduler has a certain plan, say it knows you are at 40% and the plan therefore would be to charge to 44.23%. This is now the “raw” target soc. (Before the introduction of decimal targets, VRM has rounded this to 44% for all system types). Now, the GX does the rounding, because it sees that your internal soc is only integer based. So far no change.

The next goal would be quite similiar, assuming it’ll be 48.x%, again a consecutive +4.23%

But what happens now is: Your system will charge towards that 44%. 1 minute before it reaches that 44% goal, it still reports a 43% integer value to vrm. VRM will update the schedule for the next window (which was 48.x%) and conclude: That system is lagging behind, +5% soc change is not feasible for the next window with a 13 kW chargerate. So, it’ll “correct” the 48.x% window down and it will be a 47.x% target now - and most the time rounded to 47.0, because unfortunately your rate/size combination has that “.23%” result.

while this happens, your soc flips to 44% - and your next window therefore only will be a +3% roadmap.

This repeats for every hour during charging. After 10 windows of charging, the scheduler has corrected 10% of soc-changes away compared to the initial plan.

Graph-wise, this looks like this: After the soc correction on each window (some seconds), you’ll basically “lose” 25% of the possible charge rate.

The problem is clear and needs to be fixed. We are already evaluating different options.

As a workaround you could increase your configured chargerate to a point, where that 1% down-correction then comes down to your desired +4% / 13 kW per 15 minute. (But this is only a workaround)

As long as an integer-based system will report “49%” even if it is 10 seconds before the flip to 50%, the scheduler will see it “lagging 1% behind schedule” and correct the upcoming window by 1%. And the bigger the battery, the bigger the impact of this 1%.

[kudos50]

@dognose

This repeats for every hour during charging. After 10 hours of charging, the scheduler has corrected 10% of soc-changes away compared to the initial plan.

This part is not entirely accurate. With the 4.23% the digits behind the comma per window are the same for every hour. Meaning I always end up with 3 x 15mins in which the full percentage goes down and 1 x 15mins in which it remains.

This can also be seen in the result versus planning. The planning is always about 15% per hour but the results is always 12%. 3% per hour for a 5 hour charge window starts to add up a lot quicker than 10 hours of 1%.

Glad you found it. UpCycleElectric happy but me and other Pylon users not so much. I will figure out some numbers to work around it until you come up with a fix thanks !

[dognose]

@kudos50

per hour for a 5 hour charge window starts to add up a lot quicker than 10 hours of 1%.

Absolutely right, it is 1% per window (except the first of all), not per hour. So, 10% in 2.5h.

(Corrected that)

[robmeerwijk]

I thought I had the same problem, so I switched from Battery BMS to Lynx Shunt for higher precision thus preventing the rounding error. That did not improver behaviour.

DESS charges only 1-2 minutes per quarter due to hourly SOC target communicated every 15 minutes

Update 3 — Switched to Lynx Shunt (decimal SOC precision) I switched the battery monitor from the Seplos BMS (integer SOC) to the Lynx Shunt, which reports SOC with decimal precision. Result: the stepping pattern disappears — charge power now ramps down smoothly and continuously over the 15-minute window rather than in discrete steps. However, the fundamental problem remains: every quarter, charge power starts near 7kW and bleeds down to near 0 by the end of the window. This rules out integer…