I needed the same thing, so I did the reverse engineering and I am releasing it:
What it is. A zero-dependency Python library and command-line tool that reads, validates, decodes,
diffs and edits the .rvms configuration files you download from VRM’s Remote VEConfigure, on any
operating system, without VEConfigure. It never uploads anything; you still upload through VRM as before.
What is in it
The file format written down: section structure, the integrity checksum (a plain 32-bit word sum over
each section, not a CRC, validated on every file we hold), and the per-inverter block layout.
The settings table. The per-inverter block is a flat array of 190 u16 values indexed by the public
VE.Bus setting IDs (the same numbers the MK2/MK3 protocol uses), so absorption, float, charge current,
AC input limit, low-battery shutdown, battery capacity, the Virtual Switch thresholds and more are
labelled, each with a confidence level and the evidence behind it.
A guarded editor: change a setting on every inverter by serial, recompute the checksums, and prove
that nothing else in the file moved. We have used this on four two-inverter MultiPlus systems since
July 2026 for charge voltages and Virtual Switch thresholds; every file was accepted by VRM and read
back correct.
A diff that compares files by inverter serial (the two blocks of a parallel pair swap position between
downloads, which fooled us for a while), and a qualifier that checks a file against the values you
intended before you upload and again after you re-download.
84 real files as fixtures and about 470 tests that check every documented claim against them, so
you can run the suite and see which claims hold on your own downloads.
Written-up mistakes: what the error codes mk2vsc-36/47/49 actually meant for us, why a month-old
file gets rejected, and how an upload silently reverted a fix we had made a month earlier.
What it does not do. Install or remove assistants (ESS etc.). We tried hard to do this by file and
documented every attempt: the device accepts and stores our files but the system never starts, and one
early attempt was replaced by an empty stub. That code ships as an explicitly experimental, gated module
with a long write-up of what was tried, the remaining hypotheses, and the one experiment we would run
next. If you understand the assistant record format or the device-side install procedure, that document
is where a contribution would matter most. Grid codes and the dealer password are out of scope.
Caveats, stated plainly. Everything was derived from one product family (48 V / 120 V MultiPlus
pairs, split phase), one firmware (2729560) and one format version (1.33). We hold no single-unit .rvsc, no three-phase files, and nothing from a Quattro. The most useful thing you can do is run mk2vsc validate and mk2vsc info on your own downloads and open an issue with the result, especially
if a test fails. A download, one setting changed in VEConfigure, and a second download, plus a
screenshot of the tab, names a field for everyone.