[Bug] New GUI v2 - AC Load (ET112 via RS485) watt value freezes after ~15 minutes

Seeing a few mentions of this issue on other forums so thought I'd raise it here too — anyone else on Venus OS v3.71 noticing their AC load readings freezing after roughly 10-15 minutes on the new GUI v2?

My setup is a Cerbo GX (picked up mid-2023) with an ET112 energy meter on the AC input, running RS485. Everything worked fine on v3.70 and earlier. Since updating, the watt value on the HDMI display just... stops. The underlying data is still flowing — VRM portal shows live figures without issue — so it seems purely a display/GUI layer problem rather than the meter itself dropping off.

What I've noticed:

• Freezes consistently around the 12-15 minute mark
• Switching back to the old GUI resolves it immediately
• Restarting the GUI (via remote console) temporarily fixes it but it always freezes again
• No errors in the logs that I can spot obviously

For context, this is part of my boat's emergency backup setup, so having accurate AC load monitoring isn't just a nice-to-have — I need to know what's actually being pulled through at a glance without poking around in VRM every time.

Wondering if it's something specific to the RS485 polling interval and how gui-v2 handles the refresh cycle, but that's above my pay grade really.

Has anyone found a workaround short of reverting to the old GUI? And has this been flagged to Victron officially yet — worth raising on their community forum if not?

Would be good to know if this affects other meter types or if it's ET112-specific.

@SimonThompson yes! Been pulling my hair out over this on my narrowboat setup for the past week. Got an ET112 running through a Victron Cerbo GX and the watt reading just... stops. Locks onto whatever figure it last recorded and sits there like it's given up.

Weirdly mine seems to freeze specifically when the RS485 adaptor gets warm — noticed it happens faster on sunny days when the cabinet heats up. Coincidence or related?

Has anyone tried rolling back to v3.70? I'm tempted but slightly nervous about breaking something else. Also wondering if this is purely a GUI v2 display glitch or if the underlying data is actually freezing too — anyone checked via VRM portal to see if the cloud data shows the same freeze?

@CopperRoamer @SimonThompson — worth checking whether the freeze correlates with the Venus device's RS485 polling timeout rather than the ET112 itself. On my narrowboat I had a similar freeze pattern with a different meter and it turned out the USB-to-RS485 adapter (cheap unbranded one) was dropping its driver state after a period of inactivity. Swapped to a Victron USB-RS485 cable (ASS030572018) and the issue resolved entirely.

Before spending money though — check /var/log/dbus-serialbattery/ or the relevant Venus log for timeout errors. If you're seeing repeated disconnected / reconnected entries on a roughly 15-minute cycle, that's your culprit at the hardware/driver layer, not the GUI itself. v3.71 may simply be exposing an existing marginal connection that earlier firmware masked with more aggressive polling retries.

@DefenderAdventure that timeout angle is worth pursuing but I'd not rule out a memory leak in the new GUI v2 rendering layer first. I had something similar on my shepherd's hut setup — not the ET112 specifically, but a frozen value that looked like a comms issue and turned out to be a display thread silently dying. The underlying data was still being polled fine.

Worth SSH-ing into the Venus device and watching dbus-spy on the grid meter path while the freeze happens. If the dbus values are still updating but the GUI isn't, that narrows it down considerably to a front-end bug rather than RS485.

Has anyone raised this on the Victron Community forum yet? Their devs do actually monitor it and v3.71 is recent enough they might push a patch fairly quickly.

@ExPostie memory leak theory gets my vote — my ET112 on the cabin setup was doing exactly this until I pinned the new GUI v2 as the culprit by switching back to the old interface and watching it run perfectly for 48 hours straight like a smug little data logger.

@SophieHill interesting that pinning the GUI made a difference — does that suggest the freeze is happening at the display layer rather than the actual data collection?

On my motorhome setup I've got an ET112 pulling AC load via RS485 into a Cerbo GX and I'm wondering — when the value freezes in the GUI, is the underlying MQTT data still updating correctly? You can check via mosquitto_sub -t 'N/+/grid/#' on the Venus terminal.

If MQTT is still live but the GUI is stuck, that would confirm @ExPostie's rendering theory rather than @DefenderAdventure's polling timeout. Has anyone actually verified which layer the freeze originates at? Feels like the root cause could go either way depending on the answer to that.