Studer Xtender/VarioTrack/VarioString (needs Xcom-485 module)

Register map(s) for this device, with a note of how far each has been checked. Addresses are 0-based, as on the wire. Scale and byte order are confirmed only at the hardware-verified rung.

structure-verified

Decode path is structurally sound (addresses, widths, finite values). Does NOT prove word order or scaling.

point	address (0-based)	type	scale	unit
xtender_battery_voltage	3000	F32LE	1	V
xtender_battery_temperature	3001	F32LE	1	°C
xtender_battery_charge_current	3005	F32LE	1	Adc
xtender_state_of_charge	3007	F32LE	1	%
xtender_input_voltage	3011	F32LE	1	Vac
xtender_input_current	3012	F32LE	1	Aac
xtender_input_power	3013	F32LE	1	kVA
xtender_output_voltage	3021	F32LE	1	Vac
xtender_output_current	3022	F32LE	1	Aac
xtender_output_power	3023	F32LE	1	kVA
xtender_input_frequency	3084	F32LE	1	Hz
xtender_output_frequency	3085	F32LE	1	Hz
xtender_output_active_power	3087	F32LE	1	W
xtender_input_active_power	3088	F32LE	1	W
bsp_battery_voltage	7000	F32LE	1	Vdc
bsp_battery_current	7001	F32LE	1	Adc
bsp_state_of_charge	7002	F32LE	1	%
bsp_power	7003	F32LE	1	W
bsp_temperature	7005	F32LE	1	°C
variotrack_battery_voltage	11000	F32LE	1	Vdc
variotrack_battery_current	11001	F32LE	1	Adc
variotrack_pv_voltage	11002	F32LE	1	Vdc
variotrack_pv_current	11003	F32LE	1	Adc
variotrack_pv_power	11004	F32LE	1	kW
variostring_battery_voltage	15000	F32LE	1	Vdc
variostring_battery_current	15001	F32LE	1	Adc
variostring_pv_voltage	15004	F32LE	1	Vdc
variostring_pv_current	15007	F32LE	1	Adc
variostring_pv_power	15010	F32LE	1	kW

bench facts as documented (unverified)

doc revision

V1.6.40 (R700)

field reports — community-sourced, unverified (checked 2026-06-11)

The Xcom-485i module uses physical DIP switches to configure a Modbus address offset (0, 32, 64, or 128), which shifts the actual device address range and must be accounted for in client configurations. [source]
confirmed: xtender_battery_voltage @ 3000 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40
confirmed: xtender_battery_temperature @ 3001 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40
confirmed: xtender_battery_charge_current @ 3005 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40
confirmed: xtender_state_of_charge @ 3007 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40
confirmed: bsp_battery_voltage @ 7000 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40
confirmed: variotrack_battery_voltage @ 11000 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40
confirmed: variostring_battery_voltage @ 15000 — confirmed by Studer Modbus RTU Technical Specs V1.6.20/V1.6.40

The trust ladder

Each rung states what it proved and what it did not. Gray until proven; green is earned by hardware only.

generated — A prompt produced it. Unproven — anyone can regenerate this.
structure-verified — Decode path is structurally sound (addresses, widths, finite values). Does NOT prove word order or scaling.
coherence-checked — Round-trips through a real Modbus stack with no overlapping addresses and a word-order-sensitive codec — the map is internally coherent and wire-decodable. Does NOT prove byte-order or scaling match a real device: the emulator is seeded from the map's own types, so a uniformly wrong byte-order still round-trips. Only hardware-verified confirms byte-order/scale on the wire.
hardware-verified (software-key) x1 — Matched a real device with operator-attested readings as ground truth — the only rung that confirms word order + scaling on the wire.

Device not here? Upload its manual and get a checked map back. It's free.

Want it confirmed against your own device? Order hardware verification. If it doesn't check out, you don't pay.

Building on a lot of devices? License the library — machine-readable maps, the firmware matrix, and API access.