SmartSolar missing from New UI: GX instance 2147483648, VRM changed from 279 to 65535

[ibot (Tobias)]

Hi everyone,

My SmartSolar has disappeared from the New UI, while it remains visible and operational in the Classic UI and VictronConnect.

My setup:

• Cerbo GX with GX Touch

• Venus OS v3.81 Large; the issue was already present on v3.80

• SmartSolar Charger MPPT 250/70 rev2, connected via VE.Direct

• MPPT firmware v1.74, product ID 0xA069

• VictronConnect v6.43 reports this as the latest firmware for this MPPT

• MultiPlus-II 48/5000/70-50 and Pylontech US3000C batteries

What I can observe:

• In the Classic UI, the MPPT is listed as connected and shows current PV production and charging current.

• VictronConnect also shows live values and “External control”. Charging continues, including approximately 2.6–2.7 kW when the screenshots were taken.

• In the New UI, the MPPT is missing from both the device list and the overview. This happens directly on the GX Touch and in the Remote Console.

• The Classic UI’s MPPT device-information page shows VRM instance xxxxxxxxx.

• VRM now contains two entries with the same MPPT serial number:

  • Instance 279: last connection shown as 21 October 2026, 17:23.

  • Instance 65535: updating live.

I also checked Settings → VRM → VRM device instances in the New UI. The SmartSolar is absent there too; only disconnected digital-input and tank entries are listed, so I cannot correct its instance through that menu.

Restarting the GX and unplugging/reconnecting the VE.Direct cable did not resolve it. No correction via SSH has been made.

Has anyone seen this combination of instance values and a device disappearing only from the New UI?

Is there a supported way to restore the original instance 279 without SSH, ideally preserving the existing VRM history? Could the large instance value explain why the New UI omits the device, and what diagnostics would help confirm the cause?

Screenshots show the Classic/New UI comparison, the instance value on the GX, and both VRM entries.

Thanks for any guidance.

[lxonline (LX)]

For the vrm side there was a banner up yesterday about issues related to a worldwide problem. These would have been affecting things to and from the VRM.

For the local UI V2 now. Have you tried the classic reboot just one more time? Kidding. Did this happen soon after an update

[ibot (Tobias)]

Thanks, LX! The GX has already had its reboot

I first noticed the problem yesterday evening. The VRM screenshots also give us a useful timestamp: the original MPPT entry, instance 279, was last seen on 21 October at 17:23:07. The same physical MPPT, with the same serial number, now reports under instance 65535. The Classic UI shows 2147483648.

So it looks as though the instance changed around 17:23 yesterday.

I also use gx_android and install every update, including the updates from 1.2 to 1.4. However, I can’t yet tie the problem to a particular gx_android or Venus OS update.

The issue also occurs directly on the GX Touch in the New UI. The Classic UI still shows the MPPT and live values correctly.

[ibot (Tobias)]

TL;DR: The MPPT’s VRM instance in localsettings had been overwritten with -2147483648. The immediate cause was an invalid instance value stored in localsettings. Fixed with one dbus command over SSH. Instance 279 is back, history continues.

What was broken

The stored assignment in /data/conf/settings.xml read:

<vedirect_HQ2334N7Y37>  
  <ClassAndVrmInstance type="s" default="solarcharger:279">solarcharger:-2147483648</ClassAndVrmInstance>  

That one value explains all three symptoms:

• The VE.Direct driver publishes it unsigned → Classic UI shows 2147483648.
• VRM clamps it to the 16-bit maximum → second device with instance 65535, and 279 stops updating.
• The New UI treats it as invalid → MPPT disappears from the device list, the overview, and from the VRM device instances page itself.

Tanks, temperature inputs and digital inputs 2–4 had similar garbage values (e.g. tank:-805306368, temperature:-1473155072), which is why that page only listed a few disconnected entries.

How it got that way

The localsettings log (/var/log/localsettings/) keeps every change with old and new value. Digits were being typed into the instance fields in about ten bursts – not by me; most likely accidental touch input on the GX Touch or through the Android app I use to mirror the UI. The pattern is unmistakable:

13:16:56  adc_builtin0_3  tank:21  → tank:2111  
13:20:45  vedirect_HQ…    solarcharger:279 → solarcharger:1639830926  
13:21:12  vedirect_HQ…    solarcharger:1639830926 → solarcharger:155189248  
13:25:25  vedirect_HQ…    solarcharger:155189248 → solarcharger:-2147483648  
14:01:57  adc_builtin0_3  tank:44 → tank:444 → 4444 → 44444 → … → 444444411  
14:36:48  adc_builtin0_3  tank:444444411 → tank:149476815  

444444411 plus one more “1” is 4 444 444 111; minus 2³² gives exactly 149 476 815. Same for 232222222 + “2” → -1972745074. The field accepts any digit string, doesn’t range-check, and stores the wrapped result.

The driver only reads its instance at startup. VRM therefore kept logging under 279 until the GX restarted at 17:23 – which is why the “last seen” timestamp pointed at a reboot rather than at the actual change.

Getting root access (New UI)

1. Settings → General → Access & security → access level User & installer, password ZZZ.
2. On that same page, drag the whole list down and hold it for about five seconds until the access level flips to Superuser. Works on the GX Touch and with the mouse in Remote Console.
3. Set root password and enable SSH on LAN (both only visible as Superuser).
4. ssh root@venus.local

Victron’s page for this: Venus OS: Root Access [Victron Energy]

Diagnosis

dbus -y | grep solarcharger                                 # → com.victronenergy.solarcharger.ttyS7  
dbus -y com.victronenergy.solarcharger.ttyS7 /DeviceInstance GetValue   # → 2147483648  
dbus -y com.victronenergy.solarcharger.ttyS7 /Serial GetValue           # → HQ2334N7Y37  
grep -n -B3 'ClassAndVrmInstance' /data/conf/settings.xml  
cat /var/log/localsettings/@* /var/log/localsettings/current | tai64nlocal | grep ClassAndVrmInstance  

Fix

cp /data/conf/settings.xml /data/conf/settings.xml.bak-$(date +%F)  
dbus -y com.victronenergy.settings /Settings/Devices/vedirect_HQ2334N7Y37/ClassAndVrmInstance SetValue solarcharger:279  
svc -t /service/vedirect-interface.ttyS7        # restart the VE.Direct driver so it re-reads the instance  
dbus -y com.victronenergy.solarcharger.ttyS7 /DeviceInstance GetValue   # → 279  

SetValue returns 0 when localsettings accepts the value. After the driver restart the MPPT reappeared in the New UI and VRM resumed logging under 279. I rebooted once afterwards for a clean process tree. No VRM history lost.

Cleanup: reset the other mangled entries the same way (tank:21 etc.), deleted the stale 65535 device in VRM, set the GX access level back to User, disabled SSH on LAN. The root password is wiped by the next firmware update anyway.

Two suggestions for Victron

1. Input validation: the instance field in the New UI should be limited to 0–65535. Right now it accepts arbitrary digit strings, wraps at 2³² and writes negative instances to localsettings.
2. No lock-out: a device with an out-of-range instance disappears from the New UI and from the very page that could fix it. I could not repair the affected entries through the normal UI and used SSH to recover them. Showing such entries (flagged as invalid) on the instances page would make this self-repairable. VRM silently creating a second device with instance 65535 hides the problem further.

Thanks LX – the reboot wasn’t the cause, but “what happened just before” was the right question.