search

Dr-Gigavolt / dbus-aggregate-batteries

Virtual service to merge multiple serial batteries
MIT License
63 stars 10 forks source link

Multiple Batteries and switching to float #52

Open wetty opened 11 months ago

wetty commented 11 months ago

Hi,

I have to 18S batteries with JKBMS an serialbattery.

If the cells of one of the batteries differs only 0.003V for a defined period serialbattery switches to float voltage.

The problem is now that the cells of the second battery differs much more than the 0.003V from the settings and that this battery needs more time to balance.

In a discussion with mr-manuel yesterday he thinks that this is a problem of aggregate-batteries to switch only to float, when all batteries are well balanced.

Dr-Gigavolt commented 11 months ago

Hi, if you use my charge/discharge control, OWN_CHARGE_PARAMETERS = True, the cell voltage difference is calculated from all cells of all batteries and compared with CELL_DIFF_MAX. The balancing is active until all batteries are balanced.

Otherwise (OWN_CHARGE_PARAMETERS = False) my code cannot know why one of your Serial Battery instances reduces the CVL. I must assume the worst case (danger of over-charging of some cell(s)) and therefore the minimum of all CVLs is passed to the ESS.

mr-manuel commented 11 months ago

This means that, if one of three battery packs switches to float because it's fully charged and balanced there is no way to keep the voltage high until all batteries are fully charged and balanced? Or can you achieve this by setting OWN_CHARGE_PARAMETERS = True?

Otherwise (OWN_CHARGE_PARAMETERS = False) my code cannot know why one of your Serial Battery instances reduces the CVL. I must assume the worst case (danger of over-charging of some cell(s)) and therefore the minimum of all CVLs is passed to the ESS.

I have a few ideas that maybe resolve this issue:

  1. You could check, if an alarm is triggered by the BMS

    Alarms/BmsCable
Alarms/CellImbalance
Alarms/HighChargeCurrent
Alarms/HighChargeTemperature
Alarms/HighDischargeCurrent
Alarms/HighInternalTemperature
Alarms/HighTemperature
Alarms/HighVoltage
Alarms/InternalFailure
Alarms/LowCellVoltage
Alarms/LowChargeTemperature
Alarms/LowSoc
Alarms/LowTemperature
Alarms/LowVoltage

  2. Check if Info/ChargeMode contains Bulk, Absorption or Float (only in case of the dbus-serialbattery driver)

Solution 2 would catch the case, if the dbus-serialbattery is lowering the CVL because of max cell voltage is reached.

Maybe it would possible for you to check if Info/ChargeMode is available and if yes act in another way.

Dr-Gigavolt commented 11 months ago

Hi Manuel,

OWN_CHARGE_PARAMETERS = True means the CVL, CCL, DCL are calculated by my code (in different way, explained in the Readme, than in Serial Battery) and those from Serial Battery instances are ignored.

In case of OWN_CHARGE_PARAMETERS = False .... there is couple of problems:

Best regards, Anton

Dr-Gigavolt commented 11 months ago

I think the easiest solution would be to set OWN_CHARGE_PARAMETERS = True until everything is well balanced and than to False if wished. Once well balanced, the issue should not come again.

mr-manuel commented 11 months ago

Thanks for clearing things up for me.

In case of OWN_CHARGE_PARAMETERS = False .... there is couple of problems:

  • I still use a very old Serial Battery which was not released, but it was the last commit working stable with my system, you already know about it. To test the last version again requires a lot of time which I don't have at the moment.

  • Even if it would work, the compatibility with the versions with utils.py will be lost.

The backward compatibility is given, if you add a check like does Info/ChargeMode exist and contain Bulk, Absorption or Float? If yes then use this information, if not then use the old mechanism as it is now.

  • I don't understand the reason of it. Your approach is to keep the battery at full voltage as short as possible. This is in contradiction with the new requirement. The bad balanced battery could enforce full voltage for others in parallel in worst case for weeks.

That's true, but the same is also for the cells. If one cell has lower voltage as the others, then all others have to stay at a higher voltage until the lowest one is balanced. In any case the user is responsible for his batteries and you are describing a perfect and ideal system, which I think may work only if all material is brand new.

If the SOC Reset every x days from dbus-serialbattery is used to reset the SOC of the battery, since there is no other way to do it, then this needed. It would also be needed, if not all the battery packs have the same performance.

There are many cases where full voltage could be applied for weeks. Like shading, winter, defective cell and many more. You could trigger Alarms/CellImbalance, if that is the case for x days.

I think the easiest solution would be to set OWN_CHARGE_PARAMETERS = True until everything is well balanced and than to False if wished. Once well balanced, the issue should not come again.

That would be an option or also to turn off the well balanced batteries until all are balanced well.

Anyway, this is only my opinion and the need that I understood from users that where using dbus-serialbattery with your aggregator. If you want to keep it as it is, they always have the option to use dbus-mqtt-battery and aggregate the data how the like to as long as they have the skills to do so.

Dr-Gigavolt commented 11 months ago

Hi Manuel, could you make the reinstall script with a switch, old (with utils.py) or new Serial Battery? Formerly I used to have 2 versions and switched between them by renaming the directories, now they are no more compatible and once tried I spent whole evening to make it working again. If this will work and I can easily go back to my old stable version, I can try what you propose.

mr-manuel commented 11 months ago

Unfortunately I cannot change the reinstall script, but I can make you a new one to easily switch between the versions, so it should be the same for you :-) You can also write me on Discord so we figure out what the problem with the new version is and fix it.

Dr-Gigavolt commented 11 months ago

Now I installed the newest version (hopefully it remains stable), after I wanted to try the commit 393 by changing files manually and it didn't start any more. Error message:

INFO:SerialBattery:Testing Jkbms ERROR:SerialBattery:[Errno 21] could not open port /dev/: [Errno 21] Is a directory: '/dev/'

The same after restoring old files. Could you explained me what has happened?

mr-manuel commented 11 months ago

What are you changing? How are you starting the driver? It seems that you are starting the driver manually and not specifying the port.

Dr-Gigavolt commented 11 months ago

Hi Manuel,

some good news - the last release of Serial Battery is running without crash, so it seems I don't need to keep the old staff any more. This makes the maintenance of my program easier.

But I would still like to understand the trouble with opening port:

Dr-Gigavolt commented 11 months ago

What are you changing? How are you starting the driver? It seems that you are starting the driver manually and not specifying the port.

In the trial I replaced the files in /data/etc/dbus-serialbattery and executed reinstalllocal.sh. The copying of files run without error. But the service did not start, either immediately nor after reboot.

than I tried to execute the content of the run file:

exec 2>&1 exec /opt/victronenergy/dbus-serialbattery/start-serialbattery.sh TTY

and got the error message written above (for all BMS types tried)

Dr-Gigavolt commented 11 months ago

The backward compatibility is given, if you add a check like does Info/ChargeMode exist and contain Bulk, Absorption or Float? If yes then use this information, if not then use the old mechanism as it is now.

I will look on it at the next opportunity, but it will take a while. Now I'm in lack of time and power :-(

mr-manuel commented 11 months ago

What did the logs say? If you want we can do a TeamViewer session

Dr-Gigavolt commented 11 months ago

Thanks for offer of the session, but now I have, as written, the latest version running and all old stuff is away. Or do you mean the logs of Linux?

mr-manuel commented 11 months ago

than I tried to execute the content of the run file:

exec 2>&1 exec /opt/victronenergy/dbus-serialbattery/start-serialbattery.sh TTY

exec /opt/victronenergy/dbus-serialbattery/start-serialbattery.sh ttyUSB0 should be the correct one to start manually.

The logfiles are here https://louisvdw.github.io/dbus-serialbattery/troubleshoot/#driver-log-files

But now all works with the latest version?

Dr-Gigavolt commented 11 months ago

But now all works with the latest version?

Yes.

The text from log files I pasted before was from wrong time, I have to look again.

Dr-Gigavolt commented 11 months ago

Now I've found the right part of the log:

2023-09-29 21:44:18.497459500 ./run: line 3: exec: /opt/victronenergy/dbus-serialbattery/start-serialbattery.sh: cannot execute: Permission denied

Than tried exec /opt/victronenergy/dbus-serialbattery/start-serialbattery.sh TTY (forgotten to add the port number), no log entry.

2x reboot: 2023-09-29 21:51:56.874624500 CCGX booted (0) 2023-09-29 22:22:17.981119500 CCGX booted (0) no log entry.

Reboot with new tar.gz on USB stick. The old version started, than it was overwritten with the new one. 2023-09-29 22:53:58.238258500 CCGX booted (0) 2023-09-29 22:54:28.105913500 INFO:SerialBattery:Starting dbus-serialbattery 2023-09-29 22:54:28.113689500 INFO:SerialBattery:dbus-serialbattery v0.14.3 2023-09-29 22:54:29.327434500 INFO:SerialBattery:Testing Jkbms 2023-09-29 22:54:29.458612500 INFO:SerialBattery:Connection established to Jkbms 2023-09-29 22:54:29.458619500 INFO:SerialBattery:Battery Jkbms connected to dbus from /dev/ttyUSB2 2023-09-29 22:55:30.727485500 INFO:SerialBattery:Starting dbus-serialbattery 2023-09-29 22:55:30.728638500 INFO:SerialBattery:dbus-serialbattery v1.0.20230531 * 2023-09-29 22:55:50.999202500 INFO:SerialBattery:Testing Jkbms 2023-09-29 22:55:51.119507500 INFO:SerialBattery:Connection established to Jkbms 2023-09-29 22:55:51.119936500 INFO:SerialBattery:Battery Jkbms connected to dbus from /dev/ttyUSB2

Dr-Gigavolt commented 11 months ago

But still surprising (with the last release):

USB2: 2023-09-29 23:28:15.690548500 INFO:SerialBattery:Serial Number/Unique Identifier: JK-BMS-2 2023-09-29 23:28:15.727050500 INFO:SerialBattery:DeviceInstance = 2 2023-09-29 23:28:15.727594500 INFO:SerialBattery:com.victronenergy.battery.ttyUSB2 2023-09-29 23:28:15.754307500 INFO:SerialBattery:publish config values = 1

USB3: - with error messages at the end, but it works. 2023-09-29 23:28:16.074409500 INFO:SerialBattery:Serial Number/Unique Identifier: JK-BMS-1 2023-09-29 23:28:16.125966500 INFO:SerialBattery:DeviceInstance = 1 2023-09-29 23:28:16.126561500 INFO:SerialBattery:com.victronenergy.battery.ttyUSB3 2023-09-29 23:28:16.171961500 INFO:SerialBattery:publish config values = 1 2023-09-29 23:29:15.557487500 ERROR:SerialBattery:>>> ERROR: No reply - returning 2023-09-29 23:29:16.561553500 ERROR:SerialBattery:>>> ERROR: No reply - returning 2023-09-29 23:29:17.559357500 ERROR:SerialBattery:>>> ERROR: No reply - returning 2023-09-29 23:29:18.562576500 ERROR:SerialBattery:>>> ERROR: No reply - returning 2023-09-29 23:29:19.561336500 ERROR:SerialBattery:>>> ERROR: No reply - returning

mr-manuel commented 11 months ago

Yes release v1.0.20230531 was not perfect, but now it looks good. If you still have problems write me on Discord and we fix them :-)

Dr-Gigavolt commented 10 months ago

Hello @wetty, @mr-manuel, the new feature can be activated by settin KEEP_MAX_CVL = True. Please review (search this parameter in aggregatebatteries.py) and test.

Manuel: in which part of code of Serial Battery the alarms are processed? My code up no now only combines the alarms received from Dbus, my own caclulation does not generate any, this can be improved.

wetty commented 10 months ago

the new feature can be activated by settin KEEP_MAX_CVL = True. Please review (search this parameter in aggregatebatteries.py) and test.

I will test it but might take several weeks until the sun is shining again to fill my 32kWh :-)

mr-manuel commented 8 months ago

Hi @Dr-Gigavolt,

sorry only now I saw that I never answered your question. The alarms are generated from each battery class and then written to the dbus by dbushelper.py.

It should be ok, if you only combine the alarms. I‘m not sure, if it makes sense that you trigger for example a cell imbalance alarm, when the current from the batteries is too different for a specified amount of time or something like that.