I’ve searched extensively on the forum but can’t find anywhere this has been covered already. I have 6 Victron Lithium Smart 25.6V 200Ah batteries connected in 2S3P configuration for a 48V off-grid system. I’ve not bothered with smart shunts so far but am thinking of adding this capability. I use a Raspberry Pi to monitor the MPPTs (via VE.Direct to USB cables) and Inverters (2x Phoenix 5000VA 48V in parallel, via VE.Bus BMS and VE Interface Mk 3 VE.Bus to USB).
The batteries are connected in series pairs, fused via NH00 160A fuses, then paralleled via a pair of chunky home-made solid copper busbars and all the loads connect to the busbars via individual fuses.
If I fit a single Smart Shunt to the system, I will need to create a separate battery -ve busbar and install the shunt between this and the load busbar. Alternatively if I fit 3x Smart Shunts, one in the negative cable to each battery from the busbar, I won’t need a separate busbar.
It can handle many smart shunts, as I understand. I have two in my system, one for total battery system monitoring, the other to monitor one of my two banks in parallel.
The limitation I believe will impact what I think you’re trying to do, is that Venus OS and Victron Connect do not have a simple function to combine multiple smart shunt readings into one aggregate virtual smart shunt.
Yes, you can use Node Red and create a virtual battery as the master one and choose this as the batterymonitor. You can add a third party battery aggregator script, search the forum for battery aggregator.
Thanks PWF I’ll have a look. Any thoughts on the pros and cons of single vs multiple smartshunts (apart from the cost)? Another busbar to enable use of a single shunt would probably cost me about £20 for the copper. And take an hour or so to drill and tap it. Plus time to crimp and heat shrink more lugs and short cables.
Given there are sometimes issues reported with aggregators displaying correctly in VRM portal (from what I’ve read in this forum) I’m tempted to go with 3 smart shunts as I will then get a good insight into the state of each battery bank to see how they are performing relative to each other. But will this be a problem for the BMS - having 3 sources of SOC might cause odd behaviour? Or would it not work correctly without an aggregator? If that’s the case I would lean towards a single shunt and a new battery negative busbar.
Interesting. It also answers a question I had about whether it’s possible to run additional processing tasks on a RPi outside the Venus OS process. For example, communication with a bespoke temperature sensor. I think from a quick look at your GitHub read me that’s what you’ve created as a separate preprocessor function. This is slightly off topic but I was considering an Arduino to handle the temperature sensor and forward the data to the RPi. Anyway, I’ll have a look into your code and see how I can use it with multiple smart shunts in my installation. Thank you.
How exactly does that work with multiple SmartShunts? Isn’t your script merely a BMS aggregator? Don’t get me wrong. Just asking…the probalby obvious question to which I have no answer.
Well the logic can aggregate anything and present that aggregate to the dbus.
Since the main problem with victron is that it will only present a single point to the frontend. You can’t give it multiple single devices and expect it to read their values. So you need to do that beforehand and pass a virtual device to the dbus.
You can put any sort of logic in that virtual device, group devices, put them behind relayed switches etc.
This is useful for dumb batteries and groupings being switched or dis/connected without soc logic loss.
Say you want two banks. You want to keep the one at 100% soc then disconnect until you need it. This virtual device logic should allow for that.
It doesn’t need to be sensed, it can just be virtual.
And my solution is not at all like a professionally created add-on, it just fulfills a limitation in the cerbo right now. Because victron does indeed have a placeholder in the code for aggregate mode which is not yet implemented. So that should be coming soon. It’s an idea of how that could be implemented. Though I have to admit I know way too little to be sure it’s a good solution. Time will tell.
Until then I felt it was a good bit of gadget that could help the community with a core issue that alot of us seem to face.
In my opinion, the more shunts you have, the less likely it is that they will sense correctly. Especially if they aren’t perfectly calibrated.
So by aggregation, you should be able to lessen the amount of sense that could cause differences over multiple cycles.
By passing actual values, you negate having devices desynchronize over time. I have 7 shunts in my system and I can tell you that after about a year, I really want to get rid of the core shunt values and only leave a single aggregated shunt on each of my batteries. Because those are the protection shunts. Those are the ones that controll shut off and disconnect relays.
The others are just there because the cerbo needs a single point frontend.
I set up my system in exactly the same way, except for the expensive Victron batteries. I use MQTT Battery to aggregate the Smartshunt values. You just have to make sure that the USB interfaces of the Smartshunts are galvanically isolated. I use two Multilpluss 5000 and one MultiplussGX. I had already destroyed the USB interface of this GX, as there is no reasonable information to be found on the SmartShunts. I run the entire system together with a self-built web interface and a logging function on the integrated NodeRed server.
