But why the difference, legacy SoC in 3.80 beta and TargetSoC in 3.70. That is a bug, isn´t is?
I changed two more parameters. I brought DESS setting battery capacity down from 48kWh to 44kWh, forcing a little higher SoC increase during trading. And I upgrade MP2 software from 552 to 558. Charging seems more constant at 130, as intended.
Hard to say with certainty without an a-b comparison test that pinpoints it to a singular cause. It is always the hard part, when trying to analyze faults in complex systems, not to vary more then a single parameter at a time. Here we touched upon so many parameters already: VenusOS versions, DESS core power/capacity settings, BMS SoC accuracy and behind the scenes VRM DESS schedule alignment updates.
That said, if reverting to v3.70 release, having better SoC precision and re-evaluating/tuning the core power/capacity settings result in restoring a stable operating range, that’s a win. There might even not have been a single bug at all, just a series of changes on pretty much all individual system layers that in total led to an edge case instability. The firewall test pointing to the trigger: the re-alignment efforts of the scheduler. But the cause more likely a side effect of the legacy edge case handling in VenusOS that was required to deal with integer SoC precision before the higher precision capability was released.
What would be helpful is an updated DESS tuning manual but asking for documentation updates is whole other can worms all together. 
Just checked on a system running the latest beta, which has precision of 2 digits:
0: 11.11
1: 11.22
2: 11.22
3: 11.48
4: 11.74
5: 11.99
6: 11.99
7: 12.29
8: 12.58
9: 25.54
In one of the next beta’s in 3.80 we are going to drop the legacy Schedules/../Soc field.
I there an equivalent to that to populate that JSON with all (but the SoC%) values from a BMV-712 Smartshunt? With a ‘standard’ Victron input node if at all possible to avoid another transport layer such as MQQT. It’s been a while but I remember somebody managed to read raw data directly from the BMV’s ve-direct/serial interface with even higher precision but I forgot how. That would be killer function if it could be achieved ‘officially’, and not only for BMV’s but GPS and other peripherals as well, that are automatically added to the D-BUS. I know it is possible with specific scripts but that I rather leave VenusOS clean and ‘supported’.
Discharging is stable now. Stil some dips almost every quarter, but this wil work! The system will be able to reach the targets.
I decreased the size of the DESS capacity by 10% and I followed the suggestion of @UpCycleElectric (Jan) to create a virtual battery. I adjusted the Lynx Shunt parameters. SoC comes in a decimal value from the Shunt, the rest comes from the Seplos BMS.
Tomorrow I will report back the charging results of this new config.
I made an Excel sheet that shows exactly how the VRM scheduler takes the roundtrip efficiency into account. Let me know if/when you are ready to do some fine tuning of your DESS settings.
Where does this difference come from? At least one system displayed integers in 3.80~4 (mine). However, if the integer variant is being phased out, this shouldn’t be a concern in the long term. For now, I’ll stick with version 3.70 (hopefully upgrading to 3.71 soon with peak shaving support) and won’t participate in beta testing.
Charging now shows a flat profile at 7 kW, exactly as intended. Thanks to everyone for the help!
However, I still feel that fine-tuning these parameters shouldn’t be this difficult. Most users don’t want to go through the full process — and as we know from, for example, heating systems, most installers won’t either. They install, switch the system on, and leave. And it used to work, more or less without finetuning.
A drawback of progress I’m afraid, the integer SoC D-BUS implementation required quite an extensive set of edge case handling routines to compensate for the lack of presicion and still perform reasonably well for most use cases (see the list of reactive strategy cases for instance). My impression is that those routines allowed for a much larger margin of error on the power and capacity settings. The new (semi) float TargetSoc precision brought substantial improvements to the whole systems accuracy, controllability and predictability, especially for large capacity systems like ours because it reduced complexity not having to rely on the complicated edge case handling anymore. But at the cost of less masking of lingering settings issues. You may have to blame me for advocating the loudest for this precision improvement but I guess I made up for that a bit by now. 
