Handle multiple battery modules

[Louisvdw]

Handle multiple battery modules

[rocky00717]

Any updates on this?

[Louisvdw]

I'm waiting for my second BMS to arrive. Seem that the factory has run out of RS485 chips.

[xerootg]

Do you have ideas about what it would take to make this happen? I have two batteries, both ble (nordic) central mode uart, that I'd like to use with your library, but seems like even before jumping into ble code, multiple battery support should happen.

[Louisvdw]

@xerootg you will first need to get the driver to talk to your one battery, so I would suggest starting with that. There is a battery_template.py file that you can copy as a base for your BMS. Be sure to submit a pull request when you are done. If you need help just should out in the forum.
Once you have your BMS talking to the driver all features will be availble, including this one for multiple battery modules.

[liufuyang]

Interesting. I am also waiting for my BMS to arrive and I have 2 battery packs. Perhaps I can help testing as well. But these "driver" thing is definitely new to me. Maybe some of you have some good source I can take a quick look somewhere? I also purchased a QUCC BMS I think this will support that well. Looks like the US sanction on China really taking some effects as the chips are now feels really in low supply... The QUCC BMS is not shipped yet as the seller says the RS485 will arrive for them in a few days then he can ship everything to me together.

[sideburnie]

following

[dakoal]

Hi. What if 2 TTL-USB Adapters are connected? Not RS485 and two dalys at one Adapter but 2 dalys on two adapters?

ttyUSB0 and ttyUSB1

I can try to build this today.
you can still ssh to my cerbo.

[Louisvdw]

What if 2 TTL-USB Adapters are connected? Not RS485 and two dalys at one Adapter but 2 dalys on two adapters?

You have the same issue with 2x TTL links or 1x RS485 linked to2 BMS. The one battery will override the data from the next. I already have 2 TTL linked BMS connected on my setup so that should work. You can see the data in Remote Console and the alarms from any one will show in VRM, but only the first BMS data is used and display.

[Hhalewijn]

I have 2 BMS connected. A third one will be connected next week. The two show up in remote console but as stated before, only one can be selected for advanced reporting. I hope this will be added. Please keep me updated on this.

[coca7]

I have three JBD BMS's in my system. I have the first one connected using the driver to see how it works with my system.

[coca7]

Reading through the comments I noticed that of the people who have tried connecting multiple batteries, I don't think anyone has connected more than two. I connected my three today and two of the three are visible along with my smartShunt.

[Hhalewijn]

Hi Coca7,
I've three up and running. It is as Louis says, the number does not matter, it is the behaviour of Victron that does not allow to have more than one BMS that can be selected. I think we would like to have some kind of virtual device that can be selected for Battery Monitoring and that aggregates the information from the individual devices.

[coca7]

Thanks @Hhalewijn I knew what Louis said. I just wanted to log the behavior if no one had observed it yet.

[damonblumenstein]

@Louisvdw do you have an ETA on this and can it be done over BT with the CerboGX so you don't need to run USB-UART adapters eliminating the ability to use the XiaXang app?

[Louisvdw]

Bluetooth is not is the near term plan, but there is an ticket for it #13
The multi bank should be the next feature completed as I am currently working on it and the V2.80 firmware issue.

[centro-max]

@Louisvdw can you foresee when you will get the update for the multi-bms problem with the victron version 2.8X?

your work is fantastic, compliments!

If you need a tester, i connected 2 daly-bms to my raspberrypi

[herrep]

@Louisvdw Great work!

At present, I have not set up my Victron inverter/charger + BMS so far, I am gathering information for the correct setup where I will have at least two battery banks in parallel.

What I understand from the screenshots posted above is that only very basic monitoring is possible when connecting more than one BMS via RS485 to the Venus OS based hardware. In this case, all connected BMS are shown and its associated SOC, present voltage and present current. But the detailed analysis will show only one BMS.

Is my understanding correct or did I miss something?

[Louisvdw]

Hi @herrep
All the same details are available for each connected BMS when you look at it inside the Remote Console. (and venusOS not V2.80 or higher).
But as a Battery Monitor only the values from one BMS is used in the GX and published to VRM. That is what this ticket is looking to solve.

[pedrorampolla]

Any updates on this? I have 3 JBD BMS and even renaming them as separate instances would be awesome. Willing to test. Using Firmware 2.73 and v0.10 so I can see them all in the device list.

[Louisvdw]

There is a new 0.11beta4 release that should solve many of the issues the driver had on the newer v2.80 and higher firmware. You should be able to see all the BMS in the device details list like on the V2.73 firmware. If I can get a bit more feedback from more people if this solves the issues in 2.80 I can release it as the next version.

Those issues have been holding back this feature as you can't have multiple banks if you cannot see them.

[centro-max]

OS 2.87 now shows 2 Daly-BMS with 011beta4 - that is fine!

BUT

the fill level, the total voltage and the current [A] are read out correctly, only the minimum and maximum cell voltage in the detail page is incorrect. Each cell has 3,4V in this moment.

[pedrorampolla]

Updated to 2.87 and installed beta .11b4. Now only one JBD BMS shows up at a time.

[Louisvdw]

Now only one JBD BMS shows up at a time.

What install method did you use to upgrade the driver?
And did you reboot afterwards?

[pedrorampolla]

Blind install with a USB drive. and then a reboot.

[Louisvdw]

Blind install with a USB drive. and then a reboot.

I did a change in how the auto install calls the installer in the new v0.12 release. Try and see if that solves your auto install only showing 1 BMS. It might also help to install a new venus firmware - this resets and force the driver to reinstall.

[coca7]

After installing v.12 on my Cerbo GX (v2.87) I can see all three BMS's and the smart shunt.

[arnoc-intuvision]

Hi @coca7,
I would like to know if all 3 your LLT/JBD BMS's are connected to one /dev/ttyUSBx port ? Or is each BMS connected to its own serial port ?

I've added a driver to integrate with Polarium Gen5 batteries, and I can see the first BMS in the Cerbo GX Web UI, but I would like to have multiple Polarium BMS's connected in cascade (RS485), Modbus ID 1, 2, 3, x etc, and have them all show up on the Cerbo GX Web UI as well as in the VRM Portal.

[Louisvdw]

This is still relevant as we need it for other items. But we could relook at how we do the implementation.

[mr-manuel]

@Louisvdw @istein @transistorgit how would you achieve this to create multiple batteries with one driver instance? For multiple batteries on one RS485 adapter we need one instance to create multiple batteries.

Do you think the speed will be fast enough? For example the Daly BMS is very slow and it would take very long for getting the data of multiple batteries. In this case the fetched data will be very delayed.

[transistorgit]

I had a look into it and I would say a pythonic and minimal way to achieve this would be to change battery.test_connection() to a generator object and implement an address scanner there. So the changes to the code would be:

• in battery.test_connection() scan for batteries not only once but for a fixed range of addresses or on addresses that the user defined in config.ini
• yield a battery object for each found bms
• in dbus_serialbattery the battery variable will be a list then
• so you can add a small handler function in the line gobject.timeout_add(poll_batteries, lambda: poll_batteries) that calls poll_battery(mainloop) for each entry in the loop. In the classic case of only one battery per port this would change virtually nothing. As the battery objects are called sequentially, there is no problem with simultaneous bus access. The refresh rate is divided by the number of instances, though.

I added a minimal demo code below.
Concerning the speed, I would suggest to add a throttle mechanism again. I would think that the largest requests like get_cells_volts() can be called much less often, like once a second.

First I will check with my dalys if it's possible to change the bms address at all. There is a suspicious option in the daly PC software, but I don't know if it really works.

class battery:
    address = 0

    def test_connection(self):
        for i in range(5):
            newbat = battery()
            newbat.address = i

            # do battery connection test stuff here
            # yield newbat or None

            yield newbat


# battery = get_battery(utils.BMS_PORT) stuff goes here
b = battery()
batlist = []
[batlist.append(obj) for obj in b.test_connection()]

# list all found batteries
[print(obj.address) for obj in batlist]

[gnissahr]

I am unsure if this is the correct location to share my findings regarding battery aggregation. If not, please let me know, so I can put the info in another location.

First I tried the BatteryAggregator by Pulquero. It is very easy to install, but does require the additional installation of the SetupHelper. Some configuration was required. I have a Lynx Shunt and this was seen as a battery, so my Amps were more or less double.
Not a lot of configuration possible, so I decided it's not for me.

Next I installed dbus-aggregate-batteries by Dr. Gigavolt. The installation is a bit more "hard-core" but if you are able to install the serial battery driver itself, it should not be a problem to install this additional software as well.
Initially it failed to start. The reason is probably that sometimes my batteries (I have 3) get different VRM ID's and in some cases some ID's that were previously used are no longer used after a restart. So I could end up with ID 1, 3 and 4. This causes the aggregator not to start.

The battery aggregator installs itself at VRM ID 0, however this ID is already taken by the Lynx Shunt, So I lost all info from the Shunt itself. This is easily adjusted in the code by changing the ID to an unused value. This allows the freedom to still select the Lynx Shunt as battery monitor.

My use case is slightly different than what the Gigavolt aggregator was designed for. I have a shunt and want to use it, however the aggregator takes Amps from the Multiplus instead. So far there is no option to select this.
I am trying to add it to the code. It now reads Amps from the Lynx Shunt, but for SOC no succes yet. I only have some VBA coding experience...No Python yet.

Long story short, in case the aggregator would be part of the serial-battery driver, I think it would be nice if you could select the source for for Amps, SOC and voltage. In my case the Lynx shunt voltage seems to be incorrect (it is about 0.2 to 0.3 volt too low, also without any load, so cable losses are no issue),

What would work for me is to have voltage from the batteries, SOC and Amps from the Lynx.

[transistorgit]

@mr-manuel Concerning Daly speed: currently, we are reading and writing 247 bytes in each cycle. So with a bit optimising, we could poll 4 BMS in each second without significant loss.

Up to now, I found no solution to set the address of a Daly BMS. There is a related entry in the PCMaster Software (Dalys own settings tool), but obviously, this is for use with the "WNT" board. Dalys own idea is to add these additionally "parallel" boards that do the adressing. I will investigate a bit more, but am not too optimistic.

(Probably this would end up in the invention of an own small in-line converter device at each BMS that modifies the address in real time. But it wouldn't make sense to add it to just save a 5€ serial converter. Use a Daly Bluetooth dongle then.)

[teefixx]

@gnissahr
You could try mqtt-battery from mr-manuel. I use it to aggregate two batteries, it's fully customizable, you can mix all kinds of inputs. I do this via node red, which is part of the large venusOS image.

[gambleben]

I'm interested in @transistorgit proposed solution for the Renogy driver. I haven't made any updates to it in a long time, but interested in refactoring it to use minimalmodbus (to make it easier and more reliable to pull all the values), adding in a number of alarms (recently got full documentation from Renogy), and I'd really like to figure out how to handle all 4 of my Renogy batteries as individual serial batteries, plus a "battery bank".

I also have the Renogy bluetooth module, which auto-sets the modbus addresses for each connected battery. I previously forked the project and made my own Renogy-multi driver that essentially looped through each connected battery and treated them like 1 aggregate battery. transistorgit's solution is closer to what I was hoping we could do within the project.

Finally, I also had issues with the 1 second polling interval when using 4 batteries. I think I had to increase it to 2-4 seconds to avoid issues. It might be worth making this configurable in config.ini

[Louisvdw]

@gambleben the poll_interval of the battery type handles the poll timing. So we have something similar, but it is not in config.ini.
It should be easy to add but perhaps the driver can auto adjust that depending on the amount of batteries.

[Louisvdw]

My initial idea on how to implement mulitbank is to have a master battery service. You can then decide which banks you want to have included.
There is also a secondary reason for the battery service. It help with batteries that does not have the notmal Modbus flow of requesting data to be sent. Some batteries like SBMS0 broadcast results.

When thinking of multiple devices over one RS485 port, then we do have to keep in mind this will never work for all BMS. Some BMS protocols does cater for different address. It might be easier to keep these two items as seperate developments. Keeping that in mind I also think we need to make each one look like it's own battery, and then the multi bank feature can pick this up.

[transistorgit]

I definetely agree that these are 2 disjunct features that should be developed apart from each other. A Multibank (I understand it as a "smarter, more configurable" aggregator, is on the Application level, and a bus interface implementation is just about communication level. I think a bus also has its justification as the installations are getting bigger nowadays and people will get more trouble with so many usb ports.

[gambleben]

That makes sense to me to that multiple devices over one interface is a distinct feature from aggregating all batteries. I reviewed @transistorgit's example code and I think that pattern would work well for Renogy batteries. In my config, I have a single RS485 to USB adapter and my 4 batteries are daisy chained off of that. Each device has it's own address and could be polled sequentially. I think I could make the necessary changes to the Renogy driver to support this very quickly.

Would his proposed changes require changes to the other drivers? I'd love to see us create a branch to work on this approach. I have some upcoming travel that would pull me away from the project for a couple of weeks, but I'd love to help get a working version of this in the next couple of months.

[TazerReloaded]

Another consideration for the battery master service would be the SoC source.
Average of all BMS should be the default, but my JKs drift a lot, I currently have 21% difference in SoC between them, and they only reset at 3.5V or higher, and I don't want to charge that high all the time (see #703).
I found two solutions that work very well for my setup: The SoC from VEbus (MultiPlus and MPPT counter from Victron) and the custom coulomb counter from Dr-Gigavolt/dbus-aggregate-batteries. Both agree with each other down to a few tenths.
My proposed solution would be to make configurable how the total SoC is calculated:

• average from all BMS
• specific BMS
• Victron Smart Shunt
• Victron MultiPlus
• driver coulomb counter implementation using either BMS, Smart Shunt or MultiPlus/MPPT measurements

[smurfix]

average from all BMS

That might be somewhat too naïve: if one pack is at 99% and three are at 75%, the value you actually want to work with is likely to be the former.

Thus I'd do something like

def balanced_avg(soc: list[float]) -> float:
    """
    Given an array of percentages, i.e. values in [0;1], return
    * the average if that value is near 50%
    * the minimum/maximum if the average is below 25%/above 75%
    * linearly interpolate between average and min/max otherwise.
    """
    a = sum(soc)/len(soc)
    assert a <= 1  # don't pass percentages in
    if a > .5:
        m = max(soc)
        if a > 0.75:
            return m
        return m + (a-m)*((1-a)*4-1)
    else:
        m = min(soc)
        if a < 0.25:
            return m
        return m + (a-m)*(a*4-1)
    

This breaks if the difference between max/min and average SoCs is greater than 25%, but I suspect that if that happens you have a problem that can't be fixed by refining this algorithm.

[mr-manuel]

@TazerReloaded if you want that custom options maybe the dbus-mqtt-battery is something for you. There you can aggregate the values you want with Node-RED and feed them via MQTT to the virutal battery.

[jaa2261]

That makes sense to me to that multiple devices over one interface is a distinct feature from aggregating all batteries. I reviewed @transistorgit's example code and I think that pattern would work well for Renogy batteries. In my config, I have a single RS485 to USB adapter and my 4 batteries are daisy chained off of that. Each device has it's own address and could be polled sequentially. I think I could make the necessary changes to the Renogy driver to support this very quickly.

Would his proposed changes require changes to the other drivers? I'd love to see us create a branch to work on this approach. I have some upcoming travel that would pull me away from the project for a couple of weeks, but I'd love to help get a working version of this in the next couple of months.

@gambleben I have 8 Renogy batteries that are daisy chained like yours and also using a single RS485 to USB but none of them are being detected - is this the expected behaviour with the current code base or have I got a wiring/config issue to resolve first? I'd be more than happy to help test any solution you come up with...

[seamaster101]

Would be nice to do that for the JK BMS driver as well I have 4 of these BMSs that I can install on my 4 batteries and try. Jordan

[Louisvdw]

@jaa2261 gambleben has made a custom version of the driver for his custom set up. This will not work (yet) for the current driver.

To make this work we need to some work:

1. set each BMS's address individually (manual set and only able for some BMS brands - not in the driver)
2. add support for multiple modules over one RS485 bus Multiple RS485 modules on the same interface #142
3. add multi battery module support (this issue)

[vglafirov]

This feature is highly welcome.

[jdeus]

We need a better solution, especially as no current development supports the coordinated execution of SOC_RESET_VOLTAGE

[mr-manuel]

This is now possible with the latest beta. Instead of using the SOC of the BMS, the SOC is calculated in the driver and wrong measurements can also be corrected. Check the changelog.

[mr-manuel]

See How to aggregate multiple batteries.