Custom GUI v2 Not Reflected in VRM Remote Console (via VRM Logger)

Modifications
, , , ,
1

Hi everyone,

I’m currently running a Cerbo GX with a customized GUI v2. I’ve made some UI changes and use it both via HDMI display and through WASM-based Remote Console over SSH—everything works perfectly in those environments.

However, when I access the same Cerbo GX system via the Remote Console on the VRM Portal (through the VRM logger), I notice that the GUI there does not reflect my custom GUI v2 changes. Instead, it shows the default standard GUI-v2.

I’m wondering:

  • Why doesn’t the VRM Remote Console reflect my customized GUI v2?
  • Is there any caching or version mismatch happening on the VRM logger side?
  • How can I ensure that my custom GUI is visible when accessing via VRM?

Thanks in advance for any guidance!

2

VRM uses a cached version of the gui, when available, in order to speed up the startup of the remote console. The way VRM currently determines which gui to show is determined by the sha256 sum of the .wasm file, which is stored on the local GX in the venus-gui-v2.wasm.sha256 file.

So if you have custom gui build, you will also need to update the sum in that file and restart vrmlogger or reboot the GX. After that VRM will no longer be able to find the .wasm file in its cache and download the gui-v2.wasm file from your system instead.

Note that VRM only caches the official releases and won’t magically start caching your own .wasm file, meaning that it will always take longer to start up the remote console via VRM if you have a custom one.

2 Likes
3

This path already have my custom gui-v2 files → /var/www/venus/gui-v2
where i need to put my custom files except this path ?

4

Only the files in /var/www/venus/gui-v2 are used for the gui. Just make sure the venus-gui-v2.wasm.sha256 matches the sum of zcat venus-gui-v2.wasm.gz | sha256sum. As vrmlogger only reads the contents of the file on startup, you then either need to restart vrmlogger or the GX to make sure the new checksum gets transferred to VRM.

5

my logs

1.Using active GUI path: /var/www/venus/gui-v2 → venus-gui-v2.wasm.sha256
Installed GUI hash is :

77207148b7e61411067ed63c5f50179c2da405e05ec18496f83e893153d12d3d

2.(Sum) SHA256 checksum for “venus-gui-v2.wasm.gz” …
SHA256 checksum is :

77207148b7e61411067ed63c5f50179c2da405e05ec18496f83e893153d12d3d

Checksum matched.

Then I am doing this as instructed and rebooting the device

echo "-----------------------------------------------------------------------------------"
echo "Restarting vrmlogger to update checksum on VRM..."
svc -t /service/vrmlogger
echo "SUCCESS: vrmlogger restarted successfully."
  • The .sha256 file (venus-gui-v2.wasm.sha256) contains:
 77207148b7e61411067ed63c5f50179c2da405e05ec18496f83e893153d12d3d ../build-wasm_files_to_copy/wasm/venus-gui-v2.wasm

root@einstein:~# zcat /var/www/venus/gui-v2/venus-gui-v2.wasm.gz | sha256sum
77207148b7e61411067ed63c5f50179c2da405e05ec18496f83e893153d12d3d -

Then should have updated Gui-2 WASM over VRM, right? but it does not update it. i removed my installation device from VRM portal and again added it. to recheck it is updates or not. but it does not. I think I might be missing something very important.

6

Thank you for clarifying the issue, Dirk-Jan!

For anyone encountering a similar problem, here’s the key takeaway:

The venus-gui-v2.wasm.sha256 file must contain only the checksum and not include any file paths or extra information.

For example, if your original .sha256 file has a line like:

77207148b7e61411067ed63c5f50179c2da405e05ec18496f83e893153d12d3d ../build-wasm_files_to_copy/wasm/venus-gui-v2.wasm

Update it to contain only:

77207148b7e61411067ed63c5f50179c2da405e05ec18496f83e893153d12d3d

After making this change, ensure you restart vrmlogger or reboot your GX device to apply the changes:

svc -t /service/vrmlogger

or

reboot

This ensures that your custom GUI is correctly loaded when accessing your Cerbo GX via the VRM Remote Console.

I had the same issue, and after this simple adjustment, my custom GUI now loads correctly via VRM.

Hope this helps anyone facing similar confusion!

Thanks again!

7

@dfaber,

  1. This still results in a VRM UI mismatch for the Cerbo Gx device only. even checksum matches.
  2. Raspberry Pi does well. No issues with that.
8

The venus-gui-v2.wasm.sha256 file must contain only the checksum and not include any file paths or extra information.

Sorry to disagree, but you are making the wrong statement here. The checksum is taken from the first part of the line (see here). The code doesn’t look at anything after the first part.

Simply doing (on a root filesystem that is rw):

zcat /var/www/venus/gui-v2/venus-gui-v2.wasm.gz | sha256sum | tee /var/www/venus/gui-v2/venus-gui-v2.wasm.sha256

Overwrites the file to contain the correct checksum (and a dash as second part).

After running that, svc -t /service/vrmlogger is sufficient to update vrmlogger.

1 Like
9

Update on Custom GUI-v2 Integration in VRM UI

Thanks to community input, I discovered that the VRM UI retrieves the SHA256 hash from the following location:

/var/www/venus/gui-beta/venus-gui-v2.wasm.sha256

This behavior is defined in:

/opt/victronenergy/vrmlogger/filemonitor.py

Specifically, in the start() function:

def start(send_data):
    # Check every 10 seconds
    GLib.timeout_add(10000, partial(on_timer, send_data, FileMonitor.monitors, {}))

    # Instantiating the class persists it in FileMonitor.monitors. Add all monitors below.
    SwUpdateMonitor("/var/run/swupdate-status", "us")
    NodeRedCapabilities("/data/home/nodered/.node-red/node_modules", "nrCaps")
    Sha256SumGuiV2Wasm("/var/www/venus/gui-beta/venus-gui-v2.wasm.sha256", "guiHash")

Sha256SumGuiV2Wasm(“/var/www/venus/gui-beta/venus-gui-v2.wasm.sha256”, “guiHash”)

Previously, I had only copied my WebAssembly contents to:

/var/www/venus/gui-v2

After also placing the .wasm blob in:

/var/www/venus/gui-beta

VRM began successfully picking up my custom gui-v2.

Thanks again for the guidance!

10

Hi @James_Potter , did you perhaps by accident delete and recreate the original directory or the symlink at some point?

The two mentioned directories are the same, gui-v2 is a symlink to gui-beta, so as far as the rest of the system is concerned it is the same directory. Could you perhaps check your system to make sure it still looks like this?

root@ccgx:~# ls -ld /var/www/venus/gui-{v2,beta}
drwxr-xr-x    2 root     root          1496 Mar  9  2018 /var/www/venus/gui-beta
lrwxrwxrwx    1 root     root            23 Mar  9  2018 /var/www/venus/gui-v2 -> /var/www/venus/gui-beta
2 Likes
11

You’re spot on — I just checked with:

ls -ld /var/www/venus/gui-{v2,beta}

and it shows both gui-v2 and gui-beta as actual directories:

drwxr-xr-x    3 root     root          4096 Jun 10 03:35 /var/www/venus/gui-beta  
drwxr-xr-x    3 root     root          4096 Jun 10 03:34 /var/www/venus/gui-v2

Looks like I must have accidentally deleted and recreated gui-v2 as a physical directory during development, which broke the intended symlink behavior.

I’ve now fixed it by removing the directory and restoring the symlink:

rm -rf /var/www/venus/gui-v2
ln -s /var/www/venus/gui-beta /var/www/venus/gui-v2

root@einstein:~# ls -ld /var/www/venus/gui-{v2,beta}
drwxr-xr-x    3 root     root          4096 Jun 10 03:35 /var/www/venus/gui-beta
lrwxrwxrwx    1 root     root            23 Jun 10 03:51 /var/www/venus/gui-v2 -> /var/www/venus/gui-beta

Everything works correctly again — VRM now detects my custom gui-v2 via the proper hash in gui-beta.

Thanks a lot for the clear insight!

2 Likes