Aggregate multiple battery modules of the same type under one VRM instance/Device ?

[JoshuaDodds]

Ok maybe its misconfiguration or i missed something in the docs but it seems counter-intuitive to me that multiple bms's of the same type are not exposed as a single device in VenusOS and that it should be possible to do so without the need of a third party battery aggregator.

Am i missing something in configuration or would this be a good candidate for a new feature?

I understand the difficulties and complexity scope of including an aggregator of different bms types in this project (especially when there are other projects that already address the project well) but it doesn't seem like it would be too complex to aggregate in this project batteries of the same type.

@mr-manuel Am i missing something basic here that would prevent this from being practical? I am thinking to start working on this and submit a PR unless you already are against the idea from the start ;) Let me know your thoughts!

Cheers!

[mr-manuel]

By default, Venus OS is made to support only one battery. Indipendend of how you like to aggregate the batteries, you will always need an extra service for that, except they are daisy chained.

If you attach multiple devices of the same type to a computer they never appear as one aggregated device, unless you configure it in some way. So it should be counter intuitive, that it's merged automatically.

Adding it directly to this driver will make it more complex and you are making something complex that already exists. Probably it would be better to solve some issues with existing aggregators and improve them.

About 70% of the dbus-serialbattery users have only one battery, only 20 % have two batteries and the rest more.

What would be the benefit of having a battery aggregator included in this driver except for a second install script you need to execute? You anyway have to configure it seperately else the config file is exploding and getting even more complex.

[JoshuaDodds]

Hi @mr-manuel,

Thanks for the feedback. I guess i should have been clearer. When i say multiple batteries of the same type I also meant in a daisy chained configuration. Perhaps an explanation of my use case would make it more clear:

I have x 7 Daren485 modules daisy chained via the serial ports and 1 of them is set to master mode with dip switch 5 and 6 in the up position and then connected to the CerboGX with BMS-Canbus interfacing. When you do this it shows up as a single battery indeed in VenusOS but with 7 modules online and the benefit of this is that the Master module aggregates the data from all 7 modules and sends that over CAN to the Cerbo and on the Cerbo then you can see highest/lowest temps and cells across the entire 7 modules, have an entire Capacity display of the whole stack of batteries, charge and discharge limits are summed amounts from all 7 batteries and so on. Basically everything a battery aggregator does. The only downside to this is that this battery does not expose all the rich data in the proper way over CAN to the cerbo so when i use dbus-serial i get much more data from the modules that shows up in the Cerbo than what i get over CAN. So my benefit in doing this would be better data, visibility and finer-grained control with dbus-serial then the support built into the battery itself for communication with the Cerbo. I was considering changing the way i connect the stack of batteries to the Cerbo (switch to dbus-serial) and it just occurred to me why not have the option to expose same BMS's to the Cerbo as modules tied to a single device rather than 7 different modules that then need ANOTHER external piece of software to aggregate them again and provide a single point of control for Battery Monitor, Measurements, and Temps.

The idea is not to have a second install script and a separate aggregator. My proposal is to make a BOOL flag in config for this mode where if True AND you have defined more than one BATTERY_ADDRESS in the confic file as well, A single device shows in CerboGX with X modules online and the way the information is created for this device by debus-serialbattery mimics a CAN attached master battery aggregating the data from itself and its connected slaves. Basically the device would look and appear like a BatteryAggregator created device but possibly with richer data since there is more exact data commonality between modules of the same BMS type.

I have not deeply dived into the entire codebase yet but to me it doesnt initially sound too complex since we basically have in memory objects for each connected module with all the numbers we need to aggregate that data for each metric and telemetry item and we just need to synthesize maybe a few items/attributes that dont exist yet (like modules online, offline totals, for example). But i mean, most of the numbers needed for aggregation are just simple math operations against the same attribute/property on each battery object we initialize on startup and re-calculating those number on each iteration of the refresh_data loop.

What do you think? Would you consider merging something like this if built in such a way that it very minimally touched existing logic and only extended existing logic with extended or new methods which were used only if this setting was turned on and more than one module was configured and all modules were of the same BMS_TYPE? If you are fundamentally against the idea, I would like to know it up front before i try doing this in a way to compliment this project. If this project wont benefit from the effort I can better fork, hack it in the way it works for me, and maintain my own fork of this project.

Let me know your thoughts...
JD

[mr-manuel]

Displaying daisy chained batteries as one could be easy and ressource saving. The idea of you adding only one parameter to enable/disable it would be ok. The only question is, if the users will understand, that the batteries have to be on the same port of the GX device. Very likely there will be some users that don't get it, but let's try.

[JoshuaDodds]

I will try to mitigate this issue of user confusion by very clearly documenting in the config file the valid use cases and obviously set it to False by default. Hopefully then its just a matter of users needing to delve into the documentation to understand how to get this feature. If most are not having more than one or two batteries and dont understand the benefits this feature provides they will never even know it exists. Those who do know what they want will find the documentation i will update for it. At least that;s the hope and plan :)

I will probably work on this in the coming weeks or so and tag you when i have something ready. Thanks for the feedback!