question

strix avatar image
strix asked

VRM DESS prefers grid power over available solar when battery full

My PV arrays were commissioned about two weeks ago. It was gratifying indeed when, on the first decently sunny day to follow, the 3.5kWp south east array peaked at 4.2kW output and produced 13kWh, and the 29kWh-worth of batteries were full by noon (summer time, so an hour before solar noon). Production fell off after that (NW array 4.5kWh max 1.6kW), but I wrote that off as changing weather, and I never expected the NW array to perform as well as the SE array, anyway.

But I got curious when the same pattern followed the day, this time at 10:23am. On closer examination I noticed that, as SoC approached 100%, solar production abruptly collapsed to a third over the space of a few minutes, then decayed to a tenth over about half an hour. Shadows recorded by CCTV ruled out changing insolation as the culprit.

And I noticed that the house was drawing power from the grid, despite plenty of capacity to supply household load from PV.

The marker is at 10:23am when production first collapsed. Notice that Charge Current Limit falls to zero after that half-hour period.

DESS behaviour as SoC approaches 100%

It was also charging the battery from grid power before this point and, though undesired behaviour, that's in keeping with how the DESS algorithm is meant to work, especially given lack of historic PV data.

But preferring grid power over available solar is a problem.


I had turned DESS on when the arrays were first commissioned because I judged my previous overnight scheduled charging strategy to be inadequate, so that seemed a likely culprit.

PV production immediately increased to substitute for grid consumption when I turned DESS off. The graphs don't show it but, I turned DESS back on, production fell and grid draw resumed, just to prove that it wasn't coincidence.

I turned it back off again for good at about 12:53pm, where you can see PV production rise and grid draw fall back to its 50W set-point:

PV generation restored after disabling DESS


On first glance, it appears that DESS logic considers only BMS demand when setting MPPT parameters, but it does appear to be giving some regard to AC demand. For some reason, it seems to evenly divide AC load (c. 800W) between grid and MPPT output, which seems illogical.

The jump in production at about 2.25pm, reflected by grid power going negative, is the point at which I enabled "feed in excess". I haven't tried DESS with this enabled but, even if that works, there's still a problem for those who aren't allowed to export.


Since disabling DESS and enabling excess feed-in, this plant's record daily figures have been 35kWh generated with SE and NW arrays peaking at 4.2kW and 2.6kW respectively, with production routinely limited by the MPPT's maximum battery current (though never for more than a few minutes at a time).

When I get time, I will install the NodeRED implementation and see if I can figure out what's going on if the problem recurs. I always needed to do that anyway because, at the least, neither Octopus day-ahead nor time-of-use pricing are available (yet?) in the VRM implementation. Still, I had thought the VRM implementation would have gotten me fairly close. Instead, I am relying on scheduled charging.


Plant description:

  • 2 × 3.5kWp arrays (azimuth SE & NW)
  • MultiPlus II 48/5000/70 GX (firmware v3.14 and v508)
  • SmartSolar RS 450/100 (firmware v1.16)
  • 6 × Pylon US5000 (28.8kWh total nom.)
  • VRM ID c0619ab299aa
  • Pylon BMS connected via CAN, MPPT connected via VE.Direct
VRMbug reportdynamic ess
1 comment
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

strix avatar image strix commented ·

Further to this, I've just seen that Venus v3.31 includes the following bugfix:


> Dynamic ESS: fix bug where PV from grid-inverter was fed back into the grid rather than used to charge the battery, in certain conditions.


That sounds similar to, but is not exactly the same bug as I'm reporting here. Still, v3.31 might have fixed it anyway, can a dev comment please?


Thanks,


S.

0 Likes 0 ·
0 Answers