I’m not sure if this belongs here, or in a non-beta forum. Move if appropriate. I’m on v3.70~88 and can’t switch back to a release version right now because of this issue.
I’m testing using a Starlink Mini in standby mode at a remote site. Standby mode offers a low cost (US$5/month), low bandwidth (0.5 Mbps) connection. So far it’s been working great for sending regular 1/min VRM updates and viewing VRM, even in realtime. I can get into Node Red just fine.
But VRM Remote Console fails. As expected, when fetching it takes a while to download (maybe 3-4 minutes?). But when it gets to “Downloading… 100.0%” it just hangs, seemingly forever. I’ve let it sit in that state for 1/2 hour with no change, and Starlink shows that network activity has basically stopped. I’ve also seen it give up in the middle of an active download (% obviously still increasing) with a message like “…appears to not be connected.” I’ve tried multiple times, both from a web browser and from the Android VRM app.
Guessing there are some timers somewhere which are tuned with the expectation of a faster link. I had no issues when using a higher speed link.
edit: I do have dbus-serialbattery installed, and would gladly test with it disabled - except for the Catch-22 that I need to get in to Remote Console to do so. Perhaps in a day or two when I’m on site.
Did I understand correctly that the GX device is connected to the internet via Starlink in standby mode and you try to access it via a fast internet connection over VRM?
If you have dbus-serialbattery installed, then you have a custom GUI running. This means the GUI is downloaded from the GX device every time you access it over VRM. Therefore the slow connection is used to load the GUI. If you use the stock Victron GUI then a cached version from the VRM servers is fetched.
dbus-serialbattery will change this behavior probably with Venus OS 3.80, as soon as modifications are allowed for the web GUI (WASM/Webassembly).
You can run /data/apps/dbus-serialbattery/custom-gui-uninstall.sh to uninstall the custom GUI. To prevent installation on reboot you have to remove the bash /data/apps/dbus-serialbattery/custom-gui-install.sh from /data/apps/dbus-serialbattery/enable.sh .
I added a new config option with dbus-serialbattery `v2.1.20260302dev` where you can set GUI_INSTALL_CUSTOMIZATIONS to False. This should solve your issue.
Thanks. It may work over Starlink standby mode now (I’m assuming I’d need to cache the GUI previously over a faster link), but one of the reasons for having dbus-serialbattery was to be able to see all the cell voltages and the other detailed info which it makes available. That’s not available without the custom GUI. I’ll just be patient and see if things get better in the future.
The issue you’re experiencing is because GUIv2 requires a (one-time) download of a rather large “blob” of data, before switching to a low-bandwidth connection mode.
On low bandwidth links this is an issue because the blob download times out before it is fully loaded.
I’ve noticed (and reported) this before and things should have improved, but I haven’t been able to decently follow up just yet.
Possible workarounds:
Try connecting from VRM as this will download the blob from VRM and not from your GX
Connect to GUIv2 when on site so the big blob is cached on your PC and doesn’t need to be re-downloaded when you’re at home
Connect using GUIv1
GUIv1 is basically a VNC session that takes a bit more bandwidth to run but doesn’t require the big “blob” download.
I think it’s an issue because the timeout seems to be based on how long it takes the GUI to download, instead of on the download actually failing. It should not time out if the GUI is still being received. Basing it on the overall time requires making (incorrect) assumptions about link speed.