search

Dr-Gigavolt / dbus-aggregate-batteries

Virtual service to merge multiple serial batteries
MIT License
66 stars 11 forks source link

System keeps charging/discharging if one BMS disappears #49

Open kakariki1 opened 1 year ago

kakariki1 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 2 weeks ago

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:

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