A friend of mine decided to install a parallel to grid tied ESS. He bought one cerbo GX, 2 pylontech US-5000’s, 1 multiplus 48/5000 for L1 and 1 multiplus 48/3000 for L2, one lickx distributor and a 3 phase gridmeter. While starting up the system and connecting the VE-bus on cerbo/MP5000/MP3000 we soon discovered that there was a conflict on the VE-bus using multiple MP’s and especially 2 different ones on one bus. Reading some documentation we discovered that is is not possible to create a 120° split phase if not using a pair of identical models. He also has a MK3 interface for configuring de MP’s by laptop so we tried that on the cerbo to create a second VE-bus and both drives appeared simultanious in the remote consoles device list. The documentations now sais that in this configuration only one MP can work as an ESS. Not ideal. I see a few directions we can go from here. 1.) Place a second GX device for the second MP but than how to share the gridmeter (rs485) and battery data (can-bus) on both GX devices? 2.) Setup 1 MP as ESS and write the needed PID controller in NODE-RED for the second MP. The goal is the charge/inject over AC1 only and aim for zero watts on the grid meter phases. 3.) Whatever you guys suggests so if there are any good ones we are happy to hear them.
I like this idea. Officially it it not supported a so called master slave setup but I am interested in the way to let two different MP’s work together in a “fixed” ratio.
So MP 1 takes 80% care of the load and the second MP takes care of the other 20%
As you maybe already know there is a virtual Multiplus emulator.
Maybe this could act as a master MP and steers the real (slave) MP’s
Well it is no matter of master/slave. Each multi plus should regulate the corresponding grid meter’s phase towards zero watts independently.
I assume there will be a kind of race between the two MP’s.
Or the setup could be like this:
MP1 will take of the task (invert or charge) with a max of its capacity and MP2 will do the rest…
Than I would call MP1 the master and MP2 the slave 
For example:
MP1 has a cap of 5000VA and MP2 has a cap of 3000VA
The load is currently 6000VA. => MP1 will deliver 5000VA and M2 will deliver 1000VA
I would like to see a fixed ration between both MP’s
MP1 takes care of for example 70% of the task (invert or charge) and MP2 takes care of 100-70 = 30% percent of the task.
For example:
MP1 has a cap of 5000VA and MP2 has a cap of 3000VA
The load is currently 6000VA. => MP1 will deliver 4200VA and M2 will deliver 1800VA
The current Victron parallel MP solution is that both MP’s act as one and both take care of 50% of their task. And both MP’s need to be the same type/firmware etc…
Well, the MP2’s are not connected to the same Line, they one share the neutral (N) and are connected to L1 / L2 as i explained. So no shared tasks do to as you misinderstood. But thanks for spending the time trying to help me. I suggest you start your own topic for you own problem if not allready done. Kind Regards, Gerd
You cant run them both on one gx, one grid meter or one battery can bus…
So you would need to double everything, even the battery share is a challenge to get working right
For grid metering you could use 2 single phase meters (et112) instead of one 3 phase meter
Hi Marc, Yes indeed, We are well aware now of that. But we did succeed getting both connected to the GX. One to the built in VE-bus, one to a second VE-bus using a MK3 USB convertor. Both appear in the device list. They are also both available in Node-RED and controllable from Node-Red to some extend. Also all 3 grid meter phases are available in node-red and also the battery data is available there. So in theory we could write both ESS controlling systems manually in Node-RED. I am a experienced programmer. On the other hand adding a second GX will be more practical, especially for my friends ability to fine tune the system to his personal preferences. Upgrading the second one to a 5000 is also still an option my friend considders. That way we could build a split phase ESS parallel tied as the victron documentation claims to support.