From what I know, when updating “remotely” through VRM, the update file is first downloaded locally on the Venus OS and then, from there, with a local utility, the inverter is updated.
When updating through VC, the VC will conduct the update with the file previously contained inside VC or downloaded on the Android/iOS filesystem, locally.
So, failing when updating “remotely”, it’s an issue at the Venus OS level and/or conditions at the time of update, right?
It’s a known issue? Because I am remembering some other users have had the same problem…
Once the update is handed off by VRM, only a local issue can affect success or failure, and of course, not confirming the prerequisites for a remote update are in place.
So local conditions, like Venus OS CPU usage - another thing, not so rare, with “loaded” Venus OSes by various drivers, apps, etc. - could be a problem (?) …
I wonder if the local Venus OS update utilities (ve.can, ve.bus, ve.direct, ve.tcpip, etc) could be improved to adjust their priority levels (like on the WinOS) in order to have much more luck at updating in such cases…
In my case kwindrem/GuiMod might have been the cause kind of… memory was almost full.
My setup contains VenusGX, Quattro48/10000, 3xmppt250/100, Fronius8.2, 2xBYD15,4, Fox generator15kVA, Skylla Titan48/50(for cheaper backup generator), IstaBreeze 2000 wind generator 48V.
It’s a offgrid setup where I live since 2019.
I would imagine anything that could cause instability in the GX could cause a problem.
That is a longer list, including thermal reboots, disk full etc, and the larger the system, the more variables.
But the recovery procedures should cater for most.