What the app can set, the cloud connection can set

The broker transport could move a session along — start, stop, boost, skip the
delay, cap the current — and nothing else. Everything the charger is actually
configured with sat one field away in the same messages we were already
decoding: the schedule it charges on, the plug lock, auto-start, the LED, load
balancing, solar charging, and the Modbus server the local transport depends on.
Readable, and unreachable.

The obstacle was never the cloud, it was the shape of the protocol. A setting is
not a register write. It is a *command*, and a command owns a set of fields
inside a message type — mostly one, but five own several, and the charger reads
the whole command as the new truth. A light-off schedule sent carrying only its
switch is a schedule whose start and end have just been set to midnight. So a
grouped write resends the siblings the caller did not name, using the values the
charger itself last reported, and refuses when it has never reported them. That
last part is not caution for its own sake: load balancing and solar charging
carry the serial of the meter they watch, and nothing outside the charger knows
it. An empty one would be adopted.

Those values do not arrive with the telemetry, either. The fast 0410 stream a
realtime trigger turns on carries none of them — the settings come on 0405, 0840
and 0900, which the charger sends when it has something to acknowledge. So a
grouped write may have to send a trigger first purely to make the charger talk
about itself, and says so plainly when even that produces nothing.

Everything a caller supplies is encoded before the cloud is touched at all. A
request naming one bad value changes nothing rather than half of what it asked
for, and a mistyped setting costs a validation error instead of a sign-in, a
certificate fetch and a broker connection to be told no.

mqttsettings.go holds one table and it is the only place a setting is defined:
the wire field, the name a caller uses, the state key its current value comes
from, and how a value becomes bytes. The names are the snapshot's own, so a
caller can read a status, change one entry and send it back. The existing limit
command now builds its frame from that table too rather than encoding field a8 a
second time.

Reading grew to match. The frame decoder gains the fields the grouped writes must
carry back — the two load-balance settings, both monitor serials, the solar
monitoring mode — plus the swipe gestures, and the snapshot exposes the rest of
what is now writable. One name was wrong and is corrected: field d9 was called
chargingMode after the Modbus register at 20088, but the reference has it as the
solar charging mode, so it becomes solarChargeMode and moves in beside the solar
settings. A mislabelled reading is bad; a mislabelled writable field is worse.

Over HTTP it is one action rather than a dozen, because the charger groups the
fields anyway: POST .../settings with a settings object, and settings sharing a
command travel in one frame instead of overwriting each other. The other two
transports refuse it by name and say which one has it, the way they already
refuse each other's commands. The audit trail records the values, not just that
a write happened — a setting that changes what the charger will draw, or whether
it answers on the LAN at all, is worth being able to trace afterwards.

Two things worth saying plainly. This is built from the reference project's
message maps and checked against its own frame layout, not against hardware —
there is no charger on this end to point it at. And modbusEnabled is a loaded
gun: writing it off stops the charger serving the register map, and the way back
is this transport, or the app.

The ignore rule for the local Modbus map artifact widens to the protocol maps
that now sit beside it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tajniak81
2026-09-02 18:28:45 +02:00
co-authored by Claude Opus 5
parent 576df58776
commit 90558d60b2
11 changed files with 841 additions and 24 deletions
@@ -523,6 +523,10 @@ type ankerControlBody struct {
On *bool `json:"on"` // boost
PhaseMode *int `json:"phase"` // 0 automatic, 1 single, 2 three
Seconds int `json:"seconds"` // Modbus control timeout
// Settings carries the charger's own configuration for the "settings" action,
// keyed by the names the cloud snapshot reports them under.
Settings map[string]any `json:"settings"`
}
// handleAnkerControlAction issues one command to a charger, over whichever
@@ -606,6 +610,10 @@ func (s *Server) handleAnkerControlAction(w http.ResponseWriter, r *http.Request
status, err = sess.UnlockConnector(ctx, body.ConnectorID)
case "trigger":
status, err = sess.TriggerMessage(ctx, body.RequestedMessage, body.ConnectorID)
case "settings":
writeError(w, http.StatusBadRequest,
"\"settings\" writes the charger's own configuration, which only the Anker cloud connection can do. Switch the control mode to Anker cloud (MQTT) to use it.")
return
case "config":
if body.Key != "" {
status, err = sess.ChangeConfiguration(ctx, body.Key, body.Value)
@@ -47,6 +47,12 @@ func (s *Server) ankerModbusAction(w http.ResponseWriter, r *http.Request, who *
writeError(w, http.StatusBadRequest,
"\""+action+"\" is an OCPP command; the local Modbus connection cannot send it. Switch the control mode to a CSMS mode to use it.")
return
case "settings":
// The register map holds five control registers; the charger's own
// configuration — schedules, switches, load balancing — is not among them.
writeError(w, http.StatusBadRequest,
"\"settings\" writes the charger's own configuration, which the register map does not expose. Switch the control mode to Anker cloud (MQTT) to use it.")
return
case "clear-limit":
// The register takes an explicit ceiling and the charger clamps anything
// above its rating, so "no limit" would mean writing a value we would have
@@ -19,8 +19,10 @@ package api
// on Anker's cloud being up, and on an unofficial protocol.
//
// The command set is the charger's, not OCPP's: start, stop, boost, skip-delay
// and a current limit. Everything the register map or the CSMS can do that this
// cannot is refused by name rather than as an unknown action.
// and a current limit, plus the one thing neither other transport can do at all
// — writing the charger's own configuration, which is what "settings" is for.
// Everything the register map or the CSMS can do that this cannot is refused by
// name rather than as an unknown action.
import (
"context"
@@ -94,6 +96,18 @@ func (s *Server) ankerMqttAction(w http.ResponseWriter, r *http.Request, who *ca
case "limit":
params["amps"] = body.Amps
payload["command"], payload["amps"] = "limit", body.Amps
case "settings":
// The values themselves are audited, not just the fact of a write: a
// setting that changes what the charger will draw, or whether it answers on
// the LAN at all, is worth being able to trace afterwards.
if len(body.Settings) == 0 {
writeError(w, http.StatusBadRequest,
"settings requires a \"settings\" object, e.g. {\"settings\":{\"ledBrightness\":50}}")
return
}
capability = "mqtt-settings"
params["settings"] = body.Settings
payload["settings"] = body.Settings
case "status":
capability = "mqtt-status"
default:
@@ -117,8 +131,9 @@ func (s *Server) ankerMqttAction(w http.ResponseWriter, r *http.Request, who *ca
writeJSON(w, http.StatusOK, map[string]any{"status": outcome, "result": json.RawMessage(raw)})
return
}
// The plugin answers {serial, command, status, confirmed, detail?}; relay it
// so the caller sees whether the charger acknowledged, not just that we sent.
// The plugin answers {serial, command|applied, status, confirmed, detail?};
// relay it so the caller sees whether the charger acknowledged, not just that
// we sent.
writeJSON(w, http.StatusOK, json.RawMessage(raw))
}
@@ -63,6 +63,18 @@ func TestAnkerMqttActionRefusesTurningBoostOff(t *testing.T) {
}
}
// A settings write with nothing to write is a mistake worth naming, not an empty
// command published to the charger.
func TestAnkerMqttActionRequiresSettingsToWrite(t *testing.T) {
rec := refuse(t, "settings", ankerControlBody{})
if rec.Code != http.StatusBadRequest {
t.Fatalf("empty settings returned %d, want 400", rec.Code)
}
if !strings.Contains(rec.Body.String(), "settings") {
t.Errorf("empty settings answered %q, want it to name the field it wants", rec.Body.String())
}
}
// The cloud transport signs in as the account, so unlike Modbus it carries the
// caller's resolved credentials into the plugin call.
func TestAnkerCloudConfigCarriesTheResolvedCredentials(t *testing.T) {