In my 3-phase installation peak shaving stopped working as well even when well above minimum SoC. I don’t know when it started. I currently run 3.70~93. I have 3 times Multiplus-5000/48, 48kWh LI-Ion battery, external grid meter CG EM24, and Victron EV-charger on AC-IN.
I programmed a NodeRed emergency brake. In case of grid current exces (28A) I switch charging from 16A to 6A. And in case of larger exces (32A) charging is stopped.
Settings related to peak shaving:
Grid meter: external meter
Grid meter required: yes
Peak shaving: Always
Limit system import current: Yes
Max system import current per phase: 25A
Limit system export current: Yes
Max system export current per phase: 25A
It looks like only AC-In is ignored. Just tested this morning. Peak shaving seems to work when my EVCS on AC-In is not charging. Is it possible that the new switch “Grid meter required” is implemented incorrectly?
I have literally been chasing this issue for over a year. We cannot reproduce it in testing. It shows up and disappears just as mysteriously. In the mean time, several issues have been found and fixed too, so we are never quite sure if this is the last one.
Specifically, this issue shows up, sometimes, when you have these conditions:
You don’t feed excess DC coupled PV into the grid (the Multi uses what we call “TargetPowerIsMaxFeedin” mode).
The system is charging the batteries, for example because the ESS mode is set to Keep Batteries Charged, or because DESS instructed it to.
You have a large load before the Multi, such that the AC current input limit configured in the Multi, plus the current drawn by the loads before the Multi, exceeds the configured limit.
The load is not so much that it requires feeding energy from the battery, or in other words, to shave the peak all that is required is to charge slower.
What the system has to do in this case, is it has to override the AC current input limit on the Multi so that it uses less current to charge.
In systems that does allow feeding in the excess DC coupled PV, a different mode is used to instruct charging, and the input current is limited by adjusting the power setpoint rather than overriding the AC current limit.
For this reason, it is important that I know whether the Multi was instructed to charge the battery at the time, and whether you feed in your excess DC coupled PV.
If you are running a 3.70 beta newer than v3.70~79, and you can tell me the ID of the site and the time frame where the problem was observed, it should have logged additional data that I can hopefully use to see what is going on.
First: it has always been working, even on earlier 3.70 betas, I didn´t change parameters. I don´t know when the problem started exactly, and I don´t have high resolution data on my Homeassistant or VRM to tell you more.
In the winter I charge at night mostly because of lowest prices, so I don´t expect that excess DC is the reason, but I checked: DC-Coupled PV Feed in excess is switched to on.
The system (DESS) was definitely charging the batteries. This used to be no problem.
I have EVCS (large load) before the multis. The problem is indeed when EVCS charges and DESS requires battery charging. Later, I saw peak shaving working, keeping L2 exactly 25A, when not EV-charging, only battery and some other loads on AC-out/critical.
Is definitely a yes. Slower charging was required to reduce currents to 25A.
I am running the latest 3.70 beta. The ID of the site is 421456. The time frame you can best look at is 14 feb from 4:00AM (Amsterdam time) to 8:00AM. You will see drops in current because of my nodered emergency brake, slowing down EVCS to 6A. I have set the emergency brake limits a little tighter to 26A limit so you will not see much high current exceeds later dan february 14th.
ps Since yesterday my system is not in normal working mode, because I am busy upgrading the batteries. So if you see some strange things (like only one of 3 battery active), that can be the reason. This did not effect the events on feb 14th.
Hi @robmeerwijk , I already found your site and confirmed that this is indeed not the same as the issue I described. Feeding in excess DC coupled PV is turned on, and this has an effect on the method used for regulation even when there is no sun.
I have now looked at data for your site going back to the beginning of the month, and I cannot find an example where it exceeded 25A for an extended period of time. It will sometimes briefly exceed the maximum, I saw 27A a few times, but that is perfectly normal. The control loop isn’t very fast, and it doesn’t have to be very fast. Fuses and breakers do not blow/trip immediately, unless you grossly exceed their rating, or you do so for an extended period of time.
What I would advise, since fuses and breakers are also affected by ambient temperature, and they do suffer a kind of ageing or metal fatigue if they are operating near 100% for long periods, is to use a lower limit for peak shaving than the absolute rating of the main fuse. Also, a breaker will usually trip before a fuse blows, and results in a lot less downtime.
Hi Izak, Before it used to be much faster than it is now. It always switched back to 25. Now the systems stays on 26A for long time and since I step up evcs 1A at a time as soon as current drops to 25A, it will not grow above 26. Earlier you could see battery charging dropping and EV-charging stepping up. That doesn´t happen anymore.
The reason that you do not see long duration overloads could be that I cut down EV-charging to 6A at 27A and switch of completely at 29A.
What I will do, is setting peak shaving at 20A so that I can safely test without blowing the fuses. The problem is that I have only one battery at the moment and charging is limited to 75A (0.25C) and minimum SoC at 60% so less testing opportunities.
I will come back with results, but it can take some time.
First results, peak shaving set to 20A, it looks like it works, but 1A off (graph by Home Assitant). No other heavy loads besides EV and batterycharging. E.g. heat pump did not switch on in this interval.
Looks like the EV was charging, and then at 2AM DESS instructed the Multis to charge. The peak is shaved to just over 20A, if you look to one decimal, L3 touches 21A once. So at this point it appears to be working correctly, although I do think something can be done to make it settle slighty under 20A instead.
It looks like the EV stopped charging at 03:18. As a result, the input power of the Multis is increased to 4700W each, which is around 20A at the 235V you have there, but DESS only wants the batteries to charge at 3.5kW at this point, so this results in only 6A being drawn from AC.
In short, I’m not really seeing a problem here. Not yet at least. I’ll keep looking into it, let me know if you see something again.
Hi Isaac, last night currents went up to 23A (20A limit set) for a longer period and spiked at 24A at around 2:15 Amsterdam time. This is what I observered like a month ago for the first time when I had the limit at 25A and emergency brake at 30A.
You can see the heat pump (around 2kW) active along with battery charging en EV-charging.
Still analysing the data but wanted to give some feedback. It seems that under these conditions the imported current is too high:
System is in discharged state (soc is/was below minsoc and had not been recharged to minsoc+3%).
The system is charging.
Once the system exceeds minsoc+3%, the import current goes back to acceptable levels.
In your data of last night that is what I see, the import current exceeds the limit from 02:15 to 02:25. Shortly after that the battery has charged to 63%, and the system re-enters self-consumption mode (even though it is still charging as instructed).
Not an answer yet, but I wanted to give some feedback.
Hi Izak (@iburger ) , right now the situation is a bit worse. I still have 20A limit in peak shaving. Actual values are 25A. Date and time: feb 27th, a little after 13:30.
I don´t know if you can still analyze my data. I am not on a beta anymore. It is 3.70 now.
Currents went even higher shortly after this screenshot. The nodered emergency brake intervened when currents are at 26A for a period of more than 30 secs. This procedure brings EVCS back to 6A.
@robmeerwijk do you have any other AC load meters in your installation? I’m currently seeing an issue where peak shaving is not taking into account the values for 'com.victronenergy.grid’ but instead is trying to keep the total POWER value of a 'com.victronenergy.acload’ of another unrelated VM-3P75CT (connected to the ve.can bus on my system) belwo the threshold of the configured Amps in peak shaving.
I can, Venus 3.70 is almost identical to the last beta you were running, so everything remains the same. I have an idea what the issue might be, but I don’t want to make promises just yet.
Hi Rob, could we perhaps increase the logging interval to 1 minute. It looks like you have it set up for 15 minutes.
On my side, there are heaps of data during some periods, sometimes just 5 seconds apart (it seems you are constantly adjusting the grid setpoint?), but then exactly when the data actually matters to me, I end up with just two data points, where I can clearly see something has gone wrong, but I cannot see how we got there.
At the moment the evidence says that the calculation for how much power to draw from the grid has a mistake in it. That calculation, however, is literally just “import limit minus what we’re already using”, which is obviously correct. So I still cannot work out why that offset develops the moment we start charging.
When EV-charing I do update the setpoint regurlay. In the past this was necesary in order to prevent the EVCS from draining the battery in stead of charing from grid or sun. I don´t know if this still is required. I tested this particular problem with setpoint fixed to 50. Did not change the behavior.
I switched logging interval to 1 minute. Do you want me to fix setpoint to 50 too? I will force charging car and battery this evening, because now and tomorrow there will be a lot of sun power.
Maybe this gives a clue: It used to work as a breeze. As far as I can see two things changed. One on my side, one on your side.
On my side I swapped my old CG-EM340 (RS485) with the current CG-EM24 for stability reasons. I was constantly loosing the connection and the system went into passthu all the time. That is solved now.
On your side: In 3.70 you switched to internal MP meters in case of lost grid meters. I contested that, because I prefered passthru, since I have heavy loads (EVCS) on AC-in. https://community.victronenergy.com/t/venus-os-v3-70-61-available-for-public-testing/45708/260?u=robmeerwijk You implemented a new setting in the console, “Grid meter required”. I have this set to “Yes”. Maybe there is bug in there? Are you looking at the wrong meter when external meter is set to be required?
I have been playing about from 23:00 Amsterdam time until a little after midnight. It turns out that the battery actually responds to heavier loads. And sometimes even quickly. The difference seems to be that sometimes the currents are steered back to the set value, and sometimes to the set value with an offset of 1 to 3 Amps.
The next 2 or 3 days my system will be unavailable due to a battery upgrade. I hope you have enough data now to find the cause!
PS correction: at 1:07 the heatpump kicks in, leading to enduring 24A (4A above limit)
