mvader (Victron Energy) avatar image

Venus OS v2.80~41 available for testing

Good evening everyone,

A new version is available to test. All bug fixes.

In case you don't know what this message is about, please start with reading this link, which explains the Venus OS beta program.

Changes compared to the previous test version, v2.80~36, are:

  • Fix the FzSonick connection no longer working. This was broken per Venus OS v2.73. Thank you @apollo-technics & @imac for reporting.
  • Fix problem with battery energy values (kWh counters) doubling up. Thank you @Al for reporting.
  • Complete the translations, including a fix for the German version - thank you @Stefanie.
  • Ruuvis: Fix behaviour when bluetooth adapters are added/removed.
  • Change source of RaspberryPi firmware files, mostly, or perhaps only, used for the Rpi onboard Bluetooth and WiFi chipsets. We tested this on a Rpi3, both the Ruuvis and the Wifi; and there it works. Would be great if someone can test it on the Rpi4.

I've added the full v2.80 draft changelog, compared to v2.73, the latest official release, below. We're getting really close to release now. Which would be about time..!

v2.80 summary

The version we're working on, v2.80, has various highlights: the new AC Load monitoring, the new DC metering function, and also various improvements to the HTML5 MFD App including addition of translations, added support for the Ruuvi Tag wireless temperature sensors, and since this version it adds relay control by temperature.

What to test?

Same as before: the new features I mentioned in the above summary as well basically everything. And the wifi + bluetooth on the Rpi4.

There are several major changes in v2.80, which can each make things break in unexpected places. For those interested in the details, the changes I'm referring to here are (a) that the used Python version has been updated from 2.7 to 3, (b) the Open Embedded release was upgraded from Zeus to Dunfell, and we changed to a read-only rootfs. Also, various application level changes that reduce the CPU load per Victron device, useful when connecting many solar chargers for example, were made. That caused some regressions earlier, which are now fixed.

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, please first revert to v2.73, 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.

Thank you! Matthijs.

Ps. full change log - compared to v2.73:

Main new features:

  • Add support for the wireless Ruuvi temperature sensors, which also measure humidity and air pressure. Data is available in the GUI, as well as on VRM. The Ruuvi sensors are available for sale via, Victron is not stocking them. Note that while the sensor itself also reports movement aka acceleration data, that information is not available within Venus OS.
  • Add DC load monitoring, and production. Details below.
  • Add AC load monitoring. Details below.
  • Add preliminary support for the new Multi RS. Note that this is incomplete.

AC Load monitoring details:

  • All energy meter types can now be configured to a new "role": AC Load monitor. This is done in the menu where you also choose between Grid, PV Inverter and Generator. With AC Load monitor selected, the load will be shown in the Device list. Note that we still need to work on VRM for this (add it to the Advanced page, and perhaps elsewhere as well), and also note that measured loads are not used in any calculations.

DC Load monitoring details:

  • SmartShunts and BMV-712s can now be configured to be a DC Energy Meter, rather than a Battery Monitor. Two things happen when one or more SmartShunts are configured as such: (1) the power shown in the DC system box is the sum of powers reported by all SmartShunts configured as such. Allowing multiple meters is done to accommodate for example a catamaran, then you can measure the DC Systems on Port side and on Starboard side. Use the Custom name setting to give each of the meters configured as DC System their own name. (2) the DC System Current is being compensated for when setting DVCC charge current limits to Multis, Quattros and Solar Chargers. Which in more detail mains that for example when a load of 50A is being measured, and CCL by the battery is 25A, the limit given to the Multis & Solar Chargers is 75A. A valued improved for systems with significant DC loads such as Yachts, Coaches and RVs.

    Notes and limitations: (A) instead of a SmartShunt, also a BMV-712 can be used. (B) Setting it to be a DC System is done in the settings of the BMV/SmartShunt itself. (C) The NMEA2000-out feature does not support these new types, for example when using a SmartShunt to measure output of an alternator, that data is not made available on NMEA2000.

DVCC and managed batteries, connected by CAN-Bus:

  • 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.
  • Detect- and for good settings for- BMZ ESS Batteries: DVCC=ON, SVS=Off, STS=Off
  • Force-enable SVS for the Lynx Smart BMS
  • Add custom name support: user and installer can configure a name for the battery. This name is stored on the GX device.
  • Only use the selected battery monitor; affects systems that have a managed battery and a BMV (or similar) Victron battery monitor installed.
  • Fix bug: Shared Temperature Sense did not work between an temperature sensor attached to the GX device and VE.Can devices. Bug in Venus since v2.40.
  • Automatically switch to charging if a grid connection is available and a managed battery requests charge. Currently only Pylontech and some BYD batteries support a charge request indication
  • Stop solar chargers when the BMS is disconnected in an ESS system. Solar chargers will show error #67 – No BMS.


  • Change the "Total of all phases" mode to be symmetrical: all phases are adjusted to convert the same amount of power from, as well as to, DC. In the past, this option primarily avoided passing power through the DC-bus to avoid inefficiency, but didn't take full advantage of the billing arrangement to use all the available power when there is a shortfall on another phase. Now it divides the work equally across the phases, thereby making the full inverter capacity available, and with no impact on billing. More detailed text on the Community v2.80~16 beta announcement, and soon in the manual.

VRM Portal:

  • Add information to show detailed Generator information (running/not running, last run, why its running, and more) on the VRM Portal Dashboard, when enabling the Detailed view.
  • Add information to show detailed information about AC input (grid/shore) as well as AC Loads. Includes frequency and other information.

Inverter RS:

  • complete the support for the Inverter RS. Includes DVCC, control by managed batteries, SOC sync and Extra battery current, showing its error code.
  • remove support when connected on VE.Direct. From v2.80 onwards, the only working connection for an Inverter RS to a GX device is on a VE.Can network.

MultiPlus-II 2x120V:

  • Show output current & power on the second leg, as well as transmit that to VRM for logging and visualisation on the dashboard.

HTML5 Marine MFD App:

  • Fix Garmin MFD issue that appeared in a certain start-up sequence, this issue most likely existed in the design since the beginning.
  • Show the inverter/charger widget even when the AC Inputs are configured to Generator or Not available.
  • Fix fault description for non-VE.Bus chargers
  • Fix on/off state buttons for non-VE.Bus chargers
  • Add lock button that helps prevent accidental button presses like "Start generator" or "Multi Off".
  • Add Dutch, Chinese, French, German and Italian to thelanguages.
  • Add a placeholder & message in case no data is present.
  • Add 3A button to the input limit selector.
  • Hide 3rd phase in case of a split-phase system.
  • Fix keyboard buttons not working in Remote Console.


  • Reduce GX device CPU load for many system types.
  • NMEA2000-out: fix Solar sender DC instance storage to non-volatile memory. This never worked right, until now.
  • Update recognition of Fimer grid-tie PV Inverters: Fimer recently acquired ABB and is now updating the names and recognition strings in the code.
  • Increase the maximum possible power value for starting a generator, was 100kW now 1MW. Thank you Jens-Uwe P for reporting.
  • Tank inputs on Cerbo GX and Venus GX: increase max tank resistance to 300 Ohm, thank you Alex Muir for asking.
  • Improve WiFi recovery from Failure status.
  • Improve ET340 in combination with Zigbee link, when installed in a lossy/noisy environment.
  • Fix connection issue with FzSonick batteries, using the RS485-USB cable. Issue was introduced in v2.73.
  • 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.
  • Remove transmission of load averages to VRM. Those values, visible on the diagnostics page on VRM, are not used, confusing, and the D-Bus RTT time is a much better indicator of (over-)load of a GX device, hence remove them.

User interface (CCGX, GX Touch, 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
  • Slightly renamed a few VE.Bus errors and error 8 & 11 detailed status codes to be less ambiguous. And VE.Bus error 15.
  • Wifi menu: ask for confirmation before forgetting/disconnecting from a network, as well as before disabling the Access Point; to prevent accidental locking oneselves out, especially when remote.
  • In the WiFi connection menu, give so-called hidden WiFi networks a name (their mac address), so that they no longer appear as empty rows in the menu.
  • Fix missing "Recharge" text in ESS BatteryLife state field. It said "Uknown" since Venus OS v2.20.


  • 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.
  • Improve compatibility with USB-bluetooth dongles, relevant for CCGX and Venus GX.

Developers, ModbusTCP, Node-RED, MQTT:

  • Removed the Pv/Current path aka register from our internal databus. D-Bus. Going forward, to use that, you need to calculate it by dividing the power by the voltage. Affects all APIs, including Modbus-TCP.
  • Fix the definition for Modbus-TCP register 2710 (DVCC override charge voltage). Since the mistake rendered it largely useless, and this is a fairly new register, no new register is allocated.
  • 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 this commit.
  • Change the used Open Embedded release from Zeus to Dunfell. More details about OE releases are here. Dunfell is relatively recent LTS (long term support) version. The expectation is to be able to stay at Dunfell 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.
  • Enable https support for php

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.

6 Answers
Stefanie avatar image
Stefanie answered ·

I can confirm, change download location of RaspberryPi firmware files is working on RPi4.

2 |3000

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

nice - thanks. And just to make 100% clear: you mean the wifi on your rpi works, as does the bluetooth, when running the ~41 build; right?

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

Yes, exactly. Installed via Online Updates. No issues with bluetooth and wifi. RuuviTags working as well.

Kevin Windrem avatar image
Kevin Windrem answered ·

I also confirm bluetooth and wi-fi v2.80~41 working on a RPI 4 v1.2 board.

2 |3000

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

nickdb avatar image
nickdb answered ·

@mvader (Victron Energy) this update breaks VRM. See pic. GX is slow to update VRM, does not move into realtime.

PV output/AC loads missing, while new fields on the dashboard take their place.

2-way comms ( firmware or remote configure) not working, and the GX is quite slow.


Update: forcing a second reboot seems to have resolved the issue. Something didn't go well as part of the initial update.

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 Nick, which site is this & what is the remote support number shown in Settings -> General?
nickdb avatar image nickdb mvader (Victron Energy) ♦♦ ·

site 0479b7efbaae


The GX is still slower than normal.

Strange. I had a look and all seems normal. Nothing to see in the logs of the first boot, other than lots of messages about wifi which is normal.

CPU has only at 10 to 30% load, quite low. dbus-round trip time is 1 ms, excellent.

So please do keep an eye on it. Or go back and forth to the previous version a few times to see if there is a reproducible difference.

nickdb avatar image nickdb mvader (Victron Energy) ♦♦ ·
Ok, I will switch versions a bit and see what happens.

Moving around the remote console (direct via the LAN) is laggy, switching back to the previous version and it is more responsive again.

Will feedback if I can reproduce any issues.


nickdb avatar image nickdb mvader (Victron Energy) ♦♦ ·
After switching between versions, I can't reproduce the problem. Must have been an anomaly.
Goodmorning Nick, thank you. That is good to hear.

It was the same for me right after the update. It took a little longer for the AC IN widget to become visible on VRM (and I think on the GUI too). I did not report this as I thought this is rather normal when doing firmware updates.

I have seen a similar effect on the last two updates of OS Large. Several reboots were needed before two of three USB VE Direct connections become visible and this time I had to do a 'hot' replug (power on) of the USB connection to the the Phoenix 24/1600 before it was visible. I also had to set up some of the Victron node-RED nodes again. Extra reboots now have no effect and all devices continue to be visible and accessible in node-RED.

update: I think I found the system (dBHome). Also see that you updated your comment and that it fixed itself after a second update. A failed update is unlikely, the system won't boot into the newly installed version unless its integrity checks fail.

I'll take a look.

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

The update didn't fail, it was just rebooted again because the Venus was very slow.

Functionality returned after this restart.

It is still a bit laggy on the interface but usable.

Wayne avatar image
Wayne answered ·

Ruuvi sensors lost

Good morning from New Zealand, after installing (40) I have lost Ruvvi sensors, have toggled BT on and off, toggled enable sensors on and off, and rebooted Cerbo.

Sensors within 2m of Cerbo, have moved one to within 0.3mtr for testing.


2 |3000

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

Wayne's report should be taken seriously. It would be important to know where the problem lies: Is it really a Venus OS problem, are we discussing an unreliable RF technology or are the seemingly elegant Ruuvi tags still suffering from immature technology symptoms?
Hi ofcourse we’ll look into this. Note that I’m not worried at all about the Ruuvi sensor quality. Lets see first.
Good evening @Wayne , I see two sensors lost, out of two.

do you still see the sensors in the Ruuvi app on your phone?

And, bluetooth menu is still visible, right?

Is it ok if we login to check the logs?

@mvader (Victron Energy) the sensors have never missed a beat on the Ruvvi app, appologies I should have included that in my answer.

Yes no problem at all, my two way is on, feel free to jump in any time.



I also lost Bluetooth menu settings and therefore the Ruuvi's again this morning, rebooted and they all came back. CCGX with a dongle.

The last two days at exactly the same time (07:57) the Bluetooth options disappeared and Ruuvi's don't connect, until a reboot re-installs the Bluetooth.

I'm not sure what happens at this time, but I don't have a ferrite bead choke on the USB cable for the dongle from the CCGX, so I've ordered some more, in case EMI throws off the dongle?

I have seen DBus round trip sometimes goes over 100ms up to 200ms, but normally 10-50ms, not sure if it's relevant.

running v2.80~42

Hi @Al , is it ok if someone logs in to your system? Is Remote Support enabled?
Al avatar image Al mvader (Victron Energy) ♦♦ ·

Hi Al, we checked. Looks like you have multiple USB hubs in series? That won't help with the stability. If you can remove them; or replace by one long very high quality cable. Note though: no guarantees.

Since the disconnect always happens around 8am, I'd suspect something is creating a burst of interference. Perhaps a (water) heater switching on.

What we further more see in the logs is USB errors. Which is not something we're going to look further into I'm afraid.

I'll make sure to, in the official announcement and documentation around v2.80, make clear that for CCGX and Venus GX, we expect using a BLE dongle will work in most cases, but also will not in some cases and that we don't give any guarantee or support on that. I hope you understand.

We're also planning to have Shelly WiFi temperature senders, which for cases like this with range issues might prove to be a more stable platform - though also WiFi does have its challenges...

Thanks for the checking!

ps. everytime the issue happens, this is in the logs:

Jan 26 07:58:19 ccgx user.err kernel: [54341.974945] Bluetooth: hci0: command 0x200c tx timeout Jan 26 07:58:27 ccgx kernel: [54349.863403] usb 1- USB disconnect, device number 10 Jan 26 07:58:28 ccgx kernel: [54350.743774] usb 1- new full-speed USB device number 11 using ehci-omap Jan 26 07:58:43 ccgx user.err kernel: [54365.993774] usb 1- device descriptor read/64, error -110 Jan 26 07:58:50 ccgx user.err kernel: [54372.953643] usb 1- device descriptor read/64, error -110 Jan 26 07:58:50 ccgx kernel: [54373.173736] usb 1- new full-speed USB device number 12 using ehci-omap Jan 26 07:59:03 ccgx user.err kernel: [54385.753753] usb 1- device descriptor read/64, error -110 Jan 26 07:59:18 ccgx user.err kernel: [54401.113647] usb 1- device descriptor read/64, error -110 Jan 26 07:59:18 ccgx kernel: [54401.234069] usb 1- attempt power cycle Jan 26 07:59:19 ccgx kernel: [54401.893737] usb 1- new full-speed USB device number 13 using ehci-omap Jan 26 07:59:27 ccgx user.err kernel: [54410.153717] usb 1- device not accepting address 13, error -71 Jan 26 07:59:27 ccgx kernel: [54410.253753] usb 1- new full-speed USB device number 14 using ehci-omap Jan 26 07:59:38 ccgx user.err kernel: [54420.833709] usb 1- device not accepting address 14, error -110 Jan 26 07:59:38 ccgx user.err kernel: [54420.834075] usb 1- unable to enumerate USB device
Al avatar image Al mvader (Victron Energy) ♦♦ ·

Thanks for looking Matthijs, much appreciated.

Yeah, I do have a 10m active USB + Hub for the SmartShunt, which has been fine for a year or so, and then the recent active USB's 15m + 10m + Hub for the Bluetooth dongle.

I can remove the USB Hubs as they were more for future expansion, but I have just added Ferrite choke's to both ends of the USB with the dongle, and on two other cables at the CCGX which I'd missed previously, as it looks like a USB cable/ Hub issue I'll work through changes until it's stable.

If the Choke's work or if removing a USB hub works I'll update you in case it can help with Bluetooth documentation.

Having Bluetooth dongles is great, and I'm really looking forward to Shelly devices too!

Hi @mvader (Victron Energy) Just an update to say since installing Ferrite choke beads yesterday on all cables directly at the CCGX that were missing them, and both ends of the long active USB runs, the Bluetooth has been solid, even with two hubs on the two seperate USB runs.

I think this must have been the issue, sorry for the inconvenience and not realising myself, but maybe it's useful to highlight to others: ferrite choke beads are essential for Bluetooth *dongle stability on long USB cable runs, or when using USB hubs.

Mark Maritz avatar image
Mark Maritz answered ·

Just download and tested ~41.

I have a Tank 140 installed and mA settings were reset to 4mA and 20mA after update from original settings - pre update from ~36. Other settings are fine.

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 Mark, can we login the check what happened? If you atr ok with that, please enable Remote Support in the Settings -> General menu. Would be great if we can login, I’ve no similar complaints or suspicions on what this might be.

Mark Maritz avatar image Mark Maritz mvader (Victron Energy) ♦♦ ·
Hi @mvader (Victron Energy) You have access ;)
Tank 140 - Tank 3 (Garage Tanks) is the only one I am using so far.
Thank you for the quick reply, appreciated. Will report back!

Ps. Does this dip in the graph correspond with when you did the update?

Mark Maritz avatar image Mark Maritz mvader (Victron Energy) ♦♦ ·

Yes. Did update and then reset settings to original values when I notice the "water level drop".

jeffryk avatar image
jeffryk answered ·

Not sure if this is a bug or another issue since I did not test in the released firmware version. I just installed a VE resistive tank adaptor. I was surprised the options in setup and device were not the same as the directly connected tank sensors. I use a custom tank shape on all my tanks as a way of calibration. I did find where I could change the name, but it does not save the input name in the Cerbo. Settings -- Services -- VE Can Port -- Devices -- Tank Sender Adaptor. I would at least like the option to change to a custom name. Given the tank, adaptor is a VE product and it is a fairly expensive item for what it does, I would expect the same setup options as the directly connected resistive sensors.

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 @jeffryk , I looked into it, and have to disappoint you: its not possible to set a custom name for that VE.Can Resistive Tank adapter.

For that product, the logic, including available options, are defined in the tank sender adapter itself. While for direct inputs on the GX device as well as GX Tank 140, the logic is defined in the Cerbo GX.

Also its not something we'll improve in the future. With the cost of the VE.Can Resistive Tank sender adapter, and the GX Tank 140, and direct inputs on newer GX Devices, its a product thats getting close to end of life.

Sorry! And if you want to trade it to something else (I recommend the GX Tank 140 to extend number of inputs, but that does require different type of senders) I can help make sure that happens smoothly.

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

The issue with custom names extends to other CANbus senders like the SeeLevel N2K system. I was given the reason that it should be the sender to define the custom name so that all recipients of the information in the system get the same name. That's all fine if the sender is used in a larger system with other displays and if the sender can generate a custom name. The SeeLevel system has no way to do so and I suspect in many situations the sender is not capable of generating a custom hame. It is therefore important for Venus to support a local custom name.

In addition, the default names provided by Venus are unusably long. They sort of work on the Tanks overview but nowhere else where a concise name is essential.

jeffryk avatar image jeffryk Kevin Windrem ·
Kevin. Thanks, you answered my next question. I have the Wema/Kus sensors and they have an n2k converter I could purchases, however, I was thinking I would end up with the same issue that I have now with not being able to provide a custom name for the tank. In addition to your point about the default names being long, given the large number of devices, the Cerbo supports, it is important to be able to put in custom names to keep them grouped together and easily identified. I hope that VE will please consider adding the custom name option to the Venus OS.