driver-vault/DriverVault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

The charger's address, asked for where control is set up

Browse Source 
Modbus mode had no way in from the app: the mode could be picked in Settings,
but the address the server dials had to be PUT by hand. The control card now
asks for it in the place the charger is already being controlled from.

Which provisioning the card shows follows the mode, because the two are not
alternatives to each other — OCPP installs a token into the charger, Modbus
records where the charger is. So does what the card offers: boost is a Modbus
command and appears there, clear-limit and reset are OCPP ones the register map
has no equivalent for and stay behind.

The status tiles read whichever snapshot arrived. An OCPP session counts a meter
in Wh and names a connector state; a Modbus snapshot counts the session's own
energy and names the charger's. Both land in the same two tiles.

When nothing answers, the server has already tried the address and says what it
found, so the card shows that rather than a hint written in advance.

The hint naming Own and Proxy CSMS as the way to control a charger was true
until there was a third mode; it now names all three.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tajniak81
2026-09-01 17:27:06 +02:00
co-authored by Claude Opus 5
parent f7472bada3
commit 7ccd785742
5 changed files with 199 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Web App/web/src/api.js
+20 -5
View File
@@ -329,16 +329,31 @@ export const api = {
// the reason rather than an error.
listAnkerChargers: () => request("/integrations/anker-solix/chargers"),
// Anker Solix OCPP control (per charger). getAnkerControl returns the control
// mode, connection status, provisioning endpoint + token, and a live status
// snapshot; ankerControlToken (re)generates the per-charger token the operator
// installs into the charger; ankerControlAction issues one OCPP command
// (start/stop/limit/clear-limit/availability/reset/unlock/trigger/config).
// 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.
//
// 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.
getAnkerControl: (sn) => request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control`),
ankerControlToken: (sn) =>
request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control/token`, { method: "POST" }),
ankerControlRevoke: (sn) =>
request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control/token`, { method: "DELETE" }),
ankerControlAddress: (sn, host, port) =>
request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/control/address`, {
method: "PUT",
body: JSON.stringify({ host, port }),
}),
ankerControlForgetAddress: (sn) =>
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.
ankerControlAction: (sn, action, body = {}) =>
request(`/integrations/anker-solix/chargers/${encodeURIComponent(sn)}/${action}`, {
method: "POST",