Aggregation crashes / exits when one serial battery is temporarily disconnected (non-CAN path)

[JoanMCD]

Version checked: main (VERSION = "4.3.20260611-beta")
File: dbus-aggregate-batteries.py, method that reads V/I/P from each battery service

Summary

For serial / non-CAN batteries the aggregation loop reads /Dc/0/Voltage, /Dc/0/Current,
/Dc/0/Power and adds them directly, with no None check. When one battery in the bank drops
its connection for a moment, its dbus-serialbattery instance publishes None on those paths.
The aggregator then executes int += None → TypeError and enters an error/retry loop. After
READ_TRIALS it calls sys.exit(1), which removes the aggregate battery service from D-Bus.
On a Victron ESS / VE.Bus system a disappearing battery service triggers a "Low Battery" VE.Bus
alarm and can interrupt inverter operation — a momentary BMS comms hiccup becomes a system alarm.

The CAN path (settings.CAN_batteries) got a ValueError guard, but the serial path is unguarded.

Affected code (current main)

Non-CAN read, no None guard:

# ~line 909, the `else:` (non-CAN) branch
Voltage += self._dbusMon.dbusmon.get_value(self._batteries_dict[i], "/Dc/0/Voltage")
Current += self._dbusMon.dbusmon.get_value(self._batteries_dict[i], "/Dc/0/Current")
Power   += self._dbusMon.dbusmon.get_value(self._batteries_dict[i], "/Dc/0/Power")

(Same pattern follows for /InstalledCapacity, /Capacity, /Soc, /Dc/0/Temperature.)

Exit on read failure:

# ~line 1093
logging.error("DBus read failed. Exiting...")
tt.sleep(settings.TIME_BEFORE_RESTART)
sys.exit(1)

Averaging by fixed battery count:

# ~line 1105
Voltage = Voltage / settings.NR_OF_BATTERIES
Temperature = Temperature / settings.NR_OF_BATTERIES
VoltagesSum = sum(VoltagesSum_dict.values()) / settings.NR_OF_BATTERIES

Steps to reproduce

1. NR_OF_BATTERIES >= 2, serial (non-CAN) BMS instances.
2. Briefly disconnect one BMS (pull RS485, or induce a comms error) so its dbus-serialbattery
   publishes None for V/I/P.
3. Aggregator throws TypeError: unsupported operand type(s) for +=: 'int' and 'NoneType',
   loops, then sys.exit(1) → com.victronenergy.battery.aggregate disappears from D-Bus
   → VE.Bus "Low Battery" alarm on ESS systems.

Impact

• A single, recoverable BMS disconnect takes down the whole aggregated battery service.
• On ESS this raises a VE.Bus Low Battery alarm and can disturb the inverter, instead of simply
  riding through with the remaining batteries.
• While one battery is missing, averaging by NR_OF_BATTERIES (not the number actually reporting)
  also publishes a wrong aggregate voltage/temperature.

Proposed fix (behaviour)

Three independent, small changes make the serial path resilient:

1. None-guard + skip. If any mandatory value is None, skip that battery for the cycle
   (don't add it) and remember when it first went missing:

   _voltage = get_value(.../Dc/0/Voltage)
   _current = get_value(.../Dc/0/Current)
   _power   = get_value(.../Dc/0/Power)
   if _voltage is None or _current is None or _power is None:
       # record first-missing timestamp, optionally block charge/discharge after a timeout
       continue
   batteries_online_count += 1
   Voltage += _voltage; Current += _current; Power += _power

2. Don't sys.exit() on read failure. Removing the service from D-Bus is what triggers the
   VE.Bus alarm. Keep the service alive holding the last published values; only block
   charge/discharge after a safety timeout (e.g. 180 s) if data never recovers.

3. Average by online count. Divide by the number of batteries that actually reported this
   cycle, falling back to NR_OF_BATTERIES only when none did:

   divisor = batteries_online_count if batteries_online_count > 0 else settings.NR_OF_BATTERIES
   Voltage = Voltage / divisor

With these changes a transient disconnect of one battery no longer crashes the aggregator or
raises a VE.Bus alarm; the system keeps running on the remaining batteries and recovers
automatically when the battery returns.

[Dr-Gigavolt]

Hello and thanks for reporting. Leaving a program to crash and restart is a bullet-proven technique for Victron programs. If a BMS disconnects you should find and fix the reason instead of trying to mask it. Imagine the case when the BMS disconnects, you ignore it, your batteries are full and charging won't stop. I had disconnections few weeks ago during very hot weather. I had had an signal integrity trouble which during 3 years of operation wasn't revealed. The TX-output impedance of USB-serial adapters was too high do drive the cable capacitance. But it was just OK for the most of time. But not at high ambient temperature. I had repetitive disconnections every afternoon. An investigation with an oscilloscope has shown what was wrong. And the fix was much simpler then the issue itself - a pull-up resistor for each adapter.

[JoanMCD]

Thanks for the answer, and especially for the oscilloscope story — that's exactly the kind of thing that's impossible to guess from the logs.

Could I ask for a few details on that? Which USB-serial adapters were they, where exactly did you put the pull-up (TX line to VCC, at the adapter side or at the BMS end?), and what value did you land on? My setup is different from yours — JK BMS, LiFePO4, and different RS485 adapters — so it may well not apply to me. But it sounds like something worth having written down somewhere, and I couldn't find it in either repo.

One thing I should have mentioned in the report: in my setup the BMS has the final say — whatever the driver or the aggregator asks for, the BMS stops the charge itself when the pack is full. So it acts as the last line of defence for the "batteries full, charging won't stop" case. I realise that isn't a given in every setup — is that what the current design is protecting against?

The part I'm unsure about: While looking into this I ran into what looks like the same pattern in the Victron path, which surprised me because it has nothing to do with BMS cabling. In main @ 4.3.20260611-beta:

1149:  success = True
1151:  Current_VE = 0
1161:  Current_VE = self._dbusMon.dbusmon.get_value(self._multi, "/Dc/0/Current")
1172:  for i in range(settings.NR_OF_MPPTS):
1174:      Current_VE += self._dbusMon.dbusmon.get_value(self._mppts_list[i], "/Dc/0/Current")
1176:  except Exception:
1186:      success = False
...
1241:  Current_VE += Current_SHUNTS      # TypeError: NoneType + int

As far as I can tell dbusmon.get_value() returns None rather than raising when a path isn't populated. During a MultiPlus reconnect there seems to be a window where /Connected is already > 0 but /Dc/0/Current isn't there yet — so 1161 assigns None, nothing raises, success stays True, and 1241 throws.

From my system (line number shifted by local patches):

2026-07-16 06:25:34  INFO:root:MultiPlus/Quattro is connected
2026-07-16 06:25:34  Traceback (most recent call last):
  File "/data/apps/dbus-aggregate-batteries/dbus-aggregate-batteries.py", line 1239, in _update
    Current_VE += Current_SHUNTS
TypeError: unsupported operand type(s) for +=: 'NoneType' and 'int'

What I think explains why this is rarely seen: line 1174 is inside the try. With NR_OF_MPPTS >= 1, None += float raises there first, gets caught, sets success = False, and it degrades into the "Victron current reading error" path you already wrote. I have NR_OF_MPPTS = 0, so that loop never runs and nothing catches it. Does that match your understanding, or am I misreading the flow?

If it's right, this one isn't a wiring problem — it'd be a timing race against your own MultiPlus on reconnect, and I don't see what to fix on the hardware side. Would you accept a small PR that sets success = False when the value is None, so it falls into the existing BMS-current fallback? That would keep the fail-fast philosophy intact and only change what triggers it.

Unrelated, small: Separate from all of the above: the divisor uses NR_OF_BATTERIES rather than the number of batteries currently online. If one drops out, the averages come out low. Independent of the crash question — happy to split it into its own issue if you'd prefer.

[Dr-Gigavolt]

Hello, I use these insulated adapters:
https://www.ebay.de/itm/265430429754
and the fix was 1 kOhm pull-up between 3.3V and TXD to BMS on adapter board
no troubles after fix any more

are you RS485 adapters galvanically insulated? It is necessary, otherwise you sooner or later run into troubles. Check the signals with scope whether you clean rectangles or they are low-pass filtered or there is an EMI.

One thing I should have mentioned in the report: in my setup the BMS has the final say — whatever the driver or the aggregator asks for, the BMS stops the charge itself when the pack is full. So it acts as the last line of defence for the "batteries full, charging won't stop" case. I realise that isn't a given in every setup — is that what the current design is protecting against?

Exactly, the BMS is the last defence - hard disconnection. This shall be avoided by software whenever it is possible.

The rest I will check later, have not enough time now.