I’m not so sure there is a single root cause here, I see it it more as multi domain problem that shows instability when several correction processes start fighting each other.
You can just use the input of the virtual battery. And inject a json object containing all the paths + values into that.
I know i can input it like that.. its just to get all the values out of the smart shunt either needs a lot of read nodes, or I might make a wildcard subscription on the MQTT values and do some mapping in a function. Just wondered if there was an easy fix, but I guess there never is 
Overwriting the existing smartshunt soc value will probably also give conflicts.
You should check your battery size in VRM (DESS) if its correct. Maybe share all your DESS settings.
It is trying to reach the target soc, if the battery size is incorrect (smaller than in VRM) it might reach that much faster than calculated, therefore the MP ramps down.
You might want to up the DESS power limits until you get the system to reliably max out it’s capabilities then start tuning down the grid (AC) limits. If you discover you have to set AC limits more than 5 to 10% too high, for the scheduler to plan enough energy transport to keep going at max power, you could lower the overall efficiency (via Node-RED) for fine-tuning. For a multiplus I think 80 to 85% aligns the scheduler much better than the 90% (all round-trip) I think the default setting is. Once you get within 5% between actual and scheduled, you are pretty good already, further fine-tuning is possible but might involve a voltage corrected SoC adaptation because VRM assumes SoC linear to energy (kWh) not amphour. Not too critical for Li-FePo4 but very helpful to do so for Li-NCM.
Battery size is set to 912ah in Lynx Shunt, in MP2, in Seplos BMS and in VRM. And it used to work. If you have read earlier reactions above you can see that VRM is correcting values after aproximately 1,5 minute. When disconnected by firewall from VRM there is no problem at all.
To all, I feel that this post is losing its focus (my problem) that there is a correction coming from VRM every 15 minutes approximately after 90 seconds, slowing down charging so much that my battery never reaches the planned SoC.
I am pretty sure all my settings are correct. It has been working like this for two years. The problem is recent. And I hope Victron can solve it.
| Time | Target SOC % | Note |
|---|---|---|
| 15:45:04 | 83 | Quarter target |
| 15:46:19 | 82 | VRM correction: −1% |
| 16:00:04 | 83 | New hour, quarter target |
| 16:01:19 | 0 | Missing data or reset? |
| 16:15:04 | 85 | Quarter target |
| 16:30:04 | 88 | Quarter target |
| 16:31:15 | 87 | VRM correction: −1% |
| 16:45:04 | 91 | Quarter target |
| 16:46:15 | 89 | VRM correction: −2% |
Yeahb
Yeah I read that, it’s an issue that is hard to truly pinpoint what is root cause and what is a side effect without diving into all the settings and variables involved. I first solved it with a different approach that manipulates the D-BUS schedule itself (I selectively time shifted targetSoc up 15 minutes) but after multiple rounds of fine-tuning everything else, I could stop doing that. I guess what I’m saying is: it got complicated quickly as long as the basics were not fully understood and tuned (by myself). And at first the more frequent VRM correction updates made things more noticeable. But once well tuned it can work satisfactory.
I do concur there is something that changed related to the VRM schedule updates that made the system significantly (as in 4 times) more sensitive to over corrections by the VRM scheduler.
I find it strange that your target SOC seems to be in steps of 1%. With your 912ah battery that is about a half kWh per 1% (with 7kWh/4 quarters = 1,75 kWh per quarter that will not give a lot of precision).
If i look at the target SOC’s on my machine they have 1 digit precision.
A correction from VRM of 1 full percent will have a huge impact then
I really appreciate your effort and help (as before). But I wouldn´t want to go that length. I expect a working system from Victron. A bit tweaking is ok, but there are limits. I don´t have strange parameter settings, I believe.
Maximum inverter power also 7kW
Maximum charge current 130A (approx 7kW)
912Ah in Lynx Shunt/Seplos BMS/MP2 VEConfigure
DVCC is not interacting (checked that) nor CV-phase throttling
And there is proof of the intervention of VRM 90 seconds after the quarter, consistently. So there is the problem.
Settings look fine to me.
I think there is something wrong with your target soc precision, not sure why. It should be 1 digit precision (i think that was one of the things they fixed lately to increase that precision).
I could go back to 3.70 but @nickdb pointed out to me that the venusos release is not relevant for the problem. But I will try anyway. Maybe this bug was reintroduced in 3.80 beta?
Actually spot on!
Mar 9, 2026, 16:15:04, 85
Mar 9, 2026, 16:30:04, 88
Mar 9, 2026, 16:31:15, 87
Mar 9, 2026, 16:45:04, 91
Mar 9, 2026, 16:46:15, 89
Mar 9, 2026, 21:29:26, 55.96
Mar 9, 2026, 21:30:04, 59.43
Mar 9, 2026, 21:31:19, 59.46
I reverted back to 3.70, switched logging on, and watch, decimal values! And the VRM updates no longer go down, but up.
If you are willing to try a small experiment, try swapping grid power limits and battery power limits. I know that sounds counter intuitive but how it works for the scheduler is that it schedules against the lower limit(s) anyway, having the grid (AC) limits define that lower limit will elevate at least some of the rescheduling problem because it allows room for solar and load differences on the DC side. So if the inverters can deliver max 7kW AC feed-in, set it so, and takes max 7kW AC to charge, set that as well. Then the battery charge can stay 7kW DC or higher because of the losses, but discharge needs to be 8kW at least, due to losses as well. DESS calculates the SoC schedule with losses accounted for based on the set efficiency. There is more to it then this but maybe someone from Victron could provide better guidance on this specific topic.
Here are the DESS Trade settings that work good for me. 1 x MP-II 5000 plus 1 x 8kW boost charger (Node-RED controlled to act as a slave charger to the MP-II). System maxed out on a single phase 230Vac 35A mains. Battery / DC DESS power limits don’t matter too much as long as they are higher than Grid/ AC DESS power limits. What makes this system well behaved is the fine tuning of the total capacity in kWh, a virtual battery with high precision SoC calibrated to report State of Energy% instead of State of Amphours% (much less relevant for Li-FePo4 with it’s flat voltage behaviour) and these DESS settings to go with that. Oh and 83% roundtrip efficiency set via Node-RED.
you will still get corrections from VRM.. but the impact will be a lot less (0.1% min instead of 1% min steps).
First I try to stay at 3.70. Peak shaving doesn´t work yet. But I hope my problem is solved for now. Apparantly a former fix was undone in 3.80 beta.
You could be onto something here, or this could be due to selecting the other BMS/Shunt as main battery monitor.
@dfaber It looks like target SoC coming from VRM lost digits in the current beta. Maybe you should look into that.
0.01% even. As far as I understand, the battery monitor SoC precision determines the precision used by the system. VRM has always scheduled in float precision by the way, the change is on venusOS, specifically the schedule in the D-BUS using either legacy SoC (int) or TargetSoc (float upto 2 digits).