Hi, when my Multiplus 2 connected to my Cerbo GX MK2 is going to feed into the grid at high prices, it does not or very slowly react to loads. Normally it regulates within seconds to 0w, really can’t complain about that. 4kW is regulated within 2 seconds or so.
But the issue starts when it wants to deliver back to the grid at high prices. It takes like two minutes before the Cerbo lets the Multiplus 2 reach its target power. Within that time, it seems like it does not react on loads. Usually that’s a short period(those 2 minutes). However, sometimes the grid setpoint isn’t it’s max power, and its hoovering around -100w. This is going on for an hour. During that time it does not or at least very very slowly react to loads. So if I start using like 500w, I’ll pull 400w from the grid for several minutes at expensive prices, while it should feed in during that time. For me it seems like the Cerbo took over the grid/load regulation to do the grid feeding, and that seems to work very slowly. If the Multiplus was given the task to feed in that 100w no matter what, I recon it would work way, way better. I mean regulating to 0w works ± 50w within a second, regulating to 100w should work as quickly. Any ideas about this?
This is usually defined by the grid code standard, is set (conservatively) for grid stability, and something that you will probably just have to live with.
Let me explain: the grid code may say you can only ramp up in no less than 10 minutes. This means the feed in should ramp up in 10 minutes from 0 to 4000 w in my case. Agree? Well, me to and I won’t complain. HOWEVER, now it has a very laggy PID loop to react to loads during that time. The Multiplus can do way better and that would be way better for the grid as well. If the Cerbo would send a setpoint to the Multiplus with increments of like 10w in a rate it would reach 4000w in 10 minutes, it stays in control just like normal, while being compliant to the grid code and doing the same as now but way more refined.
I get why you say it’s because of the grid code, but the grid code is about the AC in of the Multiplus, not the AC out. I’m running everything from the AC out, between the grid and the AC in are no loads. So if I switch on a load of 2000w while it only ramped up to 300w, it should immediately regulate to 2300w which still is 300w to the grid. Which it doesn’t right now.
(I’m sorry if I sound angry, please don’t take it personally)
Hey - I agree that it would be better for the grid and us to have much faster response times, and NOT pass sudden switching loads onto the grid.
Also, I think that prohibiting export from DC is self defeating - this is specified in some grid codes.
Without exact details on the diverse grid codes - something that I don’t have time to study and correlate at the moment - I’m just relating on a few things that I’ve picked up in the last few weeks.
It would be nice if the Battery inverter could Isolate the grid from any switching loads and just change the AC input at the specified slow rate, but allow the Ac output to pickup the new loads from battery. I’m not sure that this scenario would be covered by the acceptance testing.
An idea>> Use 2 inverters in series, with the one connected to the grid using the “official” grid code, but backed by a second inverter with much faster response time to pick up the switching loads?
I’ve looked way closer today. The case right now was it’s delivering about 1000w into the grid and I’m starting my microwave at 1700w. It’s 7:30am so no ramp up or ramp down is happening.
Instantly on enabling my microwave, the Multiplus output power jumps to 2700w, just like expected. But then, the Multiplus starts dropping power quickly and goes to like 1000w, and using 700w from te grid. Then when my microwave stops, the Multiplus jumps to 700w CHARGING and then proceeds to start delivering back to the grid. So this has nothing to do with grid code, it’s all done on purpose by Victron. But why? My only guess would be low battery SOC, I’m at 13%. But still then, it wants to export 500Wh in the next 30 mins so you’d think it’s smarter to prioritize keeping up with the load, and stopping any more export.
Now for me it’s less than 1kWh lost this year, but I’ve seen people on this forum losing more than that per day. I mean if I pull 3kW from 7-8am I’ll loose 2kWh at highest prices.
Your idea of two inverters in series does seem to be a solution, but I’m too broke to buy a second multiplus. Also, the extra no load usage will defy any gains I’d get out of the setup unfortunately.
Hi, in an email conversation I had with my Victron supplier on the subject of ESS, he stated :
“Mode 1 will be restricted to a rate of change no faster than 100% over 6 minutes”
This means that the Grid code is specifying how fast a battery inverter connected to the grid system can change its power, resulting in exactly the behavior that you are seeing. I do not see this as advantageous either to the user or to the grid. It has probably been specified by a group of people who don’t use these systems and don’t understand how they work OR how they can be made to work to improve or sustain the grid most effectively. I’m sure that this is not a choice that Victron would make for themselves, if they had the choice.
My feeling is that improvements to the grid load stability would occur if the load on the grid (AC in) changes at the specified rate, and the inverter internal take care of the needs of the loads and the battery.
So if you are running a load of 1700W, and have a grid set point of 100W, then the battery would be sourcing 1600W in steady state. If you then turn the load off, the battery starts charging at 100W, and the grid does not notice any change.
I’ve not seen the actual specification to read the exact phraseology, and interpret the required behavior.
I have managed to get a copy of the amendment to the AS4777:2020 standard, and that includes the following:
so it looks like it’s the test methodology applied by the standard that could be at fault, in not connecting the site load to an independent port of the inverter, but can’t currently confirm this. Victron inverters probably qualify as “Independent supply inverters” as they can operate without the presence of the grid. The standard prevents this type of inverter from exporting power from DC to the grid (Sucks) but probably does NOT alter the test method - even though this is not the way most inverters will be installed. This then limits the rate at which the inverter can change power - irrespective of where the load is connected.
The net result of this ‘oversight’ is that if everyone installed systems that are so sluggish to react, but reduced the grid load to net zero, then all the grid would see would be switching transients (both on and off), with no base load.
Thanks for your deep dive! This would be as expected. The grid is indeed not noticing anything. Only in the 6 minutes we get that sluggish behavior which we should live with I guess.
But when the setpoint is not max power (for example 1000W export) it prioritizes grid over battery.
The state was:
MP: 1000W Load: 0W Grid: -1000W (export)
MP: 2700W Load: 1700W Grid: -1000W
But then while the load was connected, within 10 seconds:
MP: 1000W Load 1700W Grid: 700W (import)
So the first two lines are exactly what we want, but then Victron decides he doesn’t want to use more power from the battery and ramps down again, resulting in grid usage. It seems like the MP acted quickly on the load but then the Cerbo was like: HEY WHAT ARE YOU DOING WE CAN’T AFFORD SO MUCH POWER, GO BACK TO YOUR 1000W!
I’ve encountered a very similar issue as you did, right after connecting an external current sensor.
At first, I thought the problem was caused by the sensor itself, since I hadn’t observed this behavior before. So I created a separate post about it. But later, after switching back to the internal current sensor, I realized that the issue still remained.
I tried removing all unnecessary Assistants — that didn’t help. Then I created a temporary workaround in Node-RED that triggers a VE.Bus reset, but it had its own drawbacks.
Eventually, after digging through the grid code settings, I found the parameter responsible for this behavior: “Power rate 100% per 600 s”, and I temporarily resolved the issue by changing it to “Power rate 100% per 0 s”.
That seemed to fix the problem, but I’m concerned that changing this parameter may not be allowed officially by the grid operator.
So the question was raised whether this is possibly a firmware issue, since the standard describes this functionality a bit differently — and it may not be implemented exactly as expected.
More details here: