Communications between ecoworthy 48v cubix and victron multi plus ii

I've been poking around this exact issue recently with a similar setup, so thought I'd chip in.

The short answer is that the EcoWorthy Cubix uses its own proprietary BMS communication protocol, and the Victron MultiPlus II speaks DVCC via VE.Can or VE.Direct — these two don't natively talk to each other out of the box. No surprise there with budget Chinese packs, frankly.

A few options worth exploring:

• DVCC via a Cerbo GX — if you have a Cerbo in the loop, you might be able to get basic SOC data through using a RS485-to-USB adaptor, but you'd need to confirm whether EcoWorthy publish their BMS register map (they often don't)
• Victron's "external BMS" mode — you can configure the MultiPlus II to defer to an external BMS for charge control, but this requires proper comms signals (charge enable/discharge enable), which means wiring in the BMS relay outputs manually to the MultiPlus II's AUX inputs
• Just run it dumb — set conservative charge/discharge parameters directly in VEConfigure and let the internal BMS handle protection itself. Not ideal but functional.

I went down the RS485 rabbit hole with a non-communicating pack last year and eventually gave up and ran it in standalone mode with carefully tuned voltage thresholds. Worked fine for my cabin backup setup.

Has anyone actually got a Cubix specifically to handshake properly with a Cerbo? I'd be genuinely interested to know if EcoWorthy have updated their firmware recently to support any standard protocol like PACE or JK-compatible comms.

Hey @Paddy, cheers for starting this thread - really useful topic!

One thing worth adding: even without proper BMS comms, you can still get a reasonably safe setup by configuring the Victron's charge parameters manually to match the Cubix's cell specs. Not ideal, but it works as a stopgap.

The real gotcha is the lack of DVCC support - without that handshake, your Multiplus won't respond dynamically to the battery's state. I'd strongly recommend setting conservative charge and discharge cutoffs in VE.Configure to compensate.

Some folks on here have had luck using a Raspberry Pi running Venus OS as a middleman, with a custom driver to translate the Cubix BMS data. Worth a search on the Victron Community forums too - there's a bloke there who wrote a Python script specifically for this kind of bridging scenario.

Really useful thread this — been wrestling with something similar on my boat setup.

Has anyone actually tried the Pylontech emulation mode that some third-party BMS units offer? I'm wondering whether a intermediate device like a Victron Cerbo GX could bridge the gap here — it speaks Victron's language natively and might smooth over the protocol mismatch with the EcoWorthy.

Also worth asking: what does the Cubix actually expose over its comms port? RS485 or CAN? Because if it's RS485, there might be more options for custom integration than if it's locked down completely.

@Paddy — did you manage to get any state-of-charge data visible in VRM at least, even if full BMS comms aren't working? That would at least give you something to work with as a fallback whilst you dig into this further.

@CamperClive the Pylontech route is basically cheat codes for Victron comms — my garden office runs exactly that combo and the Cerbo just talks to it like they went to school together.

@VoltBarry jealous of that setup honestly 😅

Worth flagging though — if you're on a narrowboat like me, space is tight and Pylontech batteries are chunky. I ended up going down the Fogstar Drift 48v route on my build, which has a similar comms headache with Victron but at least the form factor works.

What I did in the end was just run the Multiplus II in standalone mode with a Victron BMV-712 doing the monitoring separately. Not elegant but it works and the Cerbo GX ties it all together visually at least.

Not ideal if you want proper DVCC stuff happening automatically but for my use case it's fine. Might be worth considering if the EcoWorthy comms thing turns out to be a dead end 🤷

@Paddy good shout on the proprietary protocol issue — this catches a lot of people out.

Worth adding: even if you bodge a CAN or RS485 connection across, the Victron expects specific BMS data fields (SOC, cell voltages, charge/discharge limits) in a defined format. If the Cubix isn't sending those correctly, the Multi Plus II will just ignore DVCC entirely and fall back to dumb voltage-based charging — which defeats the purpose.

Your realistic options without swapping hardware:

• Victron-compatible BMS (Fogstar Drift cells with a compatible BMS is a popular UK route)
• Venus OS Large running a custom driver — some GitHub projects exist but it's not plug-and-play
• Manual charge profile via VEConfigure and accept no closed-loop comms

I've gone the Venus OS route on my van build and it took a solid weekend of head-scratching. Not for the faint-hearted.