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
Since V2 I face comparable issue regular, mainly with GX connected via GSM/Mobile. I spent some time to debug a bit more deep now and like to share my finding after I found your communication which looks realted to same in my understanding, but did not point the root cause.
After authentication the Browser/Client is loading a file/url …./gui-v2/venus-gui-v2.wasm which is about 32 Mbytes in my case. This file is required and sucessfull load is needed to continue. The file is loaded from remote GX and not from a “central Server/cloud”. As well after reload the file is loaded once again.
This give to me an explaination for the long login process, which get sometimes blocked as well.
I hope that in future version the load from remote GX is not a fixed configuration. This is blocking access to GX in some circumstances (low Bandwidth related to bad GSM or Wifi/packet lost, high RTT). As well this is adding transfer volume on the remote SIM for each login.
I would see the below as a good workaround/improvement for this cases (maybe some other exist as well?) :
When combining both ideas it would means if all 5 GX in my example load the .wasm from same url and it can be cached that this should give a significant boost in login procedure. Specialy if .wasm is loaded not from remote GX anymore.
Best Regards,
Uwe
This is why I use GUIv1 for direct connections and GUIv2 via VRM.
I haven’t been able to put time into searching options for loading GUIv2 more efficiently but it would help a lot if we could point it to a single local cache for every GX.
And in a perfect world this local cache would update from a repository on the fast internet and/or in an incremental way (rsync style) so the entire .wasm file doesn’t need to be downloaded if only a small portion changes.
Thanks Bart !
I did not realized thart the GUI-v1 is still available. Indeed a workaround to bypass the loading issue for a while. Anyhow would be good to have “one” GUI in the future.
Hi!
The download is 15MB, not 32MB. What you’re looking at there is most likely an uncompressed file size.
And for most users and situations, getting the wasm.gz file from the GX is fastest.
And getting it from the internet will be slower.
So, while technically possible, doing it the way you propose solves an edge case, and adds complexity.
What would be needed for just your use case is to add javascript to the little local webpage that tries to get the correct file from the cloud/vrm using XHR. And only when not available there, get it locally.
Lastly: the file is definitively cached in the browser. We have tested and are continuously testing this rigorously: after downloaded once, browser cached that large file and it won’t download it again.
Ps. one central and fast cache could VictronConnect App.
More precisely: an embedded webbrowser in VictronConnect.
Hi Mattjijs,
I took the filesize from Browser Info and did not measured the volume transfered over GSM. If browser shows uncompressed and transfer is compressed, then indeed it´s less than 32 MBytes.
I do agree that if connection happen on LAN the load from GX is quicker and cheaper and more simple as it´s local. But I do not think that it´s very special to connect to GX via GSM/APN. Or I am the “only” one connection to GX from Remote without VRM ?
For me the GX was loading the .wasm but not cached, I will spent time to check if/when/how the cache will work/not work and try to figure out details maybe related to browser or setup back to you. Let´s assume this is fixable as you reported cache is tested/working/supported.
Anyhow, as well if caching will take place the .wasm would be loaded each time (at least) once when connecting to another GX as the url is different (different host, but same file)
I do agree that this option needs some check as if prefered url is not usable there need to be a fallback to .wasm hosted on GX. As well handling remote connection and LAN connection need to get handled optimal.
Why not allow the user/client to decide? Let´s say in example when login and password is provided an option as “checkbox: load .wasm from Internet” ? This would give responsibility to user, does not requrie handling of prefered and fallback url, as well no detection or “best decission”
As I saw the url/Filename of .wasm is always the same. I did not done a diff on the .wasm files but I assume the .wasm is different at least for different Firmware Version of GX. So it could be good to allow “self build caching” more simply by adding a kind of VersionID into the .wasm. Otherwise the self build cache would load always “the one and only” .wasm but not the required. Ignore this comment regarding .wasm difference if the .wasm is static over all Version, as noted I did not done a diff, so it´s just an assumtion.
Thanks, Uwe
Following this as I’m having the same issue but with a fast GSM connection (>20Mbps), 3.66~1 rarely loads, 3.70~26 always loads <10s. With 3.66 I see a 15Mbps spike in the data flow which looks like a 15Mb glob but the browser sticks on ‘loading’.
hey @TheITBoat , it is possible that we already made an improvement in v3.70.
and @UweZ understood. No I don’t think your the only one, but surely its not a large percentage of people that access their system that way.
we have such caching mechanism on VRM, and there it filename is different per version. Try accessing a system over VRM and you’ll see what I mean.
And also there it first tries the cache, and if correct file is not in cache it will download it from the GX device over the ssh-tunnel used for that and a few other things; which wrt gui-v2 mostly for those systems that run with a modified gui-v2.
Tried 3.70~35, says downloading.. very quickly gets to 27.1% then stops, VRM is OK, gui-v1 is OK, no bandwidth issues that I am aware of. Eventually errors with:
Error loading application!
URL: http://192.168.xxx.xxx/gui-v2/
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36
TypeError: network error
Stack: TypeError: network error
Developer tools says Starting watchdog timer - (console.log(“starting watchdog timer”))
Tried an android tablet, basically the same but stops at 63.7%, clearing cache doesn’t change anything
With Venus OS 3.70~41 a new feature was added, where you can download the WASM file (GUIv2 binary, the biggest file to download) from VRM instead of the local device.
Add ?download=vrm to your GUIv2 URL, like http://venus.local/gui-v2/?download=vrm This will help, if your client (like laptop or smartphone) has a faster connection to the internet than it has to your GX device.
When the local WASM download fails, the error message will now also recommend to try this.
That’s a great feature. Any news on a possible security lock feature, to allow the access to GUIv2 for display purposes only, without exposing all the settings?
