Venus OS v3.66~1 available for public beta testing

UPDATE: v3.66 has been officially released on Sept 16th 2025

Good day!

v3.70 beta testing is briefly paused, in favor of preparing v3.66 for official release.

The plan is to release v3.66 next week; after which we’ll continue with v3.70.

Change log below, and first please make yourself aware with the beta testing instructions:

Instructions 1 of 3: Venus OS beta testing & how to join/install

In case you don’t know what this message is about, please start with reading this link, which explains the Venus OS beta program. Venus OS is the software running on all our GX devices, such as the Cerbo GX.

Instructions 2 of 3: How to report an issue?

Before posting, please check if your issue already exists, in which case please contribute by replying to that issue or up-voting it.

Only once you are sure its a new possible issue, start a new topic.

Lastly, before posting, preferably first revert to the latest official release, 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 let us know if you did that, and what the difference is. A perfect report contains:

  • How its expected to work

  • How it doesn’t work as expected

  • Details on the system

  • What you’ve already tried to make sure its not a setting or other issue.

Please take note that that this works quite differently than it used to do on the old version of Community:

  • For a new issue, open a new topic. Instead of adding a new reply at the bottom.

  • To add to an already open issue, aka topic, reply to that. Or just upvote it if you have the same issue. This will help us a lot in determining its importance and manage our priorities.

Instructions 3 of 3: using Node-RED, Kevin’s SetupHelper, GuiMods, dbus-serialbattery or other add-ons?

Node-RED or Signal K

In case you are running Node-RED or SignalK, then please at least say so in your bug report.

SetupHelper, GuiMods, dbus-serialbattery

Modifications such as the popular GuiMods, SetupHelper, dbus-serialbattery and other 3rd party add-ons: do not report your issues here. Please do it elsewhere instead; and make sure to check out the related issue tracker first.

These topics and beta testing and bug reports are only for clean systems.

Change log

  • Fix VRM connection issues for Remote Console for the Classic UI as well as Node-RED dashboard that affected some systems. The fixes are related to IPv6 only networks as well as networks that block outgoing connections on port 22.
  • Improve connection stability for Solar Edge PV Inverters.
  • ESS: Fix bug causing the “grid meter is missing” alarms to no longer show up when the meter was lost.
  • Various under water stability improvements
1 Like

Anything in particular we should test?
As in: are there specific sections/functions in the code that were updated?

Thanks for asking. The under water improvements are two memory leaks that caused some services to regularly restart, really well tested and clean fixes - nothing to do there.

Also some stability improvements to the VE.Can driver: connection to VE.Can devices needs to keep working; as long as nothing unexpected happens there then its good.

And lastly these features via VRM:

  • Remote Console on VRM Classic UI
  • Node-RED editor + dashboard over VRM
  • Signal K admin over VRM

For systems where that worked without issue it needs to stay working. In some systems it didn’t work (the ssh connection on which those remote features depend could not connect); with this version, all know reasons for that have been solved.

otherwise its just as usual: system needs to work as stable as normal.

3.66~1: I can confirm the big memory leak is gone but the slow one seems to still be there but may not be an issue. venus-platform process also stable. See below (ignore the hiccup) in the middle.

Hey @IngoDeJager thank you for the reply.

We’ve not seen other concerning memory leaks.

venus-platform was indeed the biggest issue - now solved so that is good.

We’re planning to release v3.66 tomorrow morning.

3 Likes

On one of my systems (that has the original Multiplus instead of Multiplus-II’s, not sure if this is related) I did notice the occasional Node Red restart so I started monitoring the Node Red service uptime.
That system is now running v3.66~1 for ~15 hours and so far so good.
The other bits never failed (noticeably) here so can’t really comment on those.

I don’t think the type of Multi is related.

To get any further, check the logs of node-red itself, as well as /data/log/messages*.

Perhaps the reason of those restarts are in there.

Hi Matthijs,

I’m not on the V3.66~1 yet because I only just found out the issues I’m having are related to these memory leaks decribed above. I have completely resetted my Cerbo’s and installs 2 times now in hopes to solve it that way, but it was always an temporary fix.
You talk about rolling out the V3.66 release today or tomorrow. Is it worth for me to update to the beta still, or should I just await the public release?
Because of your latest comment here about the logs, I checked those as well and get the following message almost every second: einstein auth.notice dbus-daemon[514]: [system] Rejected: destination has a full message queue, 0 matched rules; type=“signal”, sender=“:1.94” (uid=0 pid=559 comm=“/opt/victronenergy/gps-dbus/gps_dbus -s /dev/ttyRU”)
I understand this will be GPS related of course. I have an external device that pushes GPS data in NMEA to the Cerbo, but wondering what would cause this error to appear 3-4 times per second.

Hi all, fyi; v3.66 has been released officially just now.

Changelog as per above - and official version is on Victron Professional and on Dropbox.

@LucGH: yes you can install v3.66.

dbus-daemon message rejected sounds like an overloaded system; I’d install v3.66, and then see what happens over time.

I still don’t see the Phoenix Smart IP43 Charger showing correctly on Venus OS. The Overview page shows a “Inverter/Charger” instead, even if the system doesn’t have one. There is no way to show the charger on the Overview page, and show its connection to shore power, or flow of charging the batteries.

I installed the official release of Venus OS v3.66 and now the Classic UI got a real bad image quality (see screenshot) compared to the previsous installed version 3.54. It seems that it is heavily compressed and I see it on all my devices.

2 Likes

I’ll try that next time if/when the issue presents itself, at the moment it’s not critical enough (read: too much other work) to warrant an in-depth investigation.
The setup is quite standard and there’s nothing special in the Node Red flow either so probably it is/was due to the memory leak.
Will check and report back in case the issue reappears.

I don’t want to scare anyone but 3.66 still has an unusual random free memory loss. This time it looks like the gui process. My usage is mostly GUI V1 with a now-and-then look at V2 interface. See below when things go downhill.

1 Like

Nice find !
And damn :frowning_face_with_open_mouth:

My Cerbo finally crashed due to cpu load, caused by out-of-memory. It took about two weeks to get to this point. Some data below on the opt/victronenergy/gui/gui process.

Oct 6 21:01:10 einstein daemon.err watchdog[473]: loadavg 8 7 7 is higher than the given threshold 0 10 6!
Oct 6 21:01:11 einstein daemon.err watchdog[473]: repair binary /usr/sbin/store_watchdog_error.sh returned 253 = ‘load average too high’
Oct 6 21:01:11 einstein daemon.alert watchdog[473]: shutting down the system because of error 253 = ‘load average too high’
Oct 6 21:01:11 einstein daemon.err watchdog[31617]: /usr/sbin/sendmail does not exist or is not executable (errno = 2)
Oct 6 21:01:13 einstein syslog.info syslogd exiting
Oct 6 21:03:34 einstein syslog.info syslogd started: BusyBox v1.36.1

Data prior to the watchdog rest due to high cpu caused by out-of-memory. It started to swap heavily at this point, all symptoms of no more free memory.

root@einstein:~# top
Mem: 1012544K used, 16448K free, 10552K shrd, 688K buff, 26300K cached
CPU:  15% usr  69% sys   0% nic   3% idle   7% io   3% irq   0% sirq
Load average: 3.79 3.97 3.58 6/274 20112
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
   38     2 root     RW       0   0%  29% [kswapd0]
  840   826 root     R     889m  88%  11% /opt/victronenergy/gui/gui -neatvnc 127.0.0.1
20112 20090 root     R     2704   0%  11% top

At the point of reload where the CPU spiked and it was out or resources.

1 Like

This is interesting data, and strange at the same time.
I’ve got a pair of Cerbo’s running v3.66 for 25 days now and neither of both show indications of running out of resources.
Others have less uptime but I can’t remember if I’ve manually rebooted them or not.

It seems to start around the time I use the V1 UI interface and making a few changes to eg. grid setpoint, grid feedback etc. but I can’t be 100% sure. At the moment it’s again at a low available free memory after a few days behaving perfectly normal. I am hoping someone tells me it’s me doing something or it’s actually something that is a rare issue. It started when I upgraded from 3.5 to 3.6 but then it was the venus-platform process. Once that got fixed the gui process is the culprit.

Stuff running on Cerbo (all disabled with no effect so I enabled them again):

  1. Script to upload data to PVOutput.org.
  2. Script to read MPPT Temperature and upload to VRM.

External Data:

  1. Modbus access to read a few registers.
  2. MQTT to Home Assistant broker.
  3. Uptimekuma polling availability (ICMP), UI (https) and MQTT availability.

Here is the current data.