mvader (Victron Energy) avatar image

Venus OS v2.80~10 available for testing

UPDATE 2021-08-04: v2.80~11 is now available for testing, just one small change to fix a possible issue when running v2.80~11 on recently (2021 wk 10 or later) produced MP-II GXes or ES-II GXes.

Good afternoon!

Luckily not everyone is on summer holidays, or not anymore, and there is a new major version ready to be field tested.

In case you don't know what all this is about: this message is part of the Venus OS Beta test program. Read that link for more information.

What to test?

The new DC meter features of the BMV-712 and SmartShunt. Note though that more is coming there, such as proper visualisation on the Overviews. What is available is just the basics.

And then furthermore basically everything needs testing: similarly as the previous major release, v2.70, also this version contains major upgrades in the foundations. The main one being that the Python version was changed from 2.7 to 3. Also the Open Embedded release was upgraded from Zeus to Dunfell, and lastly we changed to a read-only rootfs. All combined this means that (a) lots of tools and packages used will have changed to a newer version, and (b) lots of Victron code has been changed to be compatible with Python 3.

How to post an issue?

Preferably all issues are organised as answers to this question. One answer per issue. So first check the existing threads. If you have the same as someone else already reported, welcome to add a comment saying "me too". And preferably some more details. And in case its not listed yet, add a new Answer. Note that Answers and Comments are two different things here on community.

Lastly, if possible please revert to v2.72, to double check if the issue you're seeing was present there as well. Regressions require a different treatment than other issues and bugs, and one of the first things that needs doing in triaging a report is distinguishing between the two.

The plan with v2.80

Development and testing will continue for quite a while; I expect at least until somewhere in September; possible also into October this year.

Change log v2.80~10

(compared to v2.72, the todays official version)

User interface (on screen & remote console)

  • Add eject button to the offline firmware update menu.
  • Fix issue that caused the overview to change when switching off the Multi in a system configured for ESS
  • Fix an issue where the grid meter reading disappeared from the gui when the Multi is off
  • Fix I/O settings visibility.

DVCC & managed batteries

  • Force DVCC settings for Pylontech batteries as per documentation (DVCC on, SVS and STS both off). This is now the same as already in place for various other battery makes.
  • Add full support for the Inverter RS, including CVL, CCL, SVS, STS and SCS.
  • Switch off inverters when a managed battery says DCL=0, just as it works for inverter/chargers already.
  • Only use the selected battery monitor; affects systems that have a managed battery and a BMV (or similar) Victron battery monitor installed.


  • Support the new DC Monitor feature, recently released as a firmware update for the BMV-712s (v4.07) and SmartShunts (v4.07). The purpose is to be able to use those dc meters not as a battery monitor but as a dc meter. For example to measure the output of an alternator, or a wind generator. Or, measure the power draw of a certain load or group of loads. First of all to visualise it, and later it can perhaps be used in DVCC as well. Note that this release is just the first step, more coming later such as proper visualisation in the overview and VRM.
  • Support exfat filesystem, for large removable media (sdcards, usb sticks). Note that this is not for the raspberrypis, since (only they) still ship with a version of Linux that does not support exfat.


  • Fix Bluetooth pincodes starting with a 0; this was broken since the first release of BLE functionality in Venus OS.
  • Implement keep-alive functionality: improves robustness with certain phones by avoiding Venus OS thinking its still connected and then remaining connected while its not.
  • Fix GX device not being visible on other phones while already connected to one. Now it is visible in the 2nd phone, but then with an explanation that to connect, the other phone needs to actually disconnect first. This is now on par with how other Victron products work with Bluetooth.

Developer / under the hood

  • Change the rootfs to be default read-only. Careful, this is quite the change in case you're modifying your rootfs. The reason behind this is quality and robustness. Every boot is now the same, instead of an initial boot possibly being different from the second or the third. And less writes to the storage, which reduces the wear, and more advantages. The downside is obviously that its a bit more hassle in case you want to modify the software. To learn how, read here this commit.
    • /opt/victronenergy/swupdate-scripts/ will make it writable again (until the next swu update)
    • additional services should now be stored in /opt/victronenergy/service instead of /service or else they won't survive a reboot
    • closes
  • Change the used Open Embedded release from Zeus to Dunfell. More details about OE releases are here. For a long time, Venus OS was based on Rocko. Recently we changed it to Zeus, which was an intermediary step to get to Dunfell. Dunfell is relatively recent LTS (long term support) version; so happy to be at that version, and expecting to be able to leave it at this for quite some time to come.
  • Change the used Python version from v2.7 to v3.. This was something we needed to do anyway, and sort of a requirement that comes with switching over to Dunfell. For those that wrote their own code this does mean work. See also this post on community.

Looking forward to your reactions, and all the best, Matthijs

Ps. in case you're wondering whats up with Venus OS large, then the answer is don't worry, its not an abandoned project at all. I'm a little bit behind with that, but plan to build a new version real soon.

Venus OS
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Not sure if it's related but victron connect really struggles to connect to mppts via vrm.

The config cog at the top right takes forever to appear, if it does.

to add, when eventually you can access the settings, changes don't take effect if you make any. This used to work, will have to rollback and see if it persists.
Hi @nickdb , noted - thank you. We'll look into this.

Not sure if it's related but victron connect really struggles to connect to mppts via vrm. The config cog at the top right takes forever to appear, if it does.

I can confirm this issue. I was not sure if it is v2.80~11 or the new VictronConnect 5.46 for PC (it just updated the first time I ran it after also updating Cerbo GX to v.2.80~11).

I went back to v2.60. The settings load much quicker - in a few seconds (using the same version of VictronConnect for PC).

Hi both, its an issue indeed; found & fixed in the code. A new version / build will be available soon.
7 Answers
bathnm avatar image
bathnm answered ·

@mvader (Victron Energy) , Great work you and your team are doing and look forward to further changes. Just noticed having upgraded my Smart Shunts, which are DC Meters are no longer available through the NMEA2000 out feature.



Reverting back to 2.72, they are in the list. If you need to access my system or require further debug data, please let me know.


1628002299115.png (125.0 KiB)
1628002332134.png (116.5 KiB)
1628002651685.png (114.8 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi @Bathnm , ah indeed. For this, NMEA2000-out hasn't been given a single thought yet. Neither has VRM, ModbusTCP or anything else.

bathnm avatar image bathnm mvader (Victron Energy) ♦♦ ·

As I have a mixed system of 12v and 24v, and the smart shunts are on the 12v side I will not benefit from the modification. Hope one day the system can report and depict a dual voltage topology. Until then will continue to just monitor the 12v side through the device list ;)

I'm not 100% sure if I can still follow you. But can say this: the assumption/limitation to have one main battery, and possibly a few secondary less important ones, is really embedded deep into the Venus OS.

DVCC is for one battery only, all calculations and visualisation on the overview is like that and so forth and so forth.

If you have multiple real battery banks, with their own inverters and so forth, you'll need two GX Devices.

For some "extra" batteries, like starter batteries, you can already see them nicely on the Marine MFD HTML5 App as well as on the VRM Dashboard; and in the GX Touch / Remote Console device list ofcourse.

bathnm avatar image bathnm mvader (Victron Energy) ♦♦ ·
Hi, Agree that there has to be a master that the system works from, and that should be linked to DVCC and all the other capabilities of managing the power system.

Would be good in the main overview could show the status of additional batteries, a bit like we have on the HTML5 app and VRM dashboard. At present you have to swap between the main overview screen and the device list to see what is happening on the additional batteries.
Kevin Windrem avatar image
Kevin Windrem answered ·

Update 2: voltage, current and frequency on AC input as well as the gauge on AC output weren't displayed. Also, the code for PV Inverters was throwing errors. These have now been fixed in v2.1 (current is now v2.1)

I forgot to mention that versions have now been added to all packages. These show up in Settings/Display/GuiMods/PackageVersions. Thanks dsfas9 for pushing me to add versions.

UPDATE: all packages have been updated. BEFORE updating to v2.80, I recommend turning on package automatic updates (NOT Venus OS updates!!!) and leaving the system for about an hour so that all packages have a chance to download and update. Or update them manually.

Once they are updated, a Venus OS update to v2.80~10, etc should be fine.

I have made changes to GuiMods to support 120/240 split-phase MultiPlus II model but have no way to test it. If someone that has that system could check the AC Output tile for expected behavior with and without the grid present, I'd appreciate any feedback.

The rest of this message is a warning to anyone that has not updated any of my packages.

Note to anyone using my GuiMods or other packages:


My scripts expect the ability to modify the rootfs and since it can't do that, the reinstall process will fail. You'll be left in a state where the system reboots constantly.

You will need to run /opt/victronenergy/swupdate-scripts/, then you should be able to reinstall all packages.

You can fix the constant reboot on a Raspberry PI by putting the SD card in another system capable of reading EXT4 file systems and removing /data/rcS.local. But on other devices, you may be stuck !!!!!!!!! I think the only option is to use the reset to factory settings mechanism.

Sorry about this. I didn't see this one coming.

I need to create a new file set for GuiMods because several files I change have been updated. Stay tuned.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

SetupHelper has been modified to enable rootfs write access.

You need to update it BEFORE updating to v2.80. This should make all packages run and automatically reinstall without the dreaded constant reboot.

GenneratorConnector and RpiDisplaySetup have been updated to support v2.80. RpiGipoSetup and VeCanSetup needed no changes except writable rootfs.

Still working on GuiMods.

Is there a way to display the version number (maybe under the Settings > GuiMods) of the SetupHelper and GuiMods?

I have not been versioning my packages. In retrospect, this would have been a good idea.

I do have a timestamp used for automatic updates and I should be able to display in the menus.

Oh oh, my apologies for this Kevin; it would have been much better if we had given a heads-up to you (and the rest of the Mods community) for this.

For anyone needing to do a factory reset, see instructions here:


I believe the "stuck in reboot" is limited to the RPI packages that require a reboot. Some have updated to v2.80 with just GuiMods installed and didn't get stuck in constant reboots. GuiMods will not run on v2.80 yet but it makes it through the automatic reinstall and uninstalls itself cleanly.
Kevin, how can we tell if we are OK to update Cerbo to 2.8? Auto update is on, but I was expecting to see version number somewhere per your notes. Am I looking in the wrong place?

Version numbers should show up in Settings/Display/GuiMods/PackageVersions once the packages are updated.

I space connections to GitHub out one every 10 minutes to limit needed bandwidth. Depending on how many packages you have, it could take up to an hour to check them all. With just GuiMods and SetupHelper, it should be done in about 20 minutes.

The version numbers are in the file "version" in each package directory. You can check to see if it's there. If not, you don't have the latest package. GuiMods should be at version v2.1. Others are v2.0.

Each package adds it's version number to a dbus setting: com.victronenergy.settings /Settings/GuiMods/PackageVersion/<package name>. GuiMods displays those numbers. You can look at the version numbers with dbus-spy.

If GuiMods updated before SetupHelper, it might not have added it's version to dbus. But you should see the version for SetupHelper. If not, try restarting the GUI: killall gui (or rebooting). If that fails, try running /data/GuiMods/setup again.

As a final thing, make sure you manually run /data/SetupHelper/setup and choose reinstall. You may have uninstalled it per my original instructions for v2.80. You would also need to reinstall all packages manually.

Strange that it wasn't updated automatically.


capture.jpg (85.7 KiB)

log just in case


capture1.jpg (160.6 KiB)

setuphelper also gets terminated if you don't press any values within a few seconds, still running 2.72 on cerbocapture2.jpg

capture2.jpg (74.9 KiB)

Look at /data/reinstallScriptsList

It should have one line for each package you've installed. When things get messed up, I've seen lines ending in -current or -backup1, etc. Those shouldn't be there. Remove them.

Also check /service. It should not have any folders ending in one of my packages-current or -backkup1, etc. Remove those folders

Even if those to issues are OK, reboot.

If that doesn't work, lets take this off-line. We're adding posts to the beta software announcement thread and this is off topic.

Email me at

I reinstalled SetupHelper and that fixed the issue, now both are on v2.1. Thanks for all your work!
Mike Dorsett avatar image
Mike Dorsett answered ·

Hi, Having woke early, I thought to spend some time on the update:-

Loading on top of 2.72, with D-bus serial battery + extensions installed.

Base: Raspberry Pi B+

1) Wifi does not connect - it appears to be up, but the Wifi symbol disappears after accepting the password. Running "enable wifi" from connmanctl (which used to fix this issue) does not fix the problem.

2) command for python3 is python, not python3 (trivial)

3) pip3 still not in opkg list. so can't install modules. (spidev,gpio)

4) pydocs is not installed (and not in list), so can't check which python modules are installed

5) No package group "build essentials" in opkg list, so I can't install python modules using setup. ( no gcc compiler etc).

In other words, this upgrade so far has negated all the work on d-bus serial battery / SPI.

Is there no way to preserve python extensions over an upgrade? without this, it will prevent any automatic upgrade, as manual intervention will be required to restore BMS functionality after an upgrade. I do appreciate this is still early days for this version, and the work you are doing. Looks like I'll have to go back to 2.72 whilst working on integration of sqlite into the package (converting from mysql). :(.


2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Note: python-setuptools was already installed, but does not appear to include gcc, so running files fails.

I am lost here, "Loading on top of 2.72, with D-bus serial battery + extensions installed."

You cannot load 2.80 on top of 2.72. Venus uses image updates, the complete rootfs is replaced. And in general you want to have the same opkg feed.

/opt/victronenergy/swupdate-scripts/ candidate
opkg update
opkg install python3-spidev python3-pip packagegroup-core-buildessential

Sorry Jeroen, I meant that the original system was 2.72. Of course the new os loads in the different partition. I Was not aware that the opkg feed needed to be manually switched after you change the update feed to candidate...

All the updates worked, including finding python doc. Thanks for including spidev in the pokg list, please can we have gpiozero and its dependency RPi.GPIO?

Installing GPIOzero using setup worked,

however RPi.GPIO failed:

arm-ve-linux-gnueabi-gcc -mfpu=neon-vfpv4 -mfloat-abi=hard -mcpu=cortex-a7 -Wno-unused-result -Wsign-compare -DNDEBUG -g -O3 -Wall -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/python3/3.8.10-r0=/usr/src/debug/python3/3.8.10-r0 -fdebug-prefix-map=/python3/3.8.10-r0=/usr/src/debug/python3/3.8.10-r0 -fdebug-prefix-map== -fdebug-prefix-map== -O2 -pipe -g -feliminate-unused-debug-types -fmacro-prefix-map=/python3/3.8.10-r0=/usr/src/debug/python3/3.8.10-r0 -fdebug-prefix-map=/python3/3.8.10-r0=/usr/src/debug/python3/3.8.10-r0 -fdebug-prefix-map== -fdebug-prefix-map== -fPIC -I/usr/include/python3.8 -c source/py_gpio.c -o build/temp.linux-armv7l-3.8/source/py_gpio.o
source/py_gpio.c:23:10: fatal error: Python.h: No such file or directory
23 | #include "Python.h"
| ^~~~~~~~~~
compilation terminated.

1) :) The wifi worked this morning, so not sure that this is repeatable. However for some reason can only connect with sudo ssh, not ssh?

Mike, the serial battery driver will already be preserved over a Venus OS upgrade.

The only thing that might be an impact is the change to use /opt/victronenergy/service instead of /service. But the driver also does not use that directly. It use the serial-starter service which handles that. So I expect it will be fine.

I'll give it a test when I get some time.

one of the update problems is that extension modules added to python via pip or opkg are missing after the upgrade, and have to be re-installed.
Jaco Reinecke avatar image
Jaco Reinecke answered ·


Tried to update my Venus, after I updated all my equipment first.

No luck.

Here I started:

1628238829954.pngIt starts:


Then it goes back to, Press to update ...

1628238829954.png (25.3 KiB)
2nd.jpg (38.0 KiB)
1628239831140.png (24.7 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi Jaco, which version is currently installed on that unit?
and ps. what is its name on VRM and is it ok for us to login and have a look?
Jaco Reinecke avatar image Jaco Reinecke mvader (Victron Energy) ♦♦ ·

Hi Matthijs,

More than Welcome to login and look. Site is: 42 Bsb VenusGX

It was the last release before this update if memory serves, of Release Candidate.
Moved back the official release v2.72 in the interim.

If you want, I can go back and try again to install Release Candidate ... ?

Hi @Jaco Reinecke, it could very well be that you first need to install v2.72, and only thereafter can update to v2.80 or later. Welcome to try and install v2.80~ candidate again.
Jaco Reinecke avatar image Jaco Reinecke mvader (Victron Energy) ♦♦ ·
I Will do so ... thank you.
Jaco Reinecke avatar image Jaco Reinecke mvader (Victron Energy) ♦♦ ·
Hi @mvader (Victron Energy)

Tried updating again from 2.72 to Release Candidate 2.80-11.

It checks for the release, says it is installing, then goes back to Press to install.

Just keep me posted if anything is done, that I can put my Cronjob back.



Hi Jaco, I logged in and checked, there is a (more detailed) error in the logs right at the end of the download.

A colleague will look into it.

Strangely, I tested installing the exact same image on another Venus GX, and that worked fine.

Well, regardless, I'll confirm back once I know more.

Kevin Windrem avatar image
Kevin Windrem answered ·

Services added to /service are wiped out on reboot !!!!!

Some of my mods (specifically SetupHelper) which run background apps aren't running. They install the service and it runs properly but after a reboot there is no directory for it in /service. Versions previous to v2.80~10 work fine.

What's changed? What can I do about it?

For those running my mods like GuiMods, the autoupdate mechanism is being disabled during the boot process so you'll need to run updates manually.

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi Kevin

The changelog links to a commit message, please read that; it explains how to do this now.

All the best, Matthijs

Kevin Windrem avatar image Kevin Windrem mvader (Victron Energy) ♦♦ ·
The link in the change log is about making the rootfs writable, which I have done. I don't see anything about creating services.

sorry; I was sure it was there but didn't check before saying so.

Here is the nugget of info:

  • additional services should now be stored in /opt/victronenergy/service instead of /service or else they won't survive a reboot

I've also added that to the change-log above, plus added a link to our original issue (from back in 2017)

Got it. Thanks for the info. My packages have been updated. BUT ....

Because the automatic update service won't continue to run after a reboot, you may need to reinstall SetupHelper. This will start the autoupdate script. Leave the system running long enough for SetupHelper to update to v2.2.

I'm having issues with removing a service. I'm adding it to /opt/victronenergy/service and that works, with the new service showing up in /service.

However when I remove it from /opt/victronenergy/service, the directory remains in /service but it is empty. It is then impossible to remove that directory and I must reboot to get things synced back up between the two directories.

I tried removing the directory in /service first then the one in /opt... when I then reinstall the service in /opt... it does not show up in /service.

I'm having to reboot after removing the service.

How can I accomplish this without rebooting after an uninstall?

Hi @Kevin Windrem , I don't know the details about this, and Jeroen is on holiday.

More info is here:

And two questions: why do you want to remove a service? And is it an issue if the directory remains in /service but is empty?

Kevin Windrem avatar image Kevin Windrem mvader (Victron Energy) ♦♦ ·

A supervise process will be started for any directory that exists in /service even if there's no run file. So removing the directory prevents the extra process and some amount of processing time. The system impact is probably negligible but I try to keep things as clean as possible.

I'm currently removing the directory in /service too, but that leads to the second issue:

The directory in /service never gets created when the package is reinstalled.

I'm trying to avoid a reboot after uninstalling my packages but can do that as a last resort.

I dug into the overlay mechanism a bit and tried a few things. I ended up removing the service directory in both /opt/v*/servcie and the overlay "working" directory in /run/overlays/service and that seemed to allow services to be removed and reinstalled without a reboot in between.

If there's a better way, I'll change my code.

thomasw-1 avatar image
thomasw-1 answered ·

Hi Matthijs @mvader (Victron Energy),
Please be informed that in DVCC the "Limit charge current" option only takes effect on AC-OUT attached inverters, but not on MPPT using a dual PV environment (Fronius on AC-OUT and Victron MPPT). Despite the "Limit charge current" setting the complete MPPT power flows into battery instead redirecting the power into grid as along as managed battery (BYD LVL) reports a CCL>0.

From my point of view the functionality does not work compliant to ESS manual:


Battery Charing Limit shall be actually overruled by DVCC


Does not work as documented:



Solution proposal:
Functionality could be easily implemented, if Minimum of CCL and DVCC Charge current limit (in case activated) would be used by ESS to control MPPT and MultiPluses.

1629111752226.png (41.7 KiB)
1629113976708.png (43.4 KiB)
1629115124957.png (21.8 KiB)
1629115592491.png (17.0 KiB)
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

paulcooper avatar image
paulcooper answered ·

I'm keen to start using the updated version of Node-Red so I tried installing venus-swu-nanopi-20210810130839-v2.80~11-large-20 over the top of v2.70~5-large-18 using a USB stick. On clicking on the file it said that it was installing but after a few seconds it just went back to displaying the currently installed version. Should it install like this or do I need to do something else? v2.70~5-large-18 is working just fine but Venus OS and Node-Red are a little old......

2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

Hi, I’m not sure what the issue is. In case you’re familiar with ssh and such, then login amd have a look at the log files in /data/log/swupdate/.

and otherwise I can login, then enable remote support, in Settings -> General.

paulcooper avatar image paulcooper mvader (Victron Energy) ♦♦ ·

Thanks. Here is an extract from the log file:

 *** Checking for updates ***
 arguments: -update -offline -force
 Searching for update on SD/USB...
 Update found on /media/sda2
 Retrieving latest version... (from /media/sda2/venus-swu-nanopi-20210810130839-v2.80.swu)
 installed: 20210416102740 v2.70~5-large-18
 available: 20210810130839 v2.80~11-large-20
 Starting swupdate to install version 20210810130839 v2.80~11-large-20 ...
 software set: stable mode: copy1
 Swupdate v2016.10.0

 Licensed under GPLv2. See source distribution for detailed copyright notices.

 Registered handlers:
 Main loop Daemon
 [NOTIFY] : SWUPDATE running :  [extract_sw_description] : Found file:
       filename sw-description
       size 768
       checksum 0xc2c5 VERIFIED

 Version 0.1.0
 [NOTIFY] : SWUPDATE running :  [parse_images] : Found compressed Image  : venus-image-large-nanopi.ext4.gz in device : /dev/mmcblk1p2 for handler raw (installed from stream)

 [NOTIFY] : SWUPDATE running :  [parse_uboot] : U-Boot var: version = 1

 [NOTIFY] : SWUPDATE running :  [cpio_scan] : Found file:
       filename venus-image-large-nanopi.ext4.gz
       size 208044292

 [NOTIFY] : SWUPDATE running :  [cpio_scan] : Found file:
       filename u-boot-sunxi-with-spl.bin
       size 316785
       not required

 ERROR core/cpio_utils.c : cpio_scan : 485 : Checksum verification failed for u-boot-sunxi-with-spl.bin: 1dc3844 != 1ee65ba

 [NOTIFY] : SWUPDATE failed [0] ERROR core/cpio_utils.c : cpio_scan : 485 : Checksum verification failed for u-boot-sunxi-with-spl.bin: 1dc3844 != 1ee65ba

 ERROR core/swupdate.c : install_from_file : 322 : failed to scan for pos '896'!
 [NOTIFY] : SWUPDATE failed [0] ERROR core/swupdate.c : install_from_file : 322 : failed to scan for pos '896'!
 Error, do_swupdate stopped with exitcode 1, unlock and exit.
 *** CCGX booted (0) ***
I have just performed a comparison (cmp) between the file on the memory stick and the original download on my Mac. The files differ despite them being the same number of bytes! This is likely to have been the cause of the checksum error. I'll try again with a new USB stick.