On a slow VPN (1Mbps), I can’t even get GUI-v2 to load, let alone be usable 
GUI-v1 however works like a bliss.
For people running GX Touch and Ekrano’s, I fully understand that GUI-v2 is a beautiful source of information about their system.
For people (like me) who run a headless system, monitor it via VRM or the Remote Display app and use the GUI purely for config, GUI-v1 is a bare essential and lightweight bliss.
That is strange; gui-v2 is a one time 10 or 20MB download and thereafter its much faster than gui-v1 is.
Very little doubt that this initial download is messing it up.
Once the UI is loaded, v2 is indeed very low in bandwidth - but I haven’t succeeded to get the UI loaded from the GX over a slow link. After 5 minutes it was still “Loading…”
Is there a way to preload the UI from local cache somehow and then have that connect to the GX as data source backend?
If my analysis is correct, GUI-v2 loads a UI one time and then has a data stream open with the GX.
I even have a sneaky suspicion that loading GUI-v2 via VRM downloads the UI from VRM and then sets up the data stream to the GX, instead of loading everything from the GX.
While GUI-v1 is a VNC session that loads & refreshes a remote screen.
The first (GUI-v2) might seem the better option, but flunks at the UI download if downloaded from the GX.
The advantage of the VNC session is no UI preload and only screen changes that need to be sent.
Even with the very chatty VM-3P75CT, the “heavy” VNC stream works without a glitch over a slow link.
Going through regular GUI-v1 menus is sometimes laggy over a slow link, but it works just fine.
If GUI-v2 UI can’t be preloaded (via VRM), it’s unusable over a slow link I’m afraid.
Hi,
The browser caches the file after the first download.
And indeed, the file is served by VRM in case using Remote Console on VRM.
You have this issue locally/accessing it directly on LAN through VPN?
Or when accessing it via VRM, or both?
When connected directly via LAN (Wifi or Ethernet), GUI-v2 loads reasonably fast.
Same case over VRM, since the UI “blob” is then served by VRM.
Over a slow link (1Mbps VPN in my case), I see traffic pegged at 1Mbps while the GUI-v2 window says “Loading…” but the download never seems to complete.
From initial findings it seems the GUI-v2 UI download session times out after a few minutes and restarts, effectively causing a never ending download loop.
Since the slow link is a VPN with MTU 1420 bytes in my case, I’ve tried lowering the MTU and MSS clamping - to no avail.
It seems the UI blob download starts in all cases but times out & restarts before the download finishes.
A lack of bandwidth for the initial UI blob download seems to be the main culprit.
Possible fixes I can quickly think of:
For me this issue is a mild inconvenience as my slow VPN serves as a backup Out of Band connection and I’ve got other ways to connect to the GX: fast main internet line, local jump server, VRM or GUI-v1.
Unfortunately, GUI-v1 doesn’t provide the same options as GUI-v2 anymore and in case of a serious issue I might lose the local jumpserver.
For people without a fast uplink and who are not connected to VRM, using GUI-v2 from outside the local network (using their own VPN for example, like I do) might pose a problem.
I’m aware that this is a peculiar use case and Victron could just say “Sorry, won’t fix, just use VRM” but at the same time Victron has always been strong about allowing people to use their systems “offline”, without requiring an internet connection to the Victron cloud.
In that regard, GUI-v2 is a bit of a party pooper for people who run their systems in a private network, not necessarily cloud connected (like me).
Edit: the Android remote GX display seems to be working more or less in the same way as the VRM option in that it runs the UI blob locally sourced and only requires the low bandwidth backend connection to the GX, so not needing to download the UI blob from the GX.
If this was available for desktop use (with a configurable remote GX IP option), that could be a solution.
Depending how it’s implemented, that could mean the comfort of using a web connection via any browser is lost by having to use a “fat client”
You could try to run the GUI-v2 app in an Android VM or emulator.
https://grok.com/share/c2hhcmQtMg%3D%3D_811ea8b2-c131-40d7-bf72-a6b7d75ad40d
That’s kind of ghetto, no ?
I doubt that I could sell that to a client 
As I haven’t tested the Android app yet, I’m not sure if it allows you to enter the remote GX IP address or if it simply autoconnects to the first one in the same subnet.
In the energy sector it’s not uncommon to have (SCADA) networks in the middle of nowhere, running on SHDSL modems with kilometers-long stretches of copper cabling between them, at speeds sometimes lower than 1Mbps.
For plain control and data acquisition that’s fast enough (and digging in fiber is damn expensive).
Loading a 10-20MB UI over those links won’t fly.
Lets start with seeing if we can extend the time-out.
The issue is easily reproducible by putting a webbrowser in dev-mode and then enabling 3G throttling.
And if that doesn’t work, there are fairly trivial other solutions.
Thanks for the report!
Matthijs
