I have two Lifepo4 Batterypacks with 16kWh and a JKBMS (v15) each. The BMS are paralleled and connected to my GX device via Can (which the newer JKBMS now speak natively). This works well and has the advantage that the current is adjusted when one of the packs is full or empty.
I also have a SmartShunt for more precise monitoring, since the shunt in the JKBMS is not as accurate, especially for small currents. With regular small loads (e.g. ~300W at night), the SmartShunt is much better estimating the SOC over long periods of time. On the other hand, the SmartShunt cannot signal the preferred current, e.g. when one of the packs is full or empty.
I would therefore like to somehow get the best of both worlds. SOC and amps from the SmartShunt and the remaining details from the BMS. I know there’s no official support for such a setup, but I think it’s likely a fairly common or desirable setup for cases where the internal BMS shunt is simply not as good as a Victron SmartShunt.
Has anyone thought about this as well or has a good idea how to best implement this? My current idea is writing a custom driver that takes the information from both devices via dbus and registers a new virtual dbus device with the combined information. I know how to do this, but maybe there’s a better solution I’m not aware of?
The JK bms has 2 programmable dry contacts that you can use. You could do something pretty simple in node-red using the relays on the gx-device and DVCC, ESS to control current and inverter power. I do this with my 12V systems based on voltage to increase the charge current when the voltage is low and slowly taper off when the battery is filling up. I don’t use communication from the BMS and I don’t even use a shunt anymore. The multiplus estimates the battery SOC very well. It will be pretty easy to send a signal to the gx-device to reduce charge current based on the state of the relay or change inverter power in ESS when the battery is off. You are basically unlimited by your imagination.
I already have all required information in my GX device (the problem is merely combining it), I’d rather not extend the hardware setup by using the dry contacts, but interesting approach, I had not thought about this.
Thanks, I’m aware of this, thankfully it’s not longer necessary to use this custom driver with newer JKBMS software versions. They can directly speak a can dialect Victron understands, so I only need to plug in the cable and see the required information from both battery packs.
I tried the whole communication from the BMS to gx device and did not like the fact my system would alarm or shut down because my battery was not happy. I also found the shunt to be extremely inaccurate and many Ahrs left in the battery and happy to run them to low voltage disconnect. I have 3 ESS’s running at the same time and have many node-red instances with different flows on each gx device to make the system do what I want it to do.
Can you get the JK info in node-red so you can do what you like with the system? I have never tried. I did set up a shelly uni to measure half the cells in a 48V pack for some automation and management which I could program in node-red but never really needed it in the end.
For me it worked perfectly fine so far, but I did have to update the JKBMS to the latest firmware to get rid of some issues (there have been fixes after some YT Videos by Andi from offgrid garage). What kinds of alarms were you experiencing?
I haven’t used node-red and don’t really see the need to, given that the current setup works fine. Also, my Multiplus 2 GX doesn’t support node-red natively afaik. But I have enough coding experience to implement a virtual battery device using velib_python, simply reading the two device entries and writing the combined info to a new one shouldn’t be so difficult.
When the battery was new I was getting high cell voltage alarms.
If you install the Venus OS large image you can use node-red from the VRM portal. You have dev experience it will be a piece of cake for you to navigate.
That sounds like a reasonable alarm though, right? When a cell has a too high voltage an alarm should be raised so that charging is interrupted. With the new JKBMS firmware that should be less likely to occur as the BMS (if properly configured) will request reduced current before a cell reaches the over voltage protection threshold.
While implementing my own solution, I found that something similar exists:
I still went ahead and implemented my own solution. For one, I also wasn’t quite sure how to achieve the same with BatteryAggregator, but also I simply enjoyed the coding challenge / learning experience. In case anyone is interested, you can find it here:
I am sure you can tinker with it and get it to work. I could not see this as particularly useful information in a multi-battery system when one is balancing while the others are still charging. I just prefer to use one ecosystem and let the BMS do what it is programmed to do, balance, overcurrent, high and low cell disconnect. I probably would not get any alarms now only charging to 55.2V. It’s good you found a good project to solve it.
Well, you now have your own solution, so just for future reference, what also works is: JK-BMS connected via RS485 and dbus-serialbattery (which can do a lot of nice things like reduce the charge current based on temperature), and then aggregate those with yet another aggregator (GitHub - Dr-Gigavolt/dbus-aggregate-batteries: Virtual service to merge multiple serial batteries) which has config options to use a smartshunt, or do it’s own SOC calculation based on the Multi’s DC values.
Last night, while staying up late hoping to catch a glimpse of Santa, I watched Andy’s JK BMS video on Off-Grid Garage. It got me thinking about potential use cases. For example, this approach could be useful for setups with multiple small batteries, each equipped with its own small BMS, connected to a large inverter.
However, it doesn’t seem as practical as my Node-RED flow, which dynamically manages the charging process. My flow allows the system to charge at maximum current up to a specific voltage, then gradually tapers the charge current to near zero once the batteries are full and the balancers are active.
If they could implement a similar logic—rather than adjusting the maximum charge and discharge current based on the state of individual BMSs—I might reconsider the utility of their communication setup.
Why not use the smartshunt as standalone and just put a small display beside GX? Or an old tablet, etc. I’d keep it simple, above a lot of overkill advice to be honest.
Because the SmartShunt can’t tell the GX when e.g. a single cell is close to the over voltage protection threshold and therefore the current should be reduced.
