README April-2024
What is Victron Venus for Rasperry Pi. Read: Raspberry Pi running Victron’s Venus firmware
The issue (for me) is that this software is intended to be installed as a wic image on a raspberry pi bootable SDcard and that suggest that the venus system will own and manage the linux platform from bottom up.
In my case I already have a rapserry pi running in my yacht running serveral of my other applications avaiable here on github. I don't want to have the venus applcation running the entire platform but rather as a background service and have the Qt-gui opened up on demand from my own application sdlSpeedometer (or from a shell commnd).
This implenetatin achive this with simple means comprising just of a bunch of scripts and a mounted (or copied) standard venus (wic) SDcard to the host.
Typically a systemd service script will start venus as a background service using either a docker, chroot or systemd-nspawn to instantiate the system.
To use systemd-nspawn would be a preferred method to start the system since it preovides a pretty good sanbox isolation from the host system and provides a good virtualized network domain.
Unfortunately systemd-nspawn (macvlan interface) does not today allow for wireless network address familys so for outgoing bluethooth traffic (bluetoothd) we are limited to only ehternet connectivity and that degrades the bluetooth feature of the system.
It is however, still possible to connect to Venus with bluetooth from a mobile app and then further to VRM.
In this situation the outgoing traffic to sensors won't work and consequentially the I/O menu in setting won't show up.
For wifi that is not a problem i my case since the host provides AP over wifi and that would in any case be a conflict with venus as it is intended to be a wifi client.
If the wifi interfaces are not in AP mode or free to use, then they can show up in the venus system as well.
As explained above, I want to have two wifi APs on the host side untouched by venus.
In summary the chroot:ed system and docker gives 100% connectivity to the outher world such as VRM and signalK etc.
The systemd-nspawn managed system gives the same but limited bluetooth.
An interesting consequence of ths implementation is that venus now is running on a bookworm (minimal) 32-bit OS on a raperry pi 5 with a 6.1 64bit Linux kernel as opposed to the standard boot image with kernel 5.10
To start with docker, an initial container must be created:
Download a ready-to-go image from:
For regular use the script venus-boot.sh should be used in order to have the complete run-time envirommnent right.
Eventually you have to deal with port conflicts between the host and the venus guest system (possibly for port 80 and 22), though not for the systemd-nspawn booted system.
Since the bookworm OS default network interface name (when set to predictable in raspi-config) is set to end0, then a renaming is necessary either on the host or by passing an environment variable to the venus subsystem.
You may add this rule into /etc/udev/rules.d/99-(some file)
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="e4:5f:01:9a:c1:7a", NAME="eth0"
Or pass the enviromnet variabe VRM_IFACE=ethX to the venus system. This is a valid argument for the venus-boot.sh script.
Bookworm 32-bit has still a 64 bit kernel (on rpi4-5) and it is running 32 bit binaries in user space. This implementation is tested on such a system and 64 bit bookworm is not tested.
This explains why we are loading a linux/arm64/v8 docker to the system.
Check the file /opt/victronenergy/dbus-i2c/dbus-i2c.py in the Venus domain, a line reading "bus=dbus.SystemBus() if (platform.machine() == 'xxx' ...". The xxx should be alterred to what you get from the host command "uname -m" i.e. aarch64 for the 64-bit system.