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>
