Go the way the owner's phone already goes

Control had two transports and neither fitted the ordinary customer. OCPP waits
for the charger to dial in, which needs a public endpoint it can reach, a
certificate, and a firmware willing to talk to our CSMS. Modbus TCP dials the
charger, which needs the server on the charger's own network. Between them they
cover a charger we host and a charger we stand next to; the common case is a
charger behind someone else's router, and that had nothing.

It was never unreachable, though. The charger holds a connection open to Anker's
own broker — it is how the mobile app drives it from anywhere, and it is the
mqttStatus register the Modbus snapshot has been reporting all along. So a third
control mode joins that broker as the account: get_user_mqtt_info issues a client
certificate, mTLS to aiot-mqtt-eu.anker.com:8883, and commands go out on the same
topics the app publishes on. Nothing on the customer's side has to be forwarded,
addressed or certificated.

What travels is not an API call. The payload is a JSON envelope around a base64
binary frame the device itself speaks — marker, little-endian length, message
type, name/length/type/value fields, XOR checksum — so mqttframe.go is a codec
rather than a client, written from the message maps in anker-solix-api and
anchored on the one frame that project documents byte for byte. A frame whose
fields do not tile exactly up to the checksum is refused rather than half-read:
these arrive over a link we do not control, and a truncated frame must not read
as a charger reporting zeros.

Two of the charger's habits shape the rest. It publishes nothing unless asked, so
a status read arms a telemetry trigger and waits for the next frame, and a poll
inside that window answers from what has since arrived. And a broker connection
costs a fetched certificate and a TLS handshake while the plugin manager builds a
throwaway instance per request — so the connection lives on the account's shared
session beside the auth token, for exactly the reason the token lives there, and
closes itself after five idle minutes.

The transport also sees two signals no other one does: the boost flag, and the
plug and start countdowns. The package doc has said since the first commit that
they are never set and the derived mode must do without them. Here they are set,
so a charger that has been told to start and is counting down a delay says so
rather than sitting in "preparing", and "skip the delay" is offered only while
there is a delay to skip.

The clients generalise instead of growing a second layout. Both snapshots name
the same quantities the same way, so what was Modbus-only in the readouts is now
whichever transport read the charger — ModbusStatus becomes ChargerStatus on the
phone, mb becomes dev on the web. What each transport can be *told* still
differs, and the buttons branch on that: reset and clear-limit stay with OCPP,
the timeout and phase registers with Modbus, skip-delay with the cloud. A command
a transport has no equivalent for is refused by name, saying which one has it.

The cost is worth saying plainly. This leans on Anker's cloud being up and on an
unofficial protocol the app may change under us, where Modbus leans on nothing
but the LAN. And it is checked against the reference implementation's own worked
example rather than against hardware — there is no charger on this end to point
it at.

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

API Server/README.md

@@ -30,7 +30,7 @@ internal/
 │   └── dist/                # built panel, embedded via go:embed
 ├── config/config.go      # env + .env load, .env write-back
 ├── models/models.go      # domain types + derived-field computation
-├── mqtt/                 # hand-rolled MQTT 3.1.1 client (Greencell EVSE telemetry)
+├── mqtt/                 # hand-rolled MQTT 3.1.1 client (Greencell EVSE telemetry, Anker cloud control)
 ├── modbus/               # Modbus TCP client (Anker Solix local charging control)
 ├── ocpp/                 # OCPP 1.6J Central System (Anker Solix charging control)
 ├── pb/client.go          # PocketBase superuser client (runtime-retargetable)
@@ -185,7 +185,7 @@ GET    /api/integrations/greencell     PUT /api/integrations/greencell   POST /a
 GET    /api/integrations/greencell/chargers
 GET    /api/integrations/greencell/chargers/{sn}/state
 
-# Anker Solix charging control (Modbus TCP locally, or OCPP own/proxy mode)
+# Anker Solix charging control (Anker cloud, Modbus TCP locally, or OCPP own/proxy mode)
 GET    /api/integrations/anker-solix/chargers/{sn}/control
 POST   /api/integrations/anker-solix/chargers/{sn}/control/token
 DELETE /api/integrations/anker-solix/chargers/{sn}/control/token
@@ -319,17 +319,35 @@ Beyond the superadmin plugin registry, the built-in connectors are exposed
 per-user through `/api/integrations/*` under a **superadmin → org admin → user**
 cascade (each layer supplies defaults the next can override).
 
-Anker Solix chargers can be controlled two ways, chosen per user with the control
-mode. **Modbus TCP** (`internal/modbus`) dials the charger on the local network
-using the register map Anker publishes for the V1; the owner enables it in the
-Anker app under Settings > Integrations and saves the address it shows. It needs
-no inbound connectivity, which is what makes it the workable path for a charger
-behind a customer's router. The two **OCPP 1.6J** modes instead run a Central
-System (`internal/ocpp`) that the charger dials back into at `GET /ocpp/{serial}`
-(authenticated with OCPP Basic auth using a per-charger control token, not a
-bearer token), which requires the charger to be able to reach this server. Either
-way the owner can start/stop and set charge limits, with every command
-rate-limited and written to a `control_audit` trail.
+Anker Solix chargers can be controlled three ways, chosen per user with the
+control mode, and they differ in what the deployment has to make reachable.
+
+The **Anker cloud** mode asks nothing of the network at all. The charger already
+holds a connection open to Anker's MQTT broker — it is how the mobile app reaches
+it from anywhere — so the connector joins that broker as the account
+(`app/devicemanage/get_user_mqtt_info` issues a client certificate; mTLS to
+`aiot-mqtt-eu.anker.com:8883`) and publishes on the same topics the app does.
+Nothing is forwarded, addressed or certificated on the customer's side, which
+makes it the mode for a charger somewhere else entirely; the cost is a dependency
+on Anker's cloud and on an unofficial protocol, since the messages carry a binary
+device frame rather than an API call. It also reports two signals no other
+transport can see — the boost flag and the plug/start countdowns.
+
+**Modbus TCP** (`internal/modbus`) dials the charger on the local network using
+the register map Anker publishes for the V1; the owner enables it in the Anker
+app under Settings > Integrations and saves the address it shows. It needs no
+inbound connectivity and no cloud, but it does need the server to share a network
+with the charger.
+
+The two **OCPP 1.6J** modes instead run a Central System (`internal/ocpp`) that
+the charger dials back into at `GET /ocpp/{serial}` (authenticated with OCPP
+Basic auth using a per-charger control token, not a bearer token), which requires
+the charger to be able to reach this server.
+
+Whichever is in force, the owner can start/stop and set charge limits, with every
+command rate-limited and written to a `control_audit` trail. A command a
+transport has no equivalent for is refused by name, saying which transport does
+have it.
 
 **Greencell** takes the other route. The HabuDen wallbox has no cloud API: it is
 commissioned over Bluetooth in the Greencell GC app, pointed at an MQTT broker