-
-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle multiple battery modules #8
Comments
Any updates on this? |
I'm waiting for my second BMS to arrive. Seem that the factory has run out of RS485 chips. |
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. |
@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. |
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. |
following |
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 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. |
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. |
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. |
Thanks @Hhalewijn I knew what Louis said. I just wanted to log the behavior if no one had observed it yet. |
@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? |
Bluetooth is not is the near term plan, but there is an ticket for it #13 |
@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 |
@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? |
Hi @herrep |
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. |
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. |
What install method did you use to upgrade the driver? |
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. |
Hi @coca7, 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. |
This is still relevant as we need it for other items. But we could relook at how we do the implementation. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
@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. |
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:
I added a minimal demo code below. 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.
|
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. 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. 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. 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. |
@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.) |
@gnissahr |
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 |
@gambleben the poll_interval of the battery type handles the poll timing. So we have something similar, but it is not in config.ini. |
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. 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. |
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. |
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. |
Another consideration for the battery master service would be the SoC source.
|
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. |
@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. |
@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... |
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
|
@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:
|
This feature is highly welcome. |
We need a better solution, especially as no current development supports the coordinated execution of SOC_RESET_VOLTAGE |
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. |
Handle multiple battery modules
The text was updated successfully, but these errors were encountered: