The settings table

Each BareSettingData block carries a flat array of 192 little-endian u16 values starting at block offset +0x59 (device form; +0x63 in the GUI’s upload form, see docs/FORMAT.md §4). Entry n of that array is VE.Bus setting ID n as documented by the community MK2/MK3 protocol reference, xcellsior/ve-bus-programming (FINDINGS.md, “Persistent Settings IDs 0-255”). The IDs, scales and flag bits below marked xcellsior come from that reference; the evidence that the file’s array is that table is ours.

Names for settings 0 to 65 and the flag bits are Victron’s own, from the public document “Interfacing with VE.Bus products, MK2 Protocol 3.14” (section 7.3.13, Setting and Variable IDs; Victron Energy, victronenergy.com/upload/documents). That document also defines CommandGetSettingInfo, whose scale/offset/default/min/max reply is exactly the per-setting record stored in BareSettingInfo (display value = scale x (raw + offset), scale = Sc if Sc > 0 else 1/(-Sc)). Settings above 65 are not in that document. For every setting index, the table also shows VEConfigure’s own internal identifier (EPROM_*), taken from the Delphi symbol table of the VEConfig.exe binary as extracted and published by talas9/rvsc-tools (MIT), whose .rvsc viewer decoded the same settings schema independently in July 2026. An identifier is an identity, not a meaning: it settles which setting a slot is (vs2StartOnSOC, IInvLimitDuringAssist, GridSettingsValidCheckerA) and what the vendor calls the reserved ones (NotDefinedYet, GridSettingsInt), while the units and ranges come from the device schema.

The column “In VEConfigure” says where the setting appears in the vendor GUI as tab › group › field label, so a change can be typed into VEConfigure by hand or read off a screenshot. The placement was observed on VEConfigure 1.33 and published by talas9/rvsc-tools (MIT); it is keyed by identifier, not by index (that project numbers settings from 1, so its “idx 7” is setting ID 6 here). “probable” marks a placement tied by name only. Two boxes that table left unplaced, UPS function and Dynamic current limiter, are placed here from Victron’s MK2 document and xcellsior’s toggle-and-diff (setting 0 bit 3, inverted, and setting 1 bit 12). The nine settings of the Ignore AC input tab (52 to 59 and 70) are placed from our own screenshot of that tab (see the vs2 section below); talas9’s unit was not in that mode. Seven GUI fields are computed by the GUI from other settings and six have no known setting; mk2vsc fields --by-tab lists all of them in VEConfigure’s own layout. The unit in that column is what the GUI displays; the stored quantity is in the Type and Unit columns. The placement data lives in mk2vsc/ui.py.

The table is generated from mk2vsc/fields.py by tools/gen_fields_table.py. Regenerate it after any change to the code; the code is the source of truth.

How the mapping was found

Two values were pinned early, independently of any reference: absorption voltage at +0x5d and float voltage at +0x5f, confirmed by editing them, uploading through VRM, and reading them back on live systems. When we later compared the array against the reference’s setting IDs, those two sit exactly where IDs 2 and 3 would if ID 0 started at +0x59. Reading the rest of the array under that assumption across all 178 blocks of the well-formed corpus gave values that only make sense if the mapping is right:

ID	reads	meaning under the reference	why that is convincing
5	120 on every device-form block	inverter output voltage, volts	these are 120 V units; upload-form blocks read 120 at +10
6	500	AC input 1 current limit, /10 A	50.0 A matches the installation
4	35	charge current, A	one deliberate installer limit on all eight inverters
11, 12	4850, 200	DC low shutdown 48.50 V, restart offset 2.00 V	a sane LFP floor and a 2 V restart band, fleet-wide
64, 65	200/300, 190/196	battery capacity Ah; SoC at bulk end × 0.5 %	2 and 3 battery modules of 100 Ah; the reference says “190 = 95 % for LiFePO4”
73	6300	a voltage threshold	63.00 V is the DC over-voltage protection level in our alarm history
81	0 or 1	grid code active	0 on every bare download, 1 on every GUI-authored ESS block
88	5200	solar & wind priority voltage	its high byte, 0x14 = 20, sits at +0x10a; see the Virtual Switch section

No single line is proof; the pattern is. tests/test_claims.py re-checks each row on every fixture.

Confidence vocabulary

Level	Meaning	What it permits
CONFIRMED	we wrote it, uploaded it, read it back on hardware, or matched it to a VEConfigure screen	edit with `mk2vsc edit`
HIGH	reference ID and scale give a physically sensible value on every corpus block, tied to a known property of the installation	edit with `mk2vsc edit` (you are still the first to write it)
MEDIUM	reference ID exists; scale or meaning not checked against our systems	read; edit only with `--allow-unverified`
LOW	plausible meaning from context only	read
UNKNOWN	observed values recorded, meaning unknown	read

Flag registers (IDs 0 and 1) are never edited by the writer regardless of level; we have not toggled a bit on hardware.

The device’s own schema

The BareSettingInfo section is a table of one 10-byte record per setting: i16 scale | i16 offset | u16 default | u16 min | u16 max. The engineering value of a raw u16 is (raw + offset) / |scale| for a negative scale (a divisor) and (raw + offset) * scale for a positive one (a unit such as 15 minutes). mk2vsc.schema reads it, the last column of the table below shows it, and the writer refuses any raw value outside the device’s own min/max. 189 of the 190 bounded settings (0 to 189) in the corpus lie inside their range; the exception is the flags register, whose “max” (0x6ffc) is the mask of settable bits.

What the schema settles on its own: the durations in the Virtual Switch block are raw - 1 (in seconds or minutes), charge efficiency is (raw + 1) / 256, setting 62 is the output frequency stored as a period (41667 / 2500 = 16.667 ms = 60 Hz, range 45 to 65 Hz), settings 63 and 71 are signed values centred on 32768, settings 70 and 74 are percentages at the half-percent scale, and setting 81 is a 0 to 32 index rather than a flag. What it does not give is names: scale and range narrow a setting’s identity, they do not name it.

The Virtual Switch relay mode (IDs 15 to 43)

Setting 15 (vsUsage) selects what the Virtual Switch does: 0 not used, 1 controls the relay, 2 ignores the AC input. Settings 16 to 43 are the relay-mode conditions: on-levels (16 to 18), on-times (19 to 27), off-levels (28 to 30), off-times (31 to 42) and a minimum on time (43), all named by Victron. Our systems use the ignore-AC mode, so these hold defaults.

The Virtual Switch ignore-AC mode (IDs 52 to 59, 70)

Victron calls these the vs2 settings. The “Virtual switch > Ignore AC input” tab holds eight values, a SoC threshold and a drop-down:

IDs	Tab field	Storage
70	do not ignore AC when SoC lower than	x0.5 %, MEDIUM: not in Victron’s document; 25 % on every configured block, the value the installer set fleet-wide
52, 53	do not ignore AC when load higher than … W for … s	current in 0.01 A (HIGH); seconds = raw - 1 (MEDIUM)
54, 55	do not ignore AC when Udc lower than … V for … s	volts x100 (CONFIRMED); seconds = raw - 1 (MEDIUM)
56, 57	ignore AC when load lower than … W for … min	current in 0.01 A (HIGH); minutes = raw - 1 (MEDIUM)
58, 59	ignore AC when Udc higher than … V for … min	volts x100 (CONFIRMED); minutes = raw - 1 (MEDIUM)

The load thresholds are stored as current, not watts: the tab showed 1000 W and 750 W on a 120 V inverter, and the download from the same period holds 833 and 625, which are 8.33 A and 6.25 A. Every load value in the corpus is a round number of watts at 120 V (1750 = 2100 W, 1250 = 1500 W, 1208 = 1450 W). To set a threshold in watts, divide by the inverter output voltage: mk2vsc edit f.rvms vs_load_high=17.5 is 2100 W on a 120 V system.

The four durations (53, 55, 57, 59) sit next to their thresholds. The device schema gives them offset -1: the value is raw - 1, in seconds for 53 and 55 (unit 1/60 minute) and minutes for 57 and 59. Current blocks read 3 s / 20 s / 1 min / 1 min, and 20 s and 1 min are the values on the tab. Settings 16 to 18 and 28 to 30 hold a second copy of load-high / Udc-high / Udc-low values with the same scales; probably the same conditions for another context.

The flag registers (IDs 0, 1, 60, 61)

Victron numbers the flags 0 to 63 across four registers: Flags[0..15] are the bits of setting 0, [16..31] of setting 1, [32..47] of setting 60, [48..63] of setting 61. From the MK2 document:

Flag	Bit of	Meaning when set
0, 1	setting 0	MultiPhaseSystem, MultiPhaseLeader
2	setting 0	60 Hz
3 / 7	setting 0	Disable wave check (the “UPS function” option), bit 7 must be its inverse
4	setting 0	DoNotStopAfter10HrBulk
5	setting 0	AssistEnabled (PowerAssist)
6, 8	setting 0	DisableCharge, DisableAES
11	setting 0	EnableReducedFloat
13, 14, 15	setting 0	Disable ground relay, Weak AC input, Remote overrules AC2
16 to 26	setting 1 bits 0 to 10	Virtual Switch relay-mode alarm conditions (vsonBulkProtection … vsInvert)
27, 28	setting 1 bits 11, 12	Accept wide input frequency, Dynamic current limiter
29, 30, 31	setting 1 bits 13 to 15	Tubular plate traction curve, Remote overrules AC1, Low power shutdown in AES
32, 33, 34	setting 60 bits 0 to 2	vs2offWhenAC1Available, vs2Invert, vsSetInverterPeriodTime

Bits 9, 10 and 12 of setting 0 are “not promoted options”; Victron warns that changing them can damage the device. The schema’s max for each flag register is the mask of bits the firmware supports. The writer does not edit flag registers.

IDs 128–191

IDs 129 to 189 read 0xffff on every block. IDs 128, 190 and 191 are the grid-code words: 0xffff on blocks that never had a grid code; populated once a grid code is set (128 and 191 follow the inverter’s role in the pair, 190 reads 0xfff5); partly retained after a grid code is removed. The array ends after ID 191; the assistant area follows (docs/FORMAT.md §5).

The table

IDs not listed read zero on every block (19–23, 31–36, 38–43, 61, 75–80, 82–84, 86, 89–127) or 0xffff (129–189 on bare blocks); they are omitted from the table but visible with mk2vsc show --all.

How to add or promote a field

The differential method is what produced everything above; it needs no Windows and no source.

Bracket one change. Download the file, make exactly one change in VEConfigure (or have your installer make it), download again. mk2vsc diff before.rvms after.rvms names the setting IDs that moved. One change at a time, or you cannot tell which is which.
Look for lockstep. A real setting changed by an installer’s “configure properly” pass moves on both inverters of a pair at once and converges to the same standard value across systems. Timestamps, pointers and checksums move on every save and are never settings (mk2vsc.units.VOLATILE_DEVICE).
Anchor to a screen. One screenshot of the VEConfigure tab showing the value turns a candidate into a CONFIRMED entry in seconds; it is how the Virtual Switch thresholds were pinned.
Check the scale on the corpus. A voltage should decode to a voltage on every block, not just yours. tests/test_claims.py::test_confirmed_and_high_fields_decode_to_sensible_values is where such a check belongs.
Write it down with its evidence. Add a Field to mk2vsc/fields.py with evidence and observed filled in, regenerate this table, and say what you did not verify. A field promoted without evidence will be demoted in review.

Things that cannot be found this way: fields that never vary across the files you hold (grid code, phase count, AC input current limit on a fleet where they are all the same). Those need either a screenshot or a deliberate change.