here my annotations:
- System: assuming 3-phase 25A fused: set maximum import and export power both to 17.25 kW. Set to Trade mode.
- Battery: capacity set to actual useable dayly cycleable capacity, 48kWh is that is the case
- Maximum discharge power: set a little higher than the MP II’s combined maximum inverter power, so 3 x 5 = 15kW
- Maximum charge power: set a little higher than the MP II’s combined maximum charge power, so 3 x 70A * 52.8V ~ 11 kW
- cycle life: (just for easy of calculation: price €4800, cycle life 1000 cycles (i’ll explain another time) should give €0.10 €/kWh
- Battery balancing off (well , to be controlled by the PFCO flow later)
- No other restrictions (for now)
- Buy prices and sell prices same settings, the difference is now taken into account with the cycle costs (real or imagined). Tibber does (p+0.0205+0.10154)*1.21 flat rate, also negative, zonneplan I don’t know for sure but I don’t expect negative prices during this test so just set to the same (p+0.01653+0.1088)*1.21 or do check here in the forum for an update on the actuals
- Cerbo minimum SoC 10%
- Grid setpoint 0W (no use if you do not need to ‘hard’ prevent feed-in
- No other limitations, no peak shaving, no scheduled charge levels (won’t work anuway, this is why I use the Node-RED DESS b_goal_SOC and b_goal_hour instead.
- AC-coupled PV feed-in excess: That I do not know yet , lets try without that setting for starters
- ESS Dynamic ESS, looks confusing that target SoC reads 0% but is very likely that the system is in ‘1 - self consumoption’ at the time you took the screenshot
- Charge control DVCC: I have no experience with that, if your batteries are well protected by their (JK?) BMS AND if you could add a BMV 712 Smartmonitor instead of using the BMS data, I would very very strongly advise to do so. JK SoC calculations are horrible while the BMV 712 is near perfect. And with 48kWh total capacity, ~ 938Ah you should be able to to at very least 0.2C is 188A and 0.5C is 469A, depending on the combined limits of the JK mosfets. taken the max discharge power from the MPII’s into account, 15kW, I’d set (15/48*938=) 293A rounded up to 300A (assuming no other DC loads/chargers , only the three MPII’s)
So that for starters. Thebn for the first day or two just use the VRM DESS Battery settings to turn balancing ON in the morning a couple of minutes right before the price drop (usually 9, 10 or 11h) and then back OFF again of few minutes before the price shoots up again (usually 16, 17 or 18h) and possibly reduce the total hours not to overcharge from grid when the solar production forcast is high. The best timing is what we will try to automate with the Node-RED flow later. But running it manually for a few days will provide valuable insight how the whole system will respond to the PFCO ‘intervention’ Do not mind what schedule VRM is showing with PFCO switched ON, it will correct back to normal when switched OFF again.
Report back after a couple of days with screenshots of how the system behaved in this Trade mode setup.
PS, the only setting to ‘test’ in these few test days should be the effect of point 12: AC coupled PV feed-in excess. More for me to get to know how that acts than anything else.
Also, do not worry (yet) about small duration overshoots in charging and discharging around the new hour, that can be fine tuned later. What we are looking for is the overall behavior over a full day, in Trade mode, with (for now manual) intervention to charge extra from grid when prices are low. The goal is to target full batteries around or a bit past dinner time, when the grid prices shot up high and the sun goes down.
And you do run VenusOS large beta don’t you? If so:
- Import the standard Node-RED DESS flow from Victron
- Disable that automatically activated inject node that switches on DESS mode 4 (top left) to make absolutely sure it stays on DESS mode 1 : auto (= VRM DESS)
- Copy over all settings described above except the price formulas, make that p*1.21 as this will make the https://venus.local:1881/dess page display pure market prices (including VAT) which makes for much easier interpretation)
- Additionally you may want to change the timer inject node (top right) to inject on the exact hour and then every 3 or 5 minutes, instead on a 3 or 5 minute interval from first injection.
- Finally: do set a reasonable b_goal_SOC of around 85 - 90% at 18:00 or a little later say 19:00 deppending on the amount of solar production at the end of the afternoon.
- Then compare the Node-RED schedules with the VRM-DESS schedules during the day. What you are looking for is how well timed (or not) Node-RED DESS schedules (but not actively driving DESS because that is still done by VRM DESS in mode 1 : auto) to charge your batteries, compared to what VRM DESS is actually doing (helped by the PFCO intervention). Once you get to a point these schedules become pretty predictable to you, we can work on the automation of the PFCO intervention.
And to satisfy my OCD: try to replicate these graphs on the VRM Advanced page (don’t worry about the MP temperature, I mounted the battery temp sensor on the MPII’s toroid transformer to get an impression how it holds these warm days):
Thanks Jan for your detailed info.
My dynamic pricing contract started today! (a nice day to start with those high rates in the evening 
)
My consumption is around 12 to 16 kWh a day, no real peak hours.
Solar yield for the last 1.5 years:
yield is much higher this year compared to last year. Wonder if cleaning the panels a couple of months ago made this possible…
Adding solar to your system for tax recoup only still works for a year or so. After ‘saldering’ stops I guess selling to grid gives no tax refunds anymore.
But solar is cheap these days (the panels I bought in 2022 are now half the price 
! )
I don’t understand why people complain about ending ‘salderen’.
I’ve set the system to trade mode now, and calibrated my batteries a bit so will see what that does tonight.
Batteries are three JKBMS manged boxes each with 16 313Ah cells. JKBMS configured according to Andy - Off-Grid-Garage settings.
I run venus large 3.62
No time yet to setup all your wishes
Will do that in the coming days.
12: ACV PV feed-in is switched on. It will use any surplus to charge the batteries first and further surplus will be send to the grid.
Result of the first day (but not all suggestion implemented)
Forecast:
Actual:
Between 22:00 and 23:00 discharging stops while soc is at 33%.
I do get low battery alarms, nut dont understand why. The highest cutt-off value is 52V at 0.005C.
Alarm graph:
So forecast is to use battery through the night, but it actually uses grid. I think tthat has to do with not discharging below 40% Soc. And that on itself is probably casued by the (dynamic) cut-off values. I just left them as in the eSs assistant as recommended by victron for the lifepo4 batteries. But I thinkt he values are to high. Cell voltage at 40% soc seems to me 3.24 or so, hence around 52V for the whole battery which is equal to the cut-off voltage at 0.05C. This matches more or less with the low voltage alarm. See below advanced grpah.
I’ll update the ESS assistants on a suitable moment (as I understood the will restart the MP2s so loose power for a short while…).
What cut-off settings are people using her for 16 cell lifepo4 batteries?
With this probable cutt-off issue the test are not usefull as things will misserably fail when reaching the lower SoC range…
1 Like
For my BYD and Pytes batteries, I have DC input low shutdown set to 47V, DC input low restart and DC input low pre-alarm set to 51V, as per the recommendations.
In the ESS assistant, Sustain voltage for the BYD pack is at 50V and Dynamic Cut off voltages are set to 47V, also as per the recommendations.
For the Pytes pack, recommendations are 51V Sustain and 49V for Dynamic Cut Off.
1 Like
Thansk Bart!
Where did you find recommendations for such batteries. I tried to look for it but all I can find are a few post where it is discussed a bit but no real guides for Lifepo4 batteries…
Here is a guide about LiFePO4 batteries with recommended settings for Victron chargers / inverters: My Settings – the Off-Grid-Garage
The guy also has a YouTube channel and does a lot of experiments and research.
Thanks for the pointer Hans!
Ah Andy, our German Australian
I seen most of his videos and use his recommendations for the JKBMS settings. But I do not see any MultiPlus inverter and ESS assistant setting recommendations (espceially the cut-off and sustain voltages) there.
Adsorbtion and Float voltage is most important as it will determine if the Battery gets properly balanced while not stressing it too much.
Low voltage cutoff will be managed by BMS but you can set 48V for a 16S battery to prevent discharging below 10%.
And Sustain - well, I’m using 49V for my Pytes 16S LiFePO4 (48100R-C16).
These are actually for victron supported batteries. It helps but I have a IDY battery. Anyway,
there is another topic on this that helped to figure out what I need. But still thanks Bart!
These parameters can be used for most 16S LFP batteries, as the LFP cell properties are more or less the same for every vendor.
I am using the ESS assistant settings from Configureren van de Multiplus voor Lithium Batterijen - Qion
Discharge to 20% :
0.005 C = 51,0 V
0.25 C = 50,0 V
0.7 C = 49,5 V
2 C = 49,0 V
Sustain @ 49,0 V
Discharge to 10%
0.005 C = 49,0 V
0.25 C = 48,5 V
0.7 C = 48,2 V
2 C = 48,0 V
Sustain @ 48,0V
And I have been following this thread, pondering how to combine trade mode & green mode.
I “think” trade mode is right when it draws energy from the grid at night when there is not much energy being used. Efficiency at low power is very bad. I draw ~1kWh between 00:00 and 08:00.
But on the other hand ESS thinks my consumption is 0 between 23:00 and 02:00, only setting strategy=1 after 03:00.
I like 0 grid usage and, like UpCycleElectric (kudos 
), I feel this needs a fix.
First I feel the rounding is a bit off. When I enable the node-red (or VRM) trade-mode ESS, the target SOC is always off from current SOC, between 1 and 0.1%. This results in a forced discharge on high SOC, and a forced charge on low SOC.
Second (and this has been asked before) both Trade and Green-mode discharge until minimum SOC. We could use a “trade until” SOC after which the system could switch to green-mode for self consumption.
For the first one I made a workaround in the node-red ESS flow on the cerbo:
Add a SOC node and a solar production node to the ESS pane:
And edit the “Split schedule 0 node” adding this in between the node.status... and return ..
Effectively telling ESS when the SOC change is less then 1%: just use green mode, unless there is enough solarpower to cover your needs (250W in this case).
At night it will run green-mode but during the day it will still feed in exess solar.
(I am actually testing this right now so it might receive updates.)
var battery_soc = flow.get("battery_soc");
var solar_power = flow.get("solar_power");
if (solar_power < 250) {
if (msg.soc > battery_soc - 1.0) {
if (msg.soc <= battery_soc + 1.0) {
msg.strategy = 1;
}
}
}
For the second one I like Jan’s solution of increasing minimum SOC in the morning and lowering it again in the evening but I did not add it to my flow just yet.
Keep up the good work everyone!
Thanks. Our hybrid DESS Trade approach (a) runs somewhat ok-ish for a while now, but,…
It took an enormous amount of time and effort learning, monitoring, developing, implementing, testing, changing, tuning and refactoring to get to a point where we hit a brick wall. I don’t like to say it but the bottom line is that the current DESS implementation, even (or at least) for the most simple and practically deterministic test case of a stand-alone trade only ESS, is fatally broken.
On the highest level (b) it does not provide enough choice to set up a basic trade strategy to match context specific requirements and goals for the schedulers overall goals and plan, on an intermediate level (c) there are no clearly defined, safe and supported ways to make tactical adjustments to the schedulers execution of that plan and on the lowest level (d) the actual logic behind the scheduling implementation is hidden in the cloud and to some extend in the inverters firmware (assistants).
That said, we did manage to implement a functional trade strategy with the help of Node-RED to get the system to do what we want but by the time we arrived to a solution that can be left alone for days on row without making any obvious mistakes, we basically had to learn so much about the intrinsic design and implementation details, that it has become easier and one could argue even better, to turn off DESS all together and run our own scheduler.
With in mind that neither solar production (none) nor self consumption (smaller than the heat losses during buy and sell runs) play a role of importance, THIS is why I say that IMHO DESS Trade, as-is, is fundamentally broken. It requires the end user to adjust to the system instead of the other way around. And as long as that is not addressed with a serious review of the system as a whole, I have a hard time imagining the even more complicated DESS Green solution with substantial solar production will do any better. Maybe I’m mistaken but I am not investing more time into it until I see signs that a systematic redesign is being considered. Again, I don’t like to say it, but I have come to a strong suspicion that something is fundamentally broken on the highest functional design level, that cannot be fixed by adding more bells and whistles to the, already impressively complex, implementation levels below. My suggestion to the architects of DESS would be to focus first on making the most deterministic use case (pure trade on dynamic prices) function good enough to run autonomously without missing glaringly obvious trade opportunities. Use the resulting pure trade schedule as a baseline add an option to add in a strategic deviation from that schedule to facilitate secondary objectives that require dealing with larger uncertainties, be it grid black out conditions, solar production, irregular high power consumption (EV’s) etcetera.
(a) DESS Trade active running in mode 1 : auto combined with running the Node-RED scheduler in parallel but inactive to make use of it’s b_goal_SoC and b_goal_hour functionality
(b) User settings in the primary interface, VRM DESS settings in this case
(c) API access and Node-red flows to implement additional strategic control parameters, logic and the technical means to override the active scheduler’s actions
(d) Design, code, data and documentation of what goes on behind the API in the cloud, and within the assistants on the inverter.
After resetting the cutt-off voltages things seem to work a lot better for me. @snowwie: I’ve set the values a little bit lower than your suggestions, more like settings for almost 0% SOC
I must say I was ‘just’ following the victron ve.configure guidelines: set battery type to lifepo4 and left the cutt-off values as proposed by ve.configure . The text around it mentions that “these values normally should not be changed”. I guess that is a bit misleading. They should changed that as youapparently need to adjust those values to your setup!
Anyway I turned back to green mode for a couple of days now and am reasonably happy with the outcome. No more grid intake and battery discharge actually at the highest price periods.
The only thing that coulb be better is to make sure SOC=100% around sunset. It often is around 90 to 95%. I hope that Jan’s flow to force flow with target SOc and hour will improve on that… Have to test this still.
