System keeps charging/discharging if one BMS disappears

[kakariki1]

Hello Anton (or anybody else willing to help),

I have a problem, probably not direct related to dbus-aggregate-batteries, but I hope to get some help.
I have a similar hardware setup as you: 3x MultiPlus-II 48/5000/70-50, 1x Fronius Symo 20.0-3-M, 3x LiFePO4 batteries with JK BMS 2A24S20P
Everything runs smooth for a few months now, but recently one of the BMS failed in such a way that the USB-to-serial-adapter /dev/ttyUSB0 disappeared.
dbus-aggregate-batteries behaves as expected and keeps exiting and restarting itself forever.
I also checked the dbus values by using dbus-spy, everything as expected.
The problem is, the system now does not stop charging or discharging the 2 remaining battery-packs !

This is easily reproduced by disconnecting the USB-to-serial-adapter.

So I have 2 questions:

1. Can you please try to reproduce this behaviour ?
2. Do you have a solution ?

Thanks in advance and best regards,
lakeroe

[Dr-Gigavolt]

Hi Berni,

I cannot look on it immedoatelly, but i think there is an option in Serial Battery setup whether it has to stop or continue to run if the BMS dissapears.

About BMS itself - can you check the serial hatdware wirh an oscilloscope? The first I can imagine (after months of operation and no change in the softwate) is a hardware damage.

[kakariki1]

Hello Anton,

the BMS is already running again, it only needed a poweroff/poweron cycle. My best guess is an indirect lightning strike, as we had some strong thunderstorms the last weeks.

And you are right:
Newer versions of dbus-serialbattery do have a BLOCK_ON_DISCONNECT setting.
I'm running an older version missing this feature.
Maybe I have to update ...

Best regards,
Berni

[kakariki1]

Hello Anton,

I thought a bit more about this topic and came to the conclusion, you have to distinguish between two different cases:

1. Connection to BMS gets lost, but /dev/ttyUSBxx still exists (easy reproducible by simply unplugging the USB-to-serial-adapter at the BMS side).
   Handling can be done in dbus-serialbattery itself, which is already included in recent versions.

2. Connection to BMS gets lost, and /dev/ttyUSBxx doesn't exist anymore (easy reproducible by simply unplugging the USB-to-serial-adapter at the Rasperry Pi or Cerbo GX).
   Handling can't be done in dbus-serialbattery, because the driver is simply not running.
   So in this case the handling has to be done somewhere else (dbus-aggregate-batteries, Venus OS, ...).

What do you think ?

Best regards,
Berni

[Dr-Gigavolt]

Hi Berni, sorry, it took some time, but now I tested it. I had no difference if disconnected serial or USB. The new serial battery driver raises /Alarms/BMScable, this I will use to put Aggregate Batteries into safe state. You right, it continues running because the last values before disconnecting remain on DBus.

[Dr-Gigavolt]

I was playing further: It does not matter whether I disconnect the serial or USB side, or BLOCK_ON_DISCONNECT in Serial Battery is set true or false: The USB instance dissapears and AggregateBatteries dies as expected. Therefore keeping the Aggregate Batteries living and controlling by /Alarms/BMScable does not work.

FYI: @mr-manuel

[Dr-Gigavolt]

I made one more trial today. Since the last time I improved exception handling, now should the AggregateBatteries disconnect clearly if data from a battery instance are no more valid. When I disconnect the serial cable of one of batteries:

• the battery instance disappears
• the aggregatebatteries tries READ_TRIALS times to get data, if not succeed, it shuts down by sys.exit() in line 832
• EES has no sensor any more
• the following alarms are raised: SerialBattery: BMS cable fault; SmartSolar MPPT: BMS connection loss; MultiPlus-II: Low battery voltage
• the MultiPlus goes to pass-through (safe)
• the MPPT continues charging

About the last point: Does the MPPT in this case follow its own charge parameters? If the voltage limit is set low enough - safe???