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>

Web App/web/src/api.js

@@ -332,13 +332,15 @@ export const api = {
   // Anker Solix control (per charger), over whichever transport the user's
   // control mode selects. getAnkerControl returns the control mode, connection
   // status, and a live status snapshot — an OCPP session snapshot in own/proxy
-  // mode, a Modbus register snapshot in modbus mode.
+  // mode, the charger's own snapshot in modbus and mqtt mode.
   //
-  // The two modes are provisioned differently, and each has its own pair here:
-  // OCPP needs a token the operator installs into the charger (ankerControlToken
-  // / ankerControlRevoke), Modbus needs the charger's address on the local
-  // network (ankerControlAddress / ankerControlForgetAddress). A charger may
-  // hold both; setting one leaves the other alone.
+  // The modes are provisioned differently. OCPP needs a token the operator
+  // installs into the charger (ankerControlToken / ankerControlRevoke); Modbus
+  // needs the charger's address on the local network (ankerControlAddress /
+  // ankerControlForgetAddress); the Anker cloud mode needs neither, because it
+  // signs in as the account and reaches the charger through Anker's own broker —
+  // which is why it is the mode for a charger the server cannot route to. A
+  // charger may hold both bindings; setting one leaves the other alone.
   getAnkerControl: (sn) => request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control`),
   ankerControlToken: (sn) =>
     request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control/token`, { method: "POST" }),
@@ -353,7 +355,9 @@ export const api = {
     request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control/address`, { method: "DELETE" }),
   // One control command. Over OCPP: start, stop, limit, clear-limit,
   // availability, reset, unlock, trigger, config. Over Modbus TCP: start, stop,
-  // limit, boost, phase, timeout, status.
+  // limit, boost, phase, timeout, status. Over the Anker cloud: start, stop,
+  // limit, boost, skip-delay, status. A command a transport cannot send is
+  // refused by name, saying which transport can.
   ankerControlAction: (sn, action, body = {}) =>
     request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/${action}`, {
       method: "POST",