Tag: Raspberry Pi

Current state of our electric installation

I recently wrote about our upcoming solar PV adventure. But before updating our system, I thought it was time to document and explain our current setup (with the help of KiCad).

This system is the main electricity for our barn and currently consists of three batteries with an energy (often referred to as “capacity”) of 3* 14.33kWh = 43kWh (battery bank A, A1:A2 on the plan). These batteries are charged by a JCB G20QS (B1) via three MultiPlus-II 48/5000/70 inverters/chargers (B1:C2) which are by default in “Charge Only” mode. The MultiPlus-II are configured in a 3-phase configuration but only turned on when 3-phase is actually needed.

The main power is delivered by a MultiPlus-II 48/3000/35 (B4:C5) that is connected to a separate battery bank (battery bank B, BYD LVS Premium Battery-Box with an energy of 8kWh). This latter MultiPlus-II is connected to L1 of the 3-phase MultiPlus-II. So, whenever the main batteries get charged the cascaded inverter will also be charged. In addition, we can then use PowerAssist to up to supply 8'000VA (= 5'000VA + 3'000VA) when running on batteries and up to 14'500VA (= 6'500VA + 5'000VA + 3000VA) on a single phase.

Though the generator can supply up 14'400W the chargers of the Multiplus-II can only charge with a power of up to 3* 48V* 70A = 10'080W. This is actually an advantage as the optimal efficiency factor of the generator is roughly at 12'000W. So with 210A we are pretty close. If we ever added more chargers to the system we could even slightly increase the charge current to 250A.

System A with the 3-phase inverter configuration is connected to a Lynx bus bar (A1:B4) that also includes a Lynx shunt (B3) used for measuring over all batteries. In addition, there is an islolated Orion-Tr DC-DC charger (A5) that constantly feeds system B.

System A and B are connected to their separate GX:

  • system A
    Cerbo GX, A5:A6
    MultiPlus-II via VE.Bus, Lynx Shunt via VE.Can, JK-BMS via RS485/USB
  • system B
    Raspberry Pi4 running VenusOS, B5:B6
    MultiPlus-II via VE.Bus, BYD BMS via VE.Can (on a Pi GPIO Hat)

And this is it for the electricity installation in our barn.

Note: This cascaded setup is officially not supported by Victron, but it has been working for us without problems for months now. This might be different in your case.

Configuration of electric components

Addendum

./.

Corrigendum

./.

Electricity and our Saurer 2DM

This is sort of a never ending story for me – just as the installation of our workshop container on the truck bed by our trusty mechanic which has been “in the making” since October 2022.

It is clear that we want and need electricity in the container. Just how and how much is not clear yet. In the following, I will consider our rquirements and different apsects and constraints of the electrical installation to hopefully come to a conclusion. This is a rather dry article with a lot of numbers – so beware …

Here is what we know (or at least think we know):

  1. The truck has a 24V system
  2. Charging any “leisure” batteries via the truck engine on a regular basis does not seem to be a good idea, as the fuel consumption is already 33l/100km without the container (that makes an astonishing 8.56mpg in the UK)
  3. It is a EURO0 diesel so we will not be able to get into all the cities (regardless of its problematic weight, length, height and width anyway).
  4. Solar panels are still no real option (most of the time too way up in the North)
  5. Charging from an EVSE might not always be possible as most of these EVSEs are for cars and do not have space for trucks
  6. We want to be able to cook and wash in the vehicle
  7. We will have a 2kW diesel heater
  8. We will have a 900W single phase petrol generator
  9. We will be using Eve LF280K cells
  10. The inverter must at least provide 2'250VA or 1'800W (concurrently, but not neccessarily on a single phase)
  11. (optional) We would like to have 3-phase power in the container (as the cabling is already in place) – but also we know we would only use it very seldomly (such as for welding, then we need at least 11A per phase)
  12. We would like to be able to charge 60% of the batteries (from 20% to 80%) within 3h
  13. We will be using Victron MultiPlus-II (as we do not 2 separate AC inputs)

Here is a list of devices needing electricity:

  1. Refrigerator (able to run on 12V DC/24V DC or 230V AC)
  2. Microwave (1'000W)
  3. Water heater (immersion heater with 1'000W or 2'000W and/or kettle with 2'000W)
  4. Table grill (1'250W)
  5. Steam cooker (450W/900W)
  6. Bread baking machine (600W)
  7. Coffee machine (1'150W)
  8. Washing machine (750W)
  9. Water pressuriation system (850W)
  10. Computers peripherals (USB-C charging with 36W via AC or DC, or 60W AC)
  11. Lights (12V or 24V DC)
  12. Water pump (12V or 24V DC)
  13. Fan (12V or 24V DC)
  14. Diesel heater (12V DC)
  15. Starlink (60W AC, possibly 48V DC)
  16. Infrared heating panel (150W AC)
  17. Battery charger (12V/24V DC or 230V AC, depending on model)
  18. Other USB powered and/or chargeable devices (via 12V/24V DC or separate 230V AC charger)
  19. built-in 6t winch (powered by engine)
  20. (optional) electric shower (8'000W)

Sizing the electrical installation comes with a number of additional constraints:

  1. The crane in the workshop garage can lift up to 500kg
    this mean, all batteries, inverters, washine machine and water tanks must be less that weight
  2. No single battery can charge or discharge with more than 140A
  3. We can only charge from EVSEs with a Type 2 connector

A 12V system is very quickly out of the picture (and the largest and only MultiPlus-II with 12V is a 3’000VA system). Besides, the truck has 24V system anyway. So it is either 24V or 48V. Here is an overview of all current 24V and 48V MultiPlus-II models and their charge and discharge values:

MultiPlus-II 24V and 48V

Let’s first evaluate a 24V system:

Combination of 24V batteries and invertes
  1. 1* 8s battery
    • Capacity is likely to be too small
    • Single battery is not redundant
    • 1*3’000VA can draw too much discharge current
    • 1* 5’000VA can draw too much discharge current
  2. 2* 8s battery
    • 2* 3’000VA can draw too much discharge current
    • 1* 5’000VA possible
  3. 3* 8s battery
    • 1-phase charge requirement can only be met with EVSE 7kW 32A Type 2
    • 3* 3’000VA can draw too much discharge current
    • 2* 5’000VA can draw too much discharge current
  4. 4* 8s battery
    • 1-phase charge requirement can only be met with EVSE 7kW 32A Type 2
    • 4* 3’000VA can draw too much discharge current

So, in a 24V 1-phase system only the 5'000VA inverter would be possible with either 2 (14’336Wh) or 4 (28’673Wh) batteries.

For a 3-phase setup to support our Kemppi Kempact 253A we would need at least 4 batteries and 3* 5'000VA inverters.

And now let’s have a look at a 48V system where we have a couple of more inverter options:

Combination of 48V batteries and inverters
  1. 1* 16s battery
    • Single battery is not redundant
    • 2* 3’000VA inverters needed
    • 1* 5’000VA inverter possible
    • 1* 8’000VA can draw too much discharge current
    • 1* 10’000VA can draw too much discharge current
    • 1* 15’000VA can draw too much discharge current
  2. 2* 16s battery
    • 1-phase charge requirement can only be met with EVSE 7kW 32A Type 2
    • 3’000VA not as 3-phase setup feasible (otherwise 6 devices necessary)
    • 8’000VA only as 3-phase setup, but then too heavy
    • 1* 10’000VA possible
    • 1* 15’000VA can draw too much discharge current
  3. 3* 16s battery
    • 1-phase charge requirement cannot be met
    • charge requirement can only be met with 3-phase EVSE (16A or 32A) Type 2 (11kW+)
    • 3’000VA possible, but too heavy with combined battery weight
    • 5’000VA possible
    • 8’000VA only as 3-phase setup, but then too heavy
    • 10’000VA only as 3-phase setup, but then too heavy
    • 15’000VA possible
  4. 4* 16s battery
    • batteries too heavy
    • 1-phase charge requirement cannot be met
    • charge requirement can only be met with 3-phase EVSE (16A or 32A) Type 2 (11kW+)
    • 3’000VA too heavy with combined battery weight
    • 5’000VA too heavy with combined battery weight
    • 8’000VA only as 3-phase setup, but then too heavy
    • 10’000VA only as 3-phase setup, but then too heavy
    • 15’000VA only as 3-phase setup, but then too heavy

So, this leaves us with really 3+2 choices:

  1. 2* 8s (14’336Wh) batteries in a 1-phase system with a single 5’000VA inverter
    • Battery and inverters would weigh roughly 140kg
  2. 2* 8s (14’336Wh) batteries in a 3-phase system with three 5’000VA inverters
    • Battery and inverters would weigh roughly 250kg
    • Not possible for 3-phase welding
  3. 4* 8s (28’672Wh) batteries in a 3-phase system with three 5’000VA inverters
    • Battery and inverters would weigh roughly 310kg
  4. 1* 16s (14’336Wh) battery in a 1-phase system with a single 5’000VA inverter
    • Battery and inverter would weigh roughly 140kg
  5. 2* 16s (28’672Wh) batteries in a 3-phase system with three 5’000VA inverters
    • Battery and inverters would weigh roughly 310kg
    • 3h on a 1-phase 16A Type 2 would charge about 38% (a 60% charge takes 4.7h)

From there, we can narrow this down even further:

  1. 1-phase system: 24V, 2*8s
    • Price: batteries 2* 1’364GBP = 2’728CHF plus inverter 1* 1’359GBP total = 4'087GBP
      • Con: 24V MultiPlus-II are considerably more expensive (than 48V)
      • Con: only have the capacity
      • Con: cannot run electric shower
  2. 3-phase system: 48V, 2* 16s
    • Price: batteries 4* 1’364GBP = 5’456CHF plus inverter 3* 812GBP = 2’436GBP total = 8'802GBP
      • Con: charge requirement can only be met with 32A Type2 on 1-phase
      • Con: additional 48V|24V DC-DC converter required
      • Con: heavier, 300kg+
        Con: higher self-consumption in 3-phase configuration

So – drum roll – my conclusion: for roughly double the money in a 48V we would get double the capacity and triple the charge and output power and pretty much can do everything we want the system to be able to do.

The 3-phase system can be reconfigured to a parallel 1-phase system, so we would even be able to use an electric shower (though very unlikely – we have our mobile shower). We can either charge 1-phase or 3-phase and have a longer window of electric autarky. And for most of the time we would leave the system in a 1-phase single device InverterCharger configuration. And additionally, for charging the other 2 devices would bet set to ChargeOnly (but be configured independently configured from each other).

The exact setup I will have to layout some other time, but right out of my head I would think of the following components:

  1. External power in with CEE 16-5, CEE32-5, CEE32-1, CEE16-1 and Neutrik PowerCON True1 TOP (the more the better)
    connected to an ATS
  2. AC out from MultiPlus-II connected to ATS
  3. Orion-Tr 24V|48V DC-DC converter
    charging from alternator (though not the norm)
  4. Orion-Tr 48V|24V DC-DC converter
    as power supply: to support 24V loads in the container
    as charger: as an emergency charger for the truck batteries
  5. Lynx Power In, Distributor
  6. Venus OS with Raspberry PI for RS-486 and DVCC

So, in case our Saurer ever gets finished – at least I know how to do the electricity …

C# .Net on a Raspberry Pi 400 running Venus OS

Today, I tried to run a C# console application on a Venus OS – and it pretty much worked right away. But why would I want to do that?

The answer is simple: a couple of weeks ago I started to add some “drivers” to Venus OS to support additional features like using a MultiPlus-II as a charger for top balancing cells. With Venus OS, most of the examples I found were written in Python (except for some C++ extensions). And it is no secret that I am not too fond of that. So, why not using my favourite programming language on Venus OS as well?

My first thought was, I would have to install the .Net framework on Venus OS. But, with the advent of self-contained (and thus framework-independent) executables this is not needed.

First, I installed .NET on a Raspberry Pi 400 with Raspbian (just for the fun of it). I basically followed Deploy .NET apps on ARM single-board computers:

curl -sSL https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --channel STS

echo 'export DOTNET_ROOT=$HOME/.dotnet' >> ~/.bashrc
echo 'export PATH=$PATH:$HOME/.dotnet' >> ~/.bashrc
source ~/.bashrc

dotnet --version

… and there it is!

And then it was time for another infamous Hello, world!:

dotnet new console -o HelloWorld
cd HelloWorld

And now for the compilation. 

dotnet publish --sc -r linux-arm -c Release -p:PublishTrimmed=true

linux-arm was needed, as Venus OS is a 32-bit operating system (regardless of the 64bit architecture of the Pi 400). I chose PublishTrimmed to save some space. And of cource, --sc for self-contained.

I then gzipped the publish folder and copied it to the Venus OS (via WinSCP). After uncompressing the files (with permissions left intact), I ran the program and got this error:

Process terminated. Couldn't find a valid ICU package installed on the system. Please install libicu (or icu-libs) using your package manager and try again. Alternatively you can set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support. Please see https://aka.ms/dotnet-missing-libicu for more information.

Enabling invariant mode seemed to be the easier choice. After all, my future drivers would hopefully not need globalisation support anyway. So, I recompiled after adjusting the .csproj file:

<PropertyGroup>
    <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>

… and it worked:

root@raspberrypi4:~# publish/HelloWorld
Hello, World!

I executed this on a Raspberry Pi 400 running Venus OS v3.00 and .Net 7.

From there, I wanted to connect to D-Bus which proved to be more difficult. Following the Connecting .NET Core to D-Bus I had to find out that Tmds.DBus.Tool was not compatible with .Net 7. I will have to look into that separately.

Note about IL trimming: the size difference is really noticable. In my example the untrimmed compilation was around 65MB and the trimmed version around 13MB. However, it seemed to me that the trimmed version took slightly longer to load and execute. So, I am not sure if I will keep this switch on.

So, what would be the perceived advantages of using .Net on Venus OS for me?

  1. Known developing environment
  2. Better type safety
  3. Reusability of a lot of basic code
  4. Easier testing and mocking

But this is only my personal opinion and preference. Yours might differ.

Initial setup of a Venus OS on a Raspberry Pi without a wired network connection

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

As pointed out in Cannot change headless – Read only filesystem on Rasp4 for Venus OS large two options exist:

  1. Make the file system read/write via /opt/victronenergy/swupdate-scripts/remount-rw.sh
  2. Enable superuser access (unfortunately, this requires GUI access – chicken-egg-problem here)

But instead of making the filesystem read-write until the next firmware update, I would rather only temporarily remount via mount -o remount,rw /.

And after that, renaming/removing the headless file succeeds.

Following the next reboot, the file system is then mounted read-only again and the GUI appears on the local HDMI port.

Now we can configure WLAN settings and everything else (such as superuser access) without the need for a wired network.

And in case you are in the need of a very small keyboard / display combination, you can use

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 Connect
Configure Network settings
Connecting to a WLAN

Enabling WiFi on a Raspberry Pi 400 with Venus OS

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.

mount -o remount,rw /
cd /lib/firmware/cypress
cp /run/media/sda1/cypress/cyfmac4356* .
chmod 644 cyfmac4356*
cd /lib/firmware/brcm
cp /run/media/sda1/brcm/brcmfmac4356-pcie.gpd-win-pocket.txt .
chmod 644 brcmfmac4356-pcie.gpd-win-pocket.txt
ln ../cypress/cyfmac4356-pcie.bin brcmfmac4356-pcie.bin
chmod 777 brcmfmac4356-pcie.bin
ln ../cypress/cyfmac4356-pcie.clm_blob brcmfmac4356-pcie.clm_blob
chmod 777 brcmfmac4356-pcie.clm_blob
ln ../cypress/cyfmac4356-sdio.bin brcmfmac4356-sdio.bin
chmod 777 brcmfmac4356-sdio.bin
ln ../cypress/cyfmac4356-sdio.clm_blob brcmfmac4356-sdio.clm_blob
chmod 777 brcmfmac4356-sdio.clm_blob
ln brcmfmac4356-sdio.AP6356S.txt brcmfmac4356-sdio.khadas,vim2.txt
chmod 777 brcmfmac4356-sdio.khadas,vim2.txt
ln brcmfmac4356-sdio.AP6356S.txt brcmfmac4356-sdio.vamrs,rock960.txt
chmod 777 brcmfmac4356-sdio.vamrs,rock960.txt
cp /run/media/sda1/brcm/brcmfmac43456-sdio.bin .
chmod 644 brcmfmac43456-sdio.bin
cp /run/media/sda1/brcm/brcmfmac43456-sdio.clm_blob .
chmod 644 brcmfmac43456-sdio.clm_blob
cp /run/media/sda1/brcm/brcmfmac43456-sdio.txt .
chmod 644 brcmfmac43456-sdio.txt
ln brcmfmac43456-sdio.bin brcmfmac43456-sdio.raspberrypi,400.bin
chmod 777 brcmfmac43456-sdio.raspberrypi,400.bin
ln brcmfmac43456-sdio.clm_blob brcmfmac43456-sdio.raspberrypi,400.clm_blob
chmod 777 brcmfmac43456-sdio.raspberrypi,400.clm_blob
ln brcmfmac43456-sdio.txt brcmfmac43456-sdio.raspberrypi,400.txt
chmod 777 brcmfmac43456-sdio.raspberrypi,400.txt
mount -o remount,ro /
view raw RaspberryPi400WlanSupportOnVenusOS.sh hosted with ❤ by GitHub
Commands necessary to enable WLAN support on Raspberry Pi 400 for Venus OS v3.00

Two brcm-links are giving errors, but this can be ignored. The links on the Raspbian are not working either.

After copying the files both directories looked like this:

Venus OS v3.00 firmware brcm and cypress folder after adding the driver files

After a reboot I could browse and connect to my SSID via Settings, Wi-Fi:

Wi-Fi networks visible after a reboot
Established connection to a Wi-Fi network

And from the serial console, ifconfig also showed our new interface:

Venus OS recognising the Raspberry Pi 400 WiFi interface

Now, the Raspberry Pi 400 can be used like any other Pi with Venus OS.

Thanks again to bipedalprimate for pointing me in the right direction!

Using a Raspberry PI 2 Model B 1GB as a Victron GX device running Venus OS v3.00

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:

Victron themselves, apparently, have no plans for supporting this feature.

Luckily, pagedo did all the hard work and gave a step-by-step description on how to enable a Wifi access point. And that worked on the Pi 2 as well.

Essentially, we have to enable Wifi, activate tethering and modify the config file:

$> connmanctl enable wifi
$> connmanctl tether wifi on <SsidName> <SsidPassword>
$> connmanctl technologies
$> nano /etc/connman/main.conf
  TetheringTechnologies = wifi
  PersistentTetheringMode = true
  AddressConflictDetection = true

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

Connecting a BYD Battery-Box Premium LVS 8.0 to a Victron MultiPlus-II 48/3000/35-32 and a Venus OS Raspberry Pi 4

The other day, I connected my BYD Battery-Box Premium LVS 8.0 to a Victron MultiPlus-II 48/3000/35-32. Here are the steps I took to do it and some errors I ran into.

The Battery-Box needs to communicate via CAN with the inverter. And as Victron inverters do not come with a CAN port by default (unless you go for a MultiPlus-II GX or EasySolar-II GX) we need a GX device. Originally, I wanted to use my Victron Cerbo GX for that, but since we moved into the caravan the device is gone missing. Luckily last year, I supplied myself with a couple of Raspberry Pis (at least model 3 and 4 are supported) that could run a Venus OS and act as a GX device. And as I was not the first one doing that, I thought it would be just too easy – well, it was easy after I did everything right.

Normally, Victron requests to use a VE.Can to CAN-bus BMS Type A cable to connect to a BYD battery. This is actually an ordinary CAT 5e network cable with RJ45 connectors where only the relevant CAN pins (and GND) are connected.

VE.Can to CAN-bus BMS Type A cablec pin layout

Note: on the original Victron Type A cable, all three pins seem to be connected:

VE.Can to CAN-bus BMS Type A cable

In order to screw the wires to the CAN hat terminal, I used uninsulated ferrules. Otherwise the Cat 5e wires would have been too soft and light for the terminal.

Installing Venus OS on the Raspberry PI 4

For the Raspberry PI 4, I followed the documentation and installed the standard (and not the large) image. At that time, v2.93 was the newest version (see here for directory of all versions). I uncompressed it and used Win32DiskImager to write the OS to a MicroSD card (all done on a Microsoft Surface Go2 running Windows 11).

I then enabled remote access via SSH by becoming superuser and setting a root password.

Note1: at first, I did the install with a Raspberry Pi 3 Model B V1.2 which also worked fine. However, the CAN device on the Victron UI then did not show any packets but worked without problem.

Note2: The Raspberry Pi 4 is a model B Rev. 1.5 (I mention this, as I saw comments that indicated that there might be a difference between different revision from 1.2 onwards).

Note3: I activated the “Mobile” tile to be able to change the charge current via the overview screen.

The CAN driver then had to be installed separately. As I did not have direct internet access from the Pi, I used the offline install method with a USB memory stick.

Installing SetupHelper

As written in the documentation, I copied the compressed installation files as venus-data.tar.gz to the root of the USB drive and restarted the Pi.
To verify the automatic installation was successful check if there is a new menu item Package manager at the end of the Settings list. If not visible check if you can find SetupHelper in /data. You can always manually copy it from the SDCard (use mount to see where the card is mounted) and then run setup yourself. I did a reboot after every package.

New menu item in Settings after installation of SetupHelper

Installing VECanSetup

Same procedure here. Copying the compressed installation files to the SDCard as /venus-data.tar.gz. Then run the package installation manually if for whatever reason the automatic install does not succeed. See below what the package manager should look like after the installation of both packages.

List of active packages in Package manager

Installing the driver

Configuring the driver had to be done from the terminal. There was a minor issue for me which I did not get right the first time. When asked to install an interface via the i option I actually had to type in a hat. I named the device hat0 and after the reboot it showed up as hat0 (can8) can8 spi0.0. In my case it was the “Waveshare 1-channel CANbus Hat 12 MHz crystal” (check the imprint on the silver part on the hat to see the crystal speed).

Configuring CAN bus

There is really not much to configure. The only option under “Services” is to set the communication speed which is 500kB/s for BYD. If the CAN adapter does not show up make sure the correct type has been selected in VeCanSetup. For me it just worked out of the box.

CAN hat showing up in Services
Setting the CAN speed for BYD Battery-Box BMU
Configured CAN bus

Before the BMS is connected the CAN should show up as ERROR-PASSIVE. As soon as the communcîcation worked it changed to ERROR-ACTIVE.

CAN bus ERROR-ACTIVE with actual traffic

Note: When I tried with the v2.93 on the Raspberry Pi 3 the RX/TX counters were always empty (but nevertheless worked). Via ifconfig the packets were correctly shown. But with the Pi 4 traffic was shown on the UI right from the start.

CAN bus traffic via ifconfig

I did not connect the CAN cable at that point but configured the Battery-Box and the inverter first.

Commissioning the inverter

I used a USB MK3 adapter with an RJ45 Cat 5e cable connected to the VE.Bus of the inverter to configure the MultiPlus.

I used VEConfigure 3 and VictronConnect (to be able to configure via VictronConnect I had to use the zzz password to get out of the read-only mode).

First, I updated the firmware of the MultiPlus via VictronConnect and then continued with VeConfig.

Basically, I set the inverter to off-grid and did not enter a country code. For the battery type I selected “Lithium Iron Phosphate” and accepted the default settings. I set the “AC current limit” to a maximum of 20A (the maximum my generator could handle) and activated the option to have it overruled by “Remote” (which can also be done via the GX Remote Console or VictronConnect).

Setting AC current limit via GX remote console

I also activated DVCC to later have the BMS tell the inverter when to charge and how to discharge. This was pretty much it. So I connected the MultiPlus via the VE.Bus and the MK3 cable to the Raspberry where it showed up instantly.

Inverter shows up after connecting VE.Bus to the Raspberry via MK3

Commissioning the Battery-Box

After assembling the battery which conisted of only stacking both battery modules on top of each other followed by the PDU on the very top I connected the BMU via the grey RJ45 to the PDU. After turning on the top most battery the BMU started as well and I was able to connecto to the WiFi of the BMU from the BeConnect app (Android or Windows both worked for me, the latter actually showed more information).

Via the app I pre-downloaded a current firmware and after switching to the BYD access point I applied the firmware (actually two different firmwares). After some waiting the new firmware had been applied and I could configure the basic settings: inverter manufacturer, number of battery modules.

At this stage I connected the 35mm2 cables from the battery to the inverter. I bought the cable preconfigured with the battery. And I used a Littelfuse JLLN-125X (class T) as a fuse between both devices.

Connecting the battery to the Venus OS

And then I connected the BMU to the GX. After some seconds, the inverter clicked and started charging. Essentially, DVCC turns on automatically (even if turned off before) as soon as the CAN communication is established.

In the GX overview the battery appeared and gave some additional information (see next section for details). All parameters between battery and inverter were exchanged automatically.

Things I noted

  1. The battery turns itself off after a while when no communication via CAN is possible. This behaviour is described somewhere in the BYD manuals.
  2. Charging the battery does not work when no CAN connection can be established. The inverter stays in “Absorption” mode with a current of 0A.
  3. A more detailed description of the pin layout can be found on the BYD manuals. See images below.
  4. The GND pin is not required for communication between the BMU and the VE.Can GX. Only BLUE for CAN-H and BLUE-WHITE for CAN-L are going into the CAN hat.
  5. In addition to the official web site bydbatterybox.com the web site eft-systems.de provides additional information and downloadable documentation.
  6. When charging the Battery-Box for the first time, I eventually reached a 100% SOC. Until that point the charge current stayed nearly constant at around 30A (Bulk). It decreased to around 1.2A and the inverter turned to “Absorption” but never stopped charging. At some point one of the cells reached a voltage of over 3.7V which resulted in a warning on the GX. Nevertheless, charging continued. I manually switched off the charger after the second time I received a warning due to high cell voltage. I would have expected to have the inverter automatically stop charging at a 100% SOC.
    Maybe the BMS only measures the charge voltage limit (CVL) which is defined as 58.4V and not the individual cells?
  7. The cells in a battery were not really well balanced (delta >= 100mV). I would have expected a better balancing. Actually, I do not know if the BMS has a balancer at all. I could not find anything in the documentation.
  8. Each LVS 4.0 has a capacity of 78Ah @ 51.2V = 3993.6Wh. The GX shows this information in the “Details” item within the battery. I could not find this information in the manual.
  9. The BYD manuals state, that the lifetime of the battery can only be achieved at 0.2C, which limits a single LVS 4.0 to 798.72W (or 1597.44W for a LVS 8.0) – this is a ridiculous small amount.
  10. Charge current was initially restricted to 38.4A by the battery, only after a day or so, the charge (CCL) and discharge current (DCL) went up to 128A. In my case the inverter only support 35A max, so no issue with that.
  11. Startup sequence
    Start top-most battery first by pressing the power button for a couple of seconds; then start the BMU if not automatically started; next start the inverter; then start the GX (in my case currently on the AC side).
  12. Shutdown sequence
    Turn off the inverter; turn off the BMU; turn off the individual batteries (keep buttons pressed for a couple of seconds); GX turns off automatically.
  13. Adding a CAN hat in VeCanSetup needs to be entered literally as a hat.
  14. Though I set the AC charge current to 20A the inverter only drew 16A at most.
  15. The WiFi of the BMU cannot be changed, nor the password.
BYD RS485 CAN pin layout, taken from the BYD BMU maual
BYD to Victron CAN pin layout, taken from the BYD BMU manual
BYD Battery-Box voltage and charge limits
Specification of BYD LVS 8.0, taken from the BYD manuals

Future improvements

  • I want to connect the Raspberry to the DC side with a 48V/12V step-down converter and a 12V to USB-C adapter. Inbetween I want to add a power bank, so the GX can be configured even if all power sources are down.
  • Replace the CAN hat with a USB CAN adapter
  • Strengthen the connection of the CAN wire to the CAN adapter
  • Try a Raspberry Pi Zero 2 W (when they become available again).

Conclusion

All in all, the installation was straightforward. A couple of uncertainties are probably normal when doing this the first time. I would have expected more documentation (articles, videos) for this to be around. But I could not find anything for a BYD, Victron, VenusOS via Raspberry setup. Maybe others are only using a Cerbo GX?

The batteries are well built (all IP55) but extremely bulky and pricey. With around 400 CHF per KW this is more than 300% of regular LiFePO4 cells. But nevermind, lead and delivery times are in the magnitude of months.

I would have liked the BMU to be integratable into one of the PDU boxes. Now it is just hanging around separately.

Would I buy another Battery-Box? Probably not – too pricey. But good for starters. Plug and play when used with Victron and a Cerbo GX.