I never actually measured the difference in internal resistance of the ones we built and some we got with our EVE LF280K cells. Time to correct this …
The flexible busbars delivered with our cells have approximately these dimensions: 105mm * 20mm * 2mm. This should give us a surface area of 40mm2 and an ideal internal resistance of around 0.045mOhm (according to some online calculators).
When measuring this with our trusty and highly precise TR1035+ the result displayed is 0.08mOhm.
Pre-built busbars 105mm * 20mm * 2mm
The Klauke version which comes with tinned copper lugs gives us a reading of 0.06mOhm – despite the smaller cross-section of 35mm2. The ideal internal resistance of the copper wire could be expected to be around 0.051mOhm (according to some other online calculator), so we are much closer to the measured value.
Custom busbar 105mm * 35mm2
The display error of the TR1035+ is expected to be similar as the measured range of both busbars is quite similar. There is certainly quite an amount of uncertainty (not only due to the maximum resolution of 10uOhm) to it. But it is interesting to see that the resistance of the custom busbars seems to be lower despite its smaller cross-section – while being better insulated (not seen on the picture) and more flexible at the same time (as it can be bent in more directions).
Producing these custom busbars is certainly more expensive (a single lug costs around 1.17GBP or 1.27CHF) and involves more manual and time consuming labour. However, it is quite easy to double them and/or increase its cross-section to up to 70mm2 per wire (when using multi-stranded DIN EN 60228 conductors).
So, this is it for today with fascinating facts about busbars for LiFePO4 cells.
The other day, I realised that I never wrote about the case build of our 16s 48V batteries, as I did for the 8s case and the 4s case. So, here it is – and I am actually describing 2 revisions as we made some adjustments.
First, the total weight of the cells alone would be roughly 16 * 5.3kg ~ 85kg. This is way beyond what a single person can – or at least should – lift. So, I deciced to split the battery into 2 separate cell blocks of 8 cells each (similar as I did split the 8s battery in the Toyota HiAce). With this approach, I would be able to:
reuse the 8s design (including the RAKO boxes)
be able to move or lift half a battery (which weighs roughly 53kg)
This battery has a nominal capacity of 3.2V * 16 * 280Ah = 14'336Wh and can be charged or discharge with up to 140A ^= 7'168W. We currently have 2 of these batteries running on our 3-phase setup with 3 * Victron MultiPlus-II 48/5000/70-50.
So essentially, I built 2 8s batteries with a connection cable between cells 8 and 9. The main negative and the BMS would be in one box and the main positive with the DC breakers would be in the other box. To avoid confusion, in this setup I went for coloured Anderson SB175 housings, with
Red 2 * 35mm2 H07RN-F cable main positive
Grey 2 * 35mm2 H07RN-F cable main negative
Blue Interconnecting both blocks 2 * 35mm2 H07RN-F cable connecting from cell 9 positive to cell 8 negative
In all cases
16s Battery Connectors
To connect the cells to the BMS balancer cables I extended the balancer cables with 2.5mm2 wire via WAGO 221-2411 inline splicing connectors. I then measured the increased resistance of the additional cable length and adjusted the values in the BMS configuration for cells 1 to 9.
With these inline connectors I am now able to disconnect the blocks from each other so I can move them around independently, if needed.
On the BMS, I connected a USB RS-485 TTL adapater with a USB extension cable which leads to one of the USB ports of the Victron Cerbo GX. With the help of dbus-serialbattery and BatteryAggregator I can control the DVCC settings in Venus OS.
The rest of the build is, as I already mentioned, pretty much like the 8s build.
Revision 1
Here are some images of the completed build of revision 1.
16s Battery top view16s Battery Block 1 main negative with BMS16s Battery Block 2 main positive with DC breaker
Revision 2
These are the changes I am currently making for the next revision:
add additional connectors for the balancer cables to further facilitate the disconnection of both blocks;
use 16mm2 M6 Klauke DIN46235 compression cable lugs for the connection of the main negative (cell 16) to the B- of the BMS (only relevant to the older JK-BMS), to be able to disconnect and potentionally replace the BMS;
use a WAGO 35mm2 DIN rail connector in the main negative block on cell 1/9 for the outgoing cable;
use cable glands on the external connections; (this allows for easy disconnection and re-building the block as an 8s battery);
use ratchet straps for compressing and mounting the cells to enable easier maintainability of the cells;
use Anderson PowerPole PP180 connectors instead of SB175, so I can use mounting plates for the PP180 and do not have dangling cables on the outside of the case (these connectors are expensive and increase the price of the overall build by roughly 60GBP).
Though this could have been our first “unboxing blog post” in this article we only describe an already unboxed table grill.
Being able to have fires in the open less and less often it was time to find an electric BBQ alternative – with the constraint that it should run on a Victron MultiPlus Compact 24/1600/40-16 (or any other 1600VA sized inverter). After some frustration we finally found a nearly perfect match: the WMF Lono Quadro.
According to its spec sheet and product brochure, it uses 1250W – which is just under the nominal maximum power of 1280W that the MultiPlus can deliver.
Plus, the BBQ is relatively cheap. With a MRSP of 79.99 EUR it is available for as low as 60 EUR (PP included depending on your location). So, we ordered one of these table grills and gave it a try.
Upon powering up the device it uses its full power (regardless of the dial setting 1 .. 5) which results in a current draw of around 50A as seen on the BMS. The setting of the dial only seems to affect the intervals between heating (drawing current at 50A) and not heating (not drawing current at all).
The initial heating phase lasts naturally longer which results in the fan of the inverter kicking in at some point. But once the BBQ is at its operating temperature the fan is silent most of the time (as the heating intervals are relatively short). With 1250W nominal power consumption and a heat-up time of around 5min this consumes roughly 104Wh – about the same energy to boild 1.1l of water from 20°C.
During the use of the BBQ the inverter is pretty much at its power maximum and so has little to no resources left to power anything else. Though it seems possible to leave a fridge running, it might be better to unplug any consumers during cooking.
But all in all, with this table grill we now can do the BBQ inside (or outside) in our Toyota HiAce – even when we are on the move.
Some additional observations:
Weight The device is relatively heavy – especially the grill plate.
Size The usable size of the BBQ (270mm x 270mm) in relation to its overall dimensions seems quite large (while the whole device is still not bulky).
Power consumption Though the power consumption is rated at 1250W the heating intervals are relatively short which turn leads to a moderate overall power consumption.
Cleaning The grill plate can easily be removed and thus easily be removed (even in a dishwasher if you happen to have one in your car). Also, the drip tray can easily be removed and cleaned. Only the base plate is not meant for dishwashing.
Drip tray If the BBQ is not positioned horizontally (maybe due to the parking position of the vehicle) then the drip tray might have difficulties to catch all the fat that might float around the grill plate.
And this is it for today. Happy BBQing …
WMF Lono Quadro running from a Victron MultiPlus Compact 24/1600/40-16 at roughly 1250W/50AHeat-up time is roughly 5min when turning the dial to the maximum position
However, in this case we wanted a kind of “special” setup which included the use of MultiPlus Assistants. So, in this article I will quickly describe what we wanted to achieve and how we implemented it.
In general, when connected to shore power we want to be able to limit the AC current drawn from the shore power. This is easily accomplished by setting a limit on the MultiPlus itself – or, as in our case, via the VE.BusSmart Dongle. Though the Phoenix does have a VE.Direct interface and is able to be connected to a GX device, in our setup we did not want to use a GX device. So, essentially the Phoenix can only be controlled via Bluetooth and the VictronConnect app. But configuring the AC input limit on two devices (Phoenix and MultiPlus) is not only a nuisance from a usability standpoint, but also error-prone as one (or at least we) tend to forget things quickly. So, a different and better solution was needed.
Enter the MultiPlus Assistant in form of the Programmable Relay. With this, we can configure the built-in relay of the MultiPlus to open and close based on the availability of an AC input.
Note: we have to disable “Virtual Switch” in the MultiPlus to be able to use the MultiPlus Assistant.
The Phoenix has a Remote Input connector, that can be used to stop charging when the connection is “off”. So in our case, we enabled two Programmable Relay assistants:
Programmable Relay, NC – On/Open After 5 seconds of AC input on the MultiPlus the relay is opened.
Programmable Relay, NC – Off/Closed After 1 second of no AC input on the MultiPlus the relay is closed (which is the default state).
Below you find some screenshots with the configuration in VE Configure:
Disable Virtual Switch on MultiPlusAdd 2 Progammable Relay assistantsProgrammable Relay ON after 5 secondsProgrammable Relay OFF after 1 second
So, five seconds after the MultiPlus has power via AC input it will open the relay which in turn will enable the Phoenix to start charging.
One second after AC input is gone the MultiPlus will close the relay so the Phoenix will stop charing (if it was charging at all).
The AC input of the Phoenix is connected to the AC output of the MultiPlus. So, when there is a AC input limit configured on the MultiPlus (such as 3A @230V) the MultiPlus and the Phoenix will not be able to charge with more than 3A. And from the MultiPlus perspective, the Phoenix is just an arbitrary consumer.
This can lead to some undesired behaviour if we were to limit the AC input to e.g. 1A. In this case, the MultiPlus would – when in Inverter mode – draw from the battery so the Phoenix could charge the battery. perpetuum mobile … ? And when the AC input is gone, this means that for roughly one second the Phoenix will also charge form the battery. But this is something I can live with easily.
And if we really had a very low power AC input (of e.g. 1A) we can still unplug the remote input and force the Phoenix not to charge. Or manually switch the MultiPlus to Charger mode only.
For us this is a usable solution without the need for multiple configuration changes nor the presence of a GX device.
Now, that we got our Toyota HiAce we thought it might be a good idea to add more power to the vehicle: in form of an 8s EVE LF280K LiFePO4 battery and a Victron MultiPlus Compact 24/1600/40-16 inverter/charger. In the following, we describe our setup and the reason why we built it like this.
The Requirements
The sustained output power of the inverter must be over 1'200W.
Charging via AC via EVSE or generator must be possible.
Charging via alternator must be possible (but is not the norm).
Charging of 60% of the battery (from 20% – 80%) via AC should take less than 180min.
The installation should use the minimum amount of space possible.
We should be able to use our existing Eve LF280K cells, thus limiting the overall current to 140A.
As the vehicle will not have a diesel heater, it should be possible to run a 150W infrared heater for at least 3 * (4+2)h = 18h (^= 2'700Wh).
In addition, the battery should be able to run a refrigerator with an average power consumption of 50W for at least 72h ^= 3'600Wh (next to other power consumption).
Design Considerations
With a maximum current of 140A and a cable run length of 1.5m, we should plan with a cross section of at least 35mm2.
Basically, with Eve LF280K cells we have three choices regarding the battery size:
1* 4s (“12V”) Configuration 4 * 3.2V * 280Ah = 3'584Wh This would lead to a required nominal AC charge power of at least 716.8W/h and a charge current of at least 56A/h.
2* 4s (“12V”) Configuration 2* 4 * 3.2V * 280Ah = 7'168Wh This would lead to a required nominal AC charge power of at least 1'433.6W/h and a charge current of at least 112A/h.
1* 8s (“24V”) Configuration 8 * 3.2V * 280Ah = 7'168Wh This would lead to a required nominal AC charge power of at least 1'433.6W/h and a charge current of at least 56A/h.
The Victron MultiPlus Compact xx/1600VA inverter/charger provides enough sustained power output (while being smaller than the non-Compact edition). Depending on the voltage of the battery, this will slightly impact the amount of charge current.
To charge the battery via the alternator we would need a DC/DC converter that depends on the battery configuration as well (either 12-12 or 12-24). So, let’s have a look at the battery first.
1* 4s (“12V”) Configuration
The smallest, lightest and cheapest configuration. But capacity requirements regarding the fridge are only fulfilled, if there are no other loads. In addition, the discharge current is relatively high (scratching the maximum discharge rate of 0.5C).
2* 4s (“12V”) Configuration
More complex setup, as each battery needs a separate BMS, which leads to the need of an aggregator for both batteries to correctly report SoC and calculate CCL and DCL. In addition, more cabling and fusing is required (and probably to a large bus bar). Comes with the advantage of having a redundant battery in case a single battery fails. Most expensive configuration.
1* 8s (“24V”) Configuration
Custom battery build needed, as there is not enough space for a typical 2 * 4 cells setup behind he seats. But, only a single BMS and thus less wiring is needed. Comes with a slight disadvantage of not having native 12V from the battery. This is actually not an isse, as all our DC devices also accept 24V. Cells can better balance voltage differences across a single 8s bank.
The Setup
In the end, I decided for the 8s configuration, due to less complexity. Splitting the 8s configuration across two cell blocks seemed to be an acceptable compromise.
As a regular MultiPlus 24/1600/40-16 would not fulfill my AC charge requirements, I had to decide to either add a second MultiPlus or to add a dedicated charger. I opted for a Phoenix Smart IP43 Charger 24/25 instead of a second MultiPlus. The MultiPlus in parallel would always consume 10W though most of the time I would not need the output power. Whereas, the Phoenix would only need power, when connected to AC. And reconfiguring the MultiPlus every time I charge was not an option for me. And yes, I lose redundancy – but also save some money (Phoenix is much cheaper). So, in the end the nominal charge power is 40A + 25A = 65A, which lets me charge at 1'560W reaching 60% within 165min.
The HiAce comes with a 70A alternator, so I chose a Orion-Tr Smart 12/24-15 DC-DC Charger. With this charger, I could run the engine in standby and still have the car heater running. And this is probably the predominant use case (if charging via alternator at all).
For the DC bus bar I went for a Victron Lynx Distributor, so I could use and install MEGA fuses. Having a 1’000A bus bar seems certainly overkill, but a separate bus bar and fuse box that accepts 35mm2 cable and MEGA fuses would be not be much smaller.
I changed the existing AC inlet of the HiAce to Neutrik PowerCON True1 TOP (congrats to the marketing department, I am still amazed how this name rolls of the tongue) and installed 2 Siemens compact 16A CRCBOs (external AC in, internal AC out). I am aware that theoretically I could support more than 16A on the internal AC out (via PowerAssist). If ever needed, I can replace the RCBO with a 20A version.
I added a VE.Bus Smart Dongle to the MultiPlus and opted against a complete (Raspberry-based) GX installation. The reason, I keep a USBMK3 with me anyway (in case I need to reconfigure the MultiPlus) and still have (Bluetooth) access to the most important settings and information of the MultiPlus. With the GX, I would to be running a WiFi hotspot (and consuming more energy as well). The disadvanage of not being able to use DVCC with information from the BMS is clear to me and accepted.
I selected a B2A8S20P JK-BMS that has an integrated 2A balancer and an RS485, CAN and heat port. In case, I ever add a GX device, I am still able to connect them and use DVCC.
The Specs
Nominal power (“capacity”) 8 * 3.2V * 280Ah = 7'168Wh
Maximum discharge power 1’600VA (1'280W, capped by the inverter) with a maximum current of 80A/63A/55A (at 2.5V/3.2V/3.65V)
Maximum AC charge power 1'560W
AC Charging from 20% – 80% in 165min
Maximum DC charge power 360W
MultiPlus self-power consumption 10W
The Build
As mentioned before, due to space constraints I had to split the battery in 2 parts (with each having 4 cells). Instead of using utz RAKO boxes I used 12mm (sanded) plywood which I did not screw together but tied down with a banding/tensioning tool and a ratchet strap. With this setup, I can easily access und disassemble the cells if needed, while still having a sturdy case. Both cell blocks are connected with a (blue) Anderson SB175 connector.
The BMS itself is mounted to the side of one of the cases (I took extra care to use short screws, in order not to drill into the cell casing). I used M6 Weidmüller 35mm2 90° angled compression cable lug to get the wire away from the BMS and into the bus bar. All other compression cable lugs are DIN 46235 from Klauke (M6 35mm2 on the cells, and M8 16mm2/35mm2 on the bus bar).
The AC and DC wires are all Eland H07RN-F (except for the last two points):
Charger to bus bar, battery to bus bar: 35mm2
Cell block to cell block: 2 * 35mm2
Alternator to DC-DC converter, DC-DC converter to bus bar: 16mm2
External AC in to RCBO, RCBO to inverter/charger (both directions), RCBO to internal AC out: 3G2.5mm2
For the connection of the Inverter/charger to the bus bar, I used the Victron installed 25mm2 welding cables.
Images
The installation is barely visible behind the seatsView from the back with preliminary wiringConnection of cell blocks with SB175 connectors, cell block 2 and DC-DC converterLynx Distributor with cell block 1Inverter/charger with space for second charger and cell block 2 (left)
Note: the Phoenix charger is not visible on the images, as I am still waiting for it to be delivered.
Charging via EVSE
Conclusion
We now have more than 7'000Wh of additional energy without losing any storage space for roughly 2'850 CHF/2’500 GBP (parts without labour). We can survive an extended weekend of 72h without recharging while still being able to enjoy amenities as using a coffee machine, heating and refrigerator. In case of longer periods of usage, we can recharge at any EVSE, or via shore power. And in emergencies, we can also charge via our Honda EU10i or via the alternator of the vehicle.
The battery is placed directly over the engine which helps in cold weather conditions to easily warm up the batteries to a chargeable level.
When setting up a Raspberry Pi to run Venus OS, the GUI is not available on the local HDMI port – it is running headless by default. However, in order to connect to a Wireless network, we need to access that UI.
As mentioned in the above link, there is a workaround to it: renaming (or removing) the /etc/venus/headless file. This can be done by connecting via the serial port to the PI using the Adafruit USB to TTL serial cable. There is a very thorough article on how to connect to the port.
In short, pin 8 (GPIO14, TX) is white; pin 10 (GPIO15, RX) is green and pin 6 can be used as ground (black) and DO NOT USE the red wire. See here for the actual Pin layout. We can then use Putty to make a connection to the Pi (at 115200bps).
So far, so good. However, when trying to rename the headless file the following error message appears: mv: can't rename 'headless': Read-only file system
Connecting to Wi-Fi with via Bluetooth and Victron Connect
In case you only want to connect to Wi-Fi and do not happen to have a serial cable, but you want to use the Raspberry Pi’s bluetooth connection, you can use Victron Connect to configure wireless network settings.
For this you start up Victron Connect on an Android (or Apple i device, Windows will nork work for that) and discover the Raspberry you want to connect. When pairing with the Pi use 000000 as the pin code.
After that you will find the gear icon in the upper right corner. From there you can select Network settings and connect to your WLAN.
Below you find some screenshots.
Bluetooth connection to Venus OS via Victron ConnectConfigure Network settingsConnecting to a WLAN
When we run Venus OS without any modifications on a Raspberry Pi 400 no WiFi is detected – though the Pi 400 certainly has WiFi onboard.
As it seems, I am not the first one to notice that. bipedalprimate presented a solution by copying a bunch of Raspbian /lib/firmware files to the Venus OS. But as it turns out, things can be achieved much simpler.
It seems, that the driver on the 400 is differs from the chipset of a _regular_ Pi 4: it is the brcmfmac43456.
When looking at the /lib/firmware/brcm folder of a Venus OS these drivers are missing:
Venus OS v3.00 contents of /lib/firmware/brcm
On a Raspberry Pi 400 things look different:
Raspberry Pi 400 Raspbian 6.1.21 contents of /lib/firmware/brcm
As it seems, only a few files are required for a Raspberry Pi 400 and only a few belong to the brcmfmac43456. Most of the files are in fact links to other files (and some are in the cypress directory).
So, I did the following: I copied the brcm and cypress directories to a USB stick and inserted it into the Pi 400. From there I copied the driver files to the respective directories inside /lib/firmware, added some links and adjusted the permissions. Below you see the commands I used.
Note1: I am a novice when it comes to Linux, so pls do not expect any sophisticated shell scripting.
Note2: by default the root file system is _read-only_. Therefore I re-mounted it as read-write (so, maybe our changes will not survive a firmware update).
Note3: my USB stick was mounted as /run/media/sda1. Yours might be different.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In our trailers and vehicles I prefer 24V 8s batteries, as the price-weight-power triangle of our Eve 280Ah cells is hard to match. With a gross weight of roughly 55kg we get a nominal “capacity” of 7168Wh. Even at a low cell voltage of 2.7V we can still get more than 2400W (3000VA) out of the battery. Exactly what a Victron MultiPlus-II 24/3000/70-32 (or any 3000VA inverter/charger for that matter) can deliver.
The Honda EU 10i has a sustained output of 900W which equates to roughly 3.9A at 230V. Now, this is not too interesting by itself.
However, the minimum AC current input of the MultiPlus is 3.6A. So, exactly within the range of the Honda EU 10i. A 5000VA inverter for example, would drain the generator with its minimum input of 4.6A+. And with its fuel tank capacity of 2.1l it runs nearly 4h on full load. Which in turn means, I can charge our 24V 8s battery about 50% without refueling.
Note: ideally we would charge it from 25% up to 75% SoC.
So, for me this generator is the ideal backup when I am away without any EV station nearby. With its 13kg and small form factor (and price) there is always a place in my vehicles where I can put it.
And as a side benefit: when I run the generator along with the inverter I can generate up to 3300W (or over 14A). That is: run my oven and boil potatoes at the same time …
And the generator even makes sense when combined with a Victron MultiPlus Compact 24/1600/40-16 (or its 12V counterpart). They are the smallest inverters/chargers in that power range. They strong enough to run a coffee machine or immersion water heater, but are not pwoerful enough to run a full 2000W appliance. However, in combination with the Honda, they just reach 2180W. Of course, charging a 24V 8s battery with a “Compact” device takes much longer, due to its smaller charger.
Along with some others I am waiting for Raspberry PIs to become available again (while *not* supporting these overpriced resellers on eBay, Amazon and elsewhere).
Luckily, back in 2016 (or was it 2015?) I bought two Raspberry PI2 Model B Rev. 1.1 with 1 GB RAM and an Edimax EW-7811Un WLAN adapter. At that time the PI did not have built-in WLAN and it was said that the original Wifi dongle Raspberry Pi WLU6331 did not work with all distributions.
We had some plans what to do with the Pi – but they never made it into reality. Instead, they went into the locker.
Edimax EW-7811Un WLAN adapter
Fast forward into the future, the whole world experiences stock supply shortages and a Raspberry Pi (now in its 4th generation) is hard to get hold of.
As I am building a couple of batteries mostly with JK-BMS I need a RS-485 connection to my Victron inverters to control charge and discharge currents. Except for the GX versions of the MultiPlus-II and EasySolar-II that _sort of_ support RS-485 (not out-of-the-box, but) in a single box, I always need an additional device like a Cerbo, BBB or: a Raspberry Pi!
But as I already wrote: I did not want to support resellers with their pharmacy pricing, so I had a look at the Venus OS compatibility list and saw that – surprisingly – even a Pi 2 is supported. So, I went looking in my shelves, lockers and other places to find these rusty old Pi 2s – and after a couple of weeks I actually found them (when I was looking for something completely different). Anyway, here they are – but only with a single GB of RAM.
Nostalgic side note: yes, there were times where I would have left out the word “only” …
I was not to sure if Venus OS would run on it. And if – how quick. It was time to find out …
Installation was straight forward: following Getting Started was all it needed. I connected the Pi to my local wired network for that purpose and makes updating and installing software much easier. At the very start I also enabled superuser and SSH access.
Note: There was a minor issue or whatever one might call it. After the install of v3.00 (via the SD card) I had the device check for an update (which at that time should not have been available). But for whatever reason, I was offered to update from v3.00 to v3.00. I did that and it worked and after that no more updates were recommended.
From then on, installing additional packages worked without an issue – but took considerably longer than on a Cerbo, Pi 4 or even the GX in the EasySolar.
One thing just seemed to be missing. Having the Pi to act as a Wifi access point (and router with DNS and DHCP). Why would I want this?
Some of my batteries are just standalone installations in a car, trailer or other machinery. And external network is not always available. And I do appreciate the comfort of wirelessly connecting to the GX – just as I am used to when using my EasySolar-II GX.
And as nearly always: I was not the first one to ask for such a feature:
After a reboot, I could successfully connect to the access point and VictronConnect immediately found the “Cerbo”:
Raspberry Pi 2 Model B Rev. 1.1 as a Victron GX device while acting as an access point
After I enabled the access point (or tether option) I could no longer see or access any other SSIDs from the Pi:
WLAN client is deactivated when running an access point
Running ifconfig gave me this output:
ifconfig output after enabling the access point
Certainly, I was interested in the performance or resource consumption of the Pi 2. As it turned out, the UI really took some CPU but the additional network services themselves were not quite as hungry: idle floats between 71% and 92%.
Pi 2 running with a RS-485 adapter and enabled access point
So, this is it. My investment of roughly 35$ in 2016 (even with intereste rate) really paid off. I have a working GX device that does everything I want – plus an access point – all in a single box.
Pi 2 running with dbus-serialbattery, BatteryAggregator and access point
Top balancing is a topic where a lot of people have written about – and now it is my turn …
It is common understanding to use a regular charger when top balancing, and one the one hand set the Charge Voltage Limit (CVL) to cellCount * 3.65V and use a reasonable current and wait for an extended period of time until all cells have reached their cell voltage maximum. And reasonable means to use a current where the BMS balancer keep up with and distribute the Amps across the cells without going into a Overvoltage (OVP) for a single cell.
So, instead of using a charger with a high supported current of at least 20A we now can use our regular Victron MultiPlus-II inverter/charger – with the help of Venus OS.
The reason why we cannot use a Victron MultiPlus-II out of the box as a charger is the fact, that is does not support fixed Amp configurations (only maximums). And after a while at a specific voltage the MultiPlus-II would enter Absorption phase and thereby reducing the current over time and stopp charging after a while altogether.
So with the help of a custom service (or Python script based on the dummyservice) we can create a battery monitor and set a fixed current.
I am not going into details on how to get a Venus OS device (Victron Cerbo GX or Raspberry Pi) up and running. There is plenty of information on the internet. Or have a look at this article where I briefly describe the setup of a Pi for our BYD battery system.
The *service* itself can be run from a shell: /data/VirtualBatteryMonitor/VirtualBatteryMonitor.py (I copied the script into /data to survive a firmware update).
And then the service should appear in the “Device List”:
Our service as a device to support a constant charge current
There are two more configuration entries needed:
Enable our service as “Battery Monitor” (Settings, System setup, Battery Monitor)
Our service configured as a “Battery Monitor”Enable DVCC
The actual parameters (charge current and maximum voltage) can be configured via dbus-spy from a shell:
Service parameters as shown by dbus-spy
The actually configured values are then shown under “Parameters” of the service (Service, Parameters):
Current configuration set to 5A constant charge current
Note1: There is no need for an actual integration of the BMS with the Venus OS.
Note2: Use at your own risk. Misconfiguring could potentionally harm the BMS, the battery or both.
Note3: Do not leave the script running / the battery charging unattendedly.
#!/usr/bin/env python3
"""
A class to put a simple service on the dbus, according to victron standards, with constantly updating
paths. See example usage below. It is used to generate dummy data for other processes that rely on the
dbus. See files in dbus_vebus_to_pvinverter/test and dbus_vrm/test for other usage examples.
To change a value while testing, without stopping your dummy script and changing its initial value, write
to the dummy data via the dbus. See example.
https://github.com/victronenergy/dbus_vebus_to_pvinverter/tree/master/test
"""
from gi.repository import GLib
import platform
import argparse
import logging
import sys
import os
import dbus
import os
# our own packages
sys.path.insert(1, os.path.join(os.path.dirname(__file__), "../ext/velib_python"))
sys.path.insert(1, "/opt/victronenergy/dbus-systemcalc-py/ext/velib_python")
from vedbus import VeDbusService
from vedbus import VeDbusItemImport
class VirtualBatteryMonitor(object):
def __init__(
self,
servicename,
deviceinstance,
paths,
productname="MultiPlus Charger",
connection="dbus",
):
try:
# Connect to the sessionbus. Note that on ccgx we use systembus instead.
logging.debug("Opening SystemBus ...")
dbusConn = dbus.SystemBus()
logging.info("Opening SystemBus SUCCEEDED.")
except:
logging.error("Reading system SOC FAILED.")
logging.debug("Opening dbus '%s' ...", servicename)
self._dbusservice = VeDbusService(servicename)
logging.info("Opening dbus '%s' SUCCEEDED.", servicename)
self._paths = paths
logging.debug("%s /DeviceInstance = %d" % (servicename, deviceinstance))
# Create the management objects, as specified in the ccgx dbus-api document
self._dbusservice.add_path("/Mgmt/ProcessName", __file__)
self._dbusservice.add_path("/Mgmt/ProcessVersion", "Unkown version, and running on Python " + platform.python_version())
self._dbusservice.add_path("/Mgmt/Connection", connection)
# Create the mandatory objects
self._dbusservice.add_path("/DeviceInstance", deviceinstance)
self._dbusservice.add_path("/ProductId", 0)
self._dbusservice.add_path("/ProductName", productname)
self._dbusservice.add_path("/FirmwareVersion", 0)
self._dbusservice.add_path("/HardwareVersion", 0)
self._dbusservice.add_path("/Connected", 1)
# Create all the objects that we want to export to the dbus
self._dbusservice.add_path('/Dc/0/Voltage', 3.4 * 16, writeable=True)
self._dbusservice.add_path('/Dc/0/Current', 5, writeable=True)
self._dbusservice.add_path('/Dc/0/Power', 3.4 * 16 * 2, writeable=True)
self._dbusservice.add_path('/Dc/0/Temperature', 15, writeable=True)
self._dbusservice.add_path('/Dc/0/MidVoltage', None)
self._dbusservice.add_path('/Dc/0/MidVoltageDeviation', None)
self._dbusservice.add_path('/ConsumedAmphours', 123, writeable=True)
self._dbusservice.add_path('/Soc', 75, writeable=True)
self._dbusservice.add_path('/TimeToGo', None)
self._dbusservice.add_path('/Info/MaxChargeCurrent', 5, writeable=True)
self._dbusservice.add_path('/Info/MaxDischargeCurrent', 0, writeable=True)
self._dbusservice.add_path('/Info/MaxChargeVoltage', 3.65 * 16, writeable=True)
self._dbusservice.add_path('/Info/BatteryLowVoltage', 2.75 * 16, writeable=True)
self._dbusservice.add_path('/Info/ChargeRequest', False, writeable=True)
self._dbusservice.add_path('/Alarms/LowVoltage', 0, writeable=True)
self._dbusservice.add_path('/Alarms/HighVoltage', 0, writeable=True)
self._dbusservice.add_path('/Alarms/LowSoc', 0, writeable=True)
self._dbusservice.add_path('/Alarms/HighCurrent', 0, writeable=True)
self._dbusservice.add_path('/Alarms/LowCellVoltage', 0, writeable=True)
self._dbusservice.add_path('/Alarms/LowTemperature', 0, writeable=True)
self._dbusservice.add_path('/Alarms/HighTemperature', 0, writeable=True)
self._dbusservice.add_path('/Capacity', 156, writeable=True)
self._dbusservice.add_path('/CustomName', "Virtual Battery Monitor (%/V/W)", writeable=True)
self._dbusservice.add_path('/InstalledCapacity', 280, writeable=True)
self._dbusservice.add_path('/System/MaxCellTemperature', 15, writeable=True)
self._dbusservice.add_path('/System/MaxCellVoltage', 3.4, writeable=True)
self._dbusservice.add_path('/System/MaxTemperatureCellId', "C5", writeable=True)
self._dbusservice.add_path('/System/MaxVoltageCellId', "C2", writeable=True)
self._dbusservice.add_path('/System/MinCellTemperature', 15, writeable=True)
self._dbusservice.add_path('/System/MinCellVoltage', 3.4, writeable=True)
self._dbusservice.add_path('/System/MinTemperatureCellId', "C6", writeable=True)
self._dbusservice.add_path('/System/MinVoltageCellId', "C3", writeable=True)
self._dbusservice.add_path('/System/NrOfCellsPerBattery', 16, writeable=True)
self._dbusservice.add_path('/System/NrOfModulesBlockingCharge', 0, writeable=True)
self._dbusservice.add_path('/System/NrOfModulesBlockingDischarge', 0, writeable=True)
self._dbusservice.add_path('/System/NrOfModulesOffline', 0, writeable=True)
self._dbusservice.add_path('/System/NrOfModulesOnline', 1, writeable=True)
self._dbusservice.add_path('/System/Temperature1', 15, writeable=True)
self._dbusservice.add_path('/System/Temperature2', 15, writeable=True)
self._dbusservice.add_path('/System/Temperature3', 0)
self._dbusservice.add_path('/System/Temperature4', 0)
# === All code below is to simply run it from the commandline for debugging purposes ===
# It will created a dbus service called com.victronenergy.pvinverter.output.
# To try this on commandline, start this program in one terminal, and try these commands
# from another terminal:
# dbus com.victronenergy.pvinverter.output
# dbus com.victronenergy.pvinverter.output /Ac/Energy/Forward GetValue
# dbus com.victronenergy.pvinverter.output /Ac/Energy/Forward SetValue %20
#
# Above examples use this dbus client: http://code.google.com/p/dbus-tools/wiki/DBusCli
# See their manual to explain the % in %20
def main():
logging.basicConfig(level=logging.DEBUG)
from dbus.mainloop.glib import DBusGMainLoop
# Have a mainloop, so we can send/receive asynchronous calls to and from dbus
DBusGMainLoop(set_as_default=True)
pvac_output = VirtualBatteryMonitor(
servicename="com.victronenergy.battery.VirtualBatteryMonitor.ttyO1",
deviceinstance=0,
paths={
"/Ac/Energy/Forward": {"initial": 0, "update": 1},
"/Position": {"initial": 0, "update": 0},
"/Nonupdatingvalue/UseForTestingWritesForExample": {"initial": None},
"/DbusInvalid": {"initial": None},
},
)
logging.info(
"Connected to dbus, and switching over to GLib.MainLoop() (= event based)"
)
mainloop = GLib.MainLoop()
mainloop.run()
if __name__ == "__main__":
main()
For my use case, this really helps as now I have a powerful charging (3 * Victron MultiPlus-II 48/5000/70-32 in parallel) that can charge the battery initally with 140A+ and later with smaller and smaller currents until all cells have reached their maximum voltage.
Our Journey to Scotland 