The table the charger actually keeps its measurements in

Modbus mode never returned a reading: every status poll came back as "the
charger did not answer", though the charger was answering all along. It was
refusing the question. The A5191 splits its map across two tables where the
spec's single 2xxxx column suggests one — 20000-20100 are input registers and
reject FC03 with an illegal-address exception at every address in the range,
while 21000-21005 really are holding registers and read back over FC03. We
inferred one space from the spec's layout and asked for all of it with FC03.

The client learns FC04, sharing a body with FC03 since the two differ only in
which table the server consults, and the plugin's two measurement reads move to
it. Writes stay on FC06, where the controls already live.

Confirmed against an A5191 on firmware 1.0.6.1: identity, live block and the
control registers all decode as the spec tabulates them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

API Server/internal/modbus/client.go

@@ -9,10 +9,11 @@
 // (internal/plugins/builtin/ankersolix): read a contiguous block of holding
 // registers, and write one register to issue a command. Concretely that means:
 //
-//   - Function codes 0x03 (Read Holding Registers) and 0x06 (Write Single
-//     Register) only. The charger exposes its whole map — read-only and
-//     read-write alike — in one 2xxxx address space, which is the holding
-//     register convention.
+//   - Function codes 0x03 (Read Holding Registers), 0x04 (Read Input Registers)
+//     and 0x06 (Write Single Register) only. The charger splits its map across
+//     the first two: everything it measures or reports (20000-20100) answers on
+//     FC04 and rejects FC03 with an illegal-address exception, while the
+//     controls it accepts (21000-21005) are holding registers.
 //   - One request in flight at a time. Modbus TCP allows pipelining by
 //     transaction identifier; nothing here needs it, and a strictly synchronous
 //     exchange means a desynchronised peer cannot silently mismatch replies.
@@ -52,9 +53,10 @@ const (
 	mbapLen     = 7
 	protocolID  = 0
 	fcReadHold  = 0x03
+	fcReadInput = 0x04
 	fcWriteReg  = 0x06
 	excMask     = 0x80 // set on the echoed function code when the reply is an exception
-	maxReadRegs = 125  // §6.3: the largest quantity one FC03 request may ask for
+	maxReadRegs = 125  // §6.3/§6.4: the most registers one read request may ask for
 )
 
 // maxPDU bounds what this client will read back from a peer. The spec's own
@@ -163,11 +165,24 @@ func (c *Client) Close() error {
 // ReadHolding reads count consecutive holding registers starting at addr
 // (function code 0x03). Register values are returned in the order read.
 func (c *Client) ReadHolding(ctx context.Context, addr, count uint16) ([]uint16, error) {
+	return c.readRegisters(ctx, fcReadHold, addr, count)
+}
+
+// ReadInput reads count consecutive input registers starting at addr (function
+// code 0x04). It is the read the Anker charger's measurement block answers:
+// the same request shape as ReadHolding, a different table on the device.
+func (c *Client) ReadInput(ctx context.Context, addr, count uint16) ([]uint16, error) {
+	return c.readRegisters(ctx, fcReadInput, addr, count)
+}
+
+// readRegisters is the body both reads share; FC03 and FC04 differ only in
+// which table the server looks the addresses up in, not in their framing.
+func (c *Client) readRegisters(ctx context.Context, fc byte, addr, count uint16) ([]uint16, error) {
 	if count == 0 || count > maxReadRegs {
 		return nil, fmt.Errorf("modbus: cannot read %d registers in one request (1-%d)", count, maxReadRegs)
 	}
 	req := make([]byte, 5)
-	req[0] = fcReadHold
+	req[0] = fc
 	binary.BigEndian.PutUint16(req[1:], addr)
 	binary.BigEndian.PutUint16(req[3:], count)