3 Days on an RS485 Bus: What We Learned Daisy-Chaining Four Daly BMS Units to a Victron Cerbo GX

We build battery packs in-house at our Houston facility. That means we don't just sell batteries; we assemble cells, configure BMS units, test packs under load, and integrate them into Victron systems before they ship. Most of the time, that process goes smoothly. This is a story about one of the times it didn't.

We were building a large 48V battery bank using four of our 16S LiFePO4 packs, each with a Daly Smart BMS rated at 100A. The packs would sit on a common DC busbar in parallel, and the four BMS units needed to communicate over RS485 as a single aggregated bank to the Victron Cerbo GX. On paper, this is a well-documented configuration. In practice, it took us three days to get it working. Here's what went wrong, what we learned, and what we'd do differently.

The Goal

Four 48V LiFePO4 packs. All positive leads to one busbar, all negative leads to another. Each pack managed by its own Daly Smart BMS (16S, 100A, with active balancing). The four BMS units needed to be daisy-chained over RS485 and present to the Cerbo GX as a single, aggregated battery bank. The Cerbo would then pass voltage, current, SOC, cell data, and temperature readings to the Victron system via DVCC (Distributed Voltage and Current Control), which governs how the MultiPlus or Quattro inverter charges and discharges the battery.

Simple enough. Four BMS units, one RS485 bus, one USB-to-RS485 adapter into the Cerbo, and the open-source dbus-serialbattery driver to bridge the gap between Daly's protocol and Victron's Venus OS. We estimated half a day for the communication setup. It took six times that.

Problem 1: Setting BMS Addresses

For multiple Daly BMS units to coexist on a single RS485 bus, each one needs a unique board address. This is how the Modbus protocol works: every device on the bus has an address, and the master (in this case, the Cerbo GX via dbus-serialbattery) polls each address individually.

The Daly Smart BMS supports address configuration through their PC software, BmsMonitor (sometimes called BMSTool). Here's the first thing that cost us time: you cannot reliably set the board address using the Daly mobile app. The Bluetooth app will appear to accept the change, but the BMS either won't retain it or will set it incorrectly. You have to use the Windows desktop software over a direct RS485 or UART connection to the BMS. We learned this the hard way after spending hours troubleshooting what turned out to be addresses that never actually changed.

The process itself is straightforward once you know the right tool. Connect each BMS individually to a PC via the RS485 cable that ships with the Daly. Open BmsMonitor, navigate to the Engineering tab, find the Board Address field, set a unique address, and confirm. For dbus-serialbattery, the Daly addresses map to Modbus addresses starting at 0x40. So our four packs were configured as 0x40, 0x41, 0x42, and 0x43, which then get specified in the driver's config.ini as BATTERY_ADDRESSES = 0x40, 0x41, 0x42, 0x43.

The critical detail: you must connect each BMS one at a time to set its address. If two BMS units with the same default address are on the bus simultaneously, you can't reliably communicate with either one. Disconnect all but one, set its address, disconnect it, connect the next. It sounds obvious in hindsight, but when you're troubleshooting a bus that returns garbage data, the root cause isn't always apparent.

Problem 2: RS485 Wiring

RS485 is a differential signaling standard. It uses two wires (commonly labeled A and B, or TX+ and TX-) plus a ground reference. The physical layer is simple, but there are rules that matter when you're chaining multiple devices.

Our first wiring attempt was a star topology: each BMS had its own cable run back to a central point where they all joined into one RS485-to-USB adapter. This is wrong for RS485. The protocol is designed for a daisy chain (bus topology), not a star. Star wiring creates signal reflections and impedance mismatches that corrupt data on the bus. With two devices, you might get away with it. With four, you won't.

The correct topology is a daisy chain: the RS485-to-USB adapter connects to BMS #1, which connects to BMS #2, which connects to BMS #3, which connects to BMS #4. Each Daly Smart BMS has RS485 connections that can be wired in series this way. The last device on the chain needs a 120-ohm termination resistor between the A and B lines. Some RS485-to-USB adapters also have a termination resistor (or a jumper to enable one) on the master end. Both ends of the bus should be terminated.

What tripped us up specifically:

• A/B line labeling isn't universal. Different manufacturers swap the A and B designations. On the Daly BMS, what's labeled "A" may correspond to "B" (or TX-) on your RS485-to-USB adapter. If you wire A-to-A and B-to-B and get no communication, try swapping them. RS485 is differential, so reversing polarity doesn't damage anything; it just inverts the signal.
• Ground reference matters. Even though RS485 is differential, a shared ground between all devices on the bus significantly improves signal integrity, especially on longer cable runs. We initially omitted the GND wire and saw intermittent communication drops that were difficult to diagnose.
• Cable quality. RS485 performs best with twisted pair cabling. We initially used loose hookup wire. Switching to CAT5 cable (using one twisted pair for A/B and another conductor for GND) cleaned up our signal immediately.

Problem 3: Getting the Daisy Chain to Aggregate

With addresses set and wiring corrected, each individual BMS was now responding to Modbus polls. We could see all four in the BmsMonitor software on the PC. The next step was making them appear as a single, aggregated battery bank on the Cerbo GX.

This is where the dbus-serialbattery driver comes in. It's a community-developed Venus OS driver that bridges serial-connected BMS units (Daly, JK, Renogy, and others) to Victron's dbus system. Without it, the Cerbo GX has no native way to talk to a Daly BMS over RS485. Victron's built-in BMS support is limited to their own batteries and a handful of CAN-bus compatible third-party units.

Installing dbus-serialbattery on the Cerbo requires SSH access. The "easy" USB flash drive auto-installer method did not work reliably for us. The SSH install did. Once installed, you edit the config.ini to specify BMS_TYPE = Daly, set the BATTERY_ADDRESSES, and reboot.

When it works, each BMS appears as a separate battery in the Venus OS device list. But we needed them aggregated into one virtual battery so that DVCC sees a single bank with combined capacity, averaged SOC, and consolidated cell data. This requires a second driver: a battery aggregator. The dbus-serialbattery documentation points to a few options. The aggregator collects data from all connected batteries and presents a unified set of values (total voltage, summed current, averaged SOC, worst-case cell voltages) to the Cerbo's DVCC system.

The aggregation step is where most people give up. It's an additional layer of software configuration on top of an already non-trivial setup. Getting the aggregator to correctly calculate combined charge/discharge current limits, to use the lowest cell voltage from any pack as the system minimum, and to properly trigger DVCC protections when any single BMS raises an alarm took careful tuning of the config parameters and several rounds of testing.

Problem 4: Cerbo GX Communication and DVCC

Even after the aggregator was working and showing correct values in the Venus OS GUI, we had one more hurdle: making sure the Victron inverter actually listened to the BMS data.

DVCC (Distributed Voltage and Current Control) is Victron's system for letting a BMS control charge and discharge behavior across the entire system. When DVCC is enabled and a battery/BMS is selected as the controlling source, the BMS dictates the Charge Voltage Limit (CVL), Charge Current Limit (CCL), and Discharge Current Limit (DCL). The inverter and charge controllers obey these limits.

The issue we hit: DVCC was enabled, but the aggregated battery wasn't selected as the controlling BMS in the Cerbo's settings. Venus OS lets you choose which battery controls DVCC under Settings > System Setup > Battery Monitor. If you have multiple battery devices visible (which we did, because both the individual BMS units and the aggregated virtual battery were showing up), you need to explicitly select the aggregated battery as the system's battery monitor. Without this, the inverter was charging based on its own internal voltage limits rather than the BMS-reported limits, which is unsafe with LiFePO4 cells.

We also had to verify that DVCC > Limit charge current and DVCC > Limit managed battery charge voltage were both enabled. And we had to make sure the charge voltage limit being reported by the aggregator matched our cell chemistry. The Daly BMS was configured for a 3.65V per cell charge cutoff (58.4V for 16S), but the dbus-serialbattery driver has its own configurable voltage limits that can override or interact with the BMS values. Getting all three layers (BMS hardware settings, driver config, and DVCC settings) to agree took careful cross-referencing.

What We'd Do Differently

Looking back, here's the streamlined process we now follow for multi-pack Daly RS485 setups:

1. Set addresses first, one BMS at a time, using the Windows BmsMonitor software only. Never trust the mobile app for address configuration. Label each pack with its Modbus address physically on the enclosure.
2. Wire the RS485 bus as a true daisy chain using twisted pair cable (CAT5 works perfectly). Terminate both ends with 120-ohm resistors. Always include the GND wire.
3. Test the bus with BmsMonitor on a PC before touching the Cerbo. If all four BMS units don't respond reliably from the PC, they won't respond reliably from the Cerbo. Fix the physical layer first.
4. Install dbus-serialbattery via SSH, not the USB auto-installer. Configure BMS_TYPE, BATTERY_ADDRESSES, and verify each battery appears individually in Venus OS.
5. Install and configure the battery aggregator. Verify the aggregated values (especially CCL, DCL, and cell min/max) make sense before enabling DVCC.
6. Set DVCC to use the aggregated battery as the system battery monitor. Verify CVL, CCL, and DCL in the Cerbo's device list match your expectations. Load test the system and confirm the inverter respects BMS-reported limits.

Why This Matters

We share this because it's the kind of real-world integration work that separates a box of components from a functioning power system. Anyone can list Victron parts on a website. Making a multi-pack third-party battery bank talk to a Cerbo GX over RS485 with proper DVCC control is engineering work, and the documentation for doing it is scattered across forum threads, GitHub issues, and BMS vendor PDFs that may or may not match your hardware revision.

This is exactly why our pre-configured power systems ship with the BMS communication already tested and the inverter pre-programmed. And it's why every kit order includes a 45-minute Zoom onboarding call with our technical team, because even a well-documented system has edge cases that are easier to solve with someone who's already been through them.

If you're building your own multi-battery Victron system and hitting communication issues, reach out. We've been through it, and we're happy to help. As a Victron Recommended Software Integrator, this is the work we do every day.