Charger management

Charger maintenance commands

Close a charger's connection, clear its authorization cache, ask about a transaction's queued messages, install firmware and collect diagnostics. These are actions of the same command route as start and stop, POST /v1/tenants/{tenant_id}/stations/{station_id}/commands, with stations:control, a persisted Idempotency-Key and 202 with an operation to poll. The API translates each one into the charger's protocol; no request carries a raw OCPP message.

`action`	OCPP 1.6	OCPP 2.0.1/2.1	Body fields
`disconnect`	Closes the WebSocket	Closes the WebSocket	none
`clear_cache`	`ClearCache`	`ClearCache`	none
`transaction_status`	not available (`409 command_unsupported`)	`GetTransactionStatus`	optional `transaction_id`
`update_firmware`	`UpdateFirmware`	`UpdateFirmware`	`location`, optional `retrieve_at`, `retries` and `force`
`upload_diagnostics`	`GetDiagnostics`	`GetLog` of the `DiagnosticsLog`	`location`, optional `from`, `to` and `retries`

Other console messages (DataTransfer, CustomerInformation, certificates and network profiles) are not part of this API.

The charger's answer

disconnect succeeds when the charging core closed the connection. The charger normally reconnects by itself: watch station.disconnected and station.connected events.

The other actions succeed when the core sent the message. As for configuration changes, result.charger_status then carries the charger's own answer once it arrives, null until then. Poll the operation to read it; it is never resent.

`action`	`charger_status`	Other result fields
`clear_cache`	`Accepted` or `Rejected`	none
`transaction_status`	`Accepted` once it answered	`transaction_ongoing` (`true`, `false`, or `null` without `transaction_id`), `messages_in_queue`
`update_firmware`	`Accepted`, `Rejected`, `AcceptedCanceled`, `InvalidCertificate` or `RevokedCertificate` (OCPP 1.6 answers without a status: `Accepted`)	`location`, `retrieve_at`, `request_id` (OCPP 2.x), `forced`
`upload_diagnostics`	`Accepted`, `Rejected` or `AcceptedCanceled` (OCPP 1.6 answers without a status: `Accepted`)	`location`, `from`, `to`, `request_id` (OCPP 2.x), `file_name`

CallError means the charger refused the message itself, for example because it does not implement it.

Transaction status

{"action":"transaction_status","transaction_id":21}

transaction_id is the transaction resource ID from the transactions API, on this station. Without it the charger reports only whether it still queues transaction messages. OCPP 1.6 has no such message: the request answers 409 command_unsupported and creates no operation.

Firmware

{"action":"update_firmware","location":"https://firmware.example.com/ac7-2.4.1.bin","retrieve_at":"2026-10-14T01:00:00Z","retries":3}

The charger itself downloads the file from location; Ivora never fetches it. location must be an https URL without credentials, of at most 512 characters. A signed query string is passed to the charger but never repeated in the operation result. retrieve_at is an ISO 8601 time with an offset; omit it to download now. retries is 0 to 10.

Installing firmware usually reboots the charger, which ends a charging session. While a transaction is active on the station the request answers 409 transaction_active with details.transaction_ids and creates no operation. Stop or wait for the session first. Only a signed-in Ivora platform administrator, never an API key, may send it anyway with "force": true; anyone else receives 403 forbidden. The result then says forced: true.

Follow the installation through station.firmware_status events. On OCPP 2.x their request_id equals the operation's result.request_id. station.booted reports the new firmware_version after the reboot.

Diagnostics

{"action":"upload_diagnostics","location":"https://uploads.example.com/diagnostics/ac7-01","from":"2026-10-12T00:00:00Z","to":"2026-10-13T00:00:00Z"}

The charger uploads its diagnostics file (OCPP 1.6) or diagnostics log (OCPP 2.x) to location, with the same https rules as firmware. Use an upload URL that only accepts this file. from and to are optional ISO 8601 times with an offset limiting the period covered. Charging is not interrupted.

Follow the upload through station.diagnostics_status events; source says diagnostics (OCPP 1.6) or log (OCPP 2.x). The charger names its file in result.file_name when it answers with one.

Refusals

These answer at once, create no operation and leave the Idempotency-Key unused:

Status and code	When
`422`	A field the action does not take, a `location` that is not `https` or holds credentials, a time without an offset, or `from` after `to`
`409 command_unsupported`	`transaction_status` on an OCPP 1.6 station
`409 transaction_active`	`update_firmware` while a transaction is active, without staff `force`
`403 forbidden`	`force` from anyone but a signed-in Ivora platform administrator

An offline station, an unknown transaction or a charging core that does not confirm the dispatch produce a rejected operation, as for other commands (station_offline, transaction_not_found, dispatch_unconfirmed).

disconnect, update_firmware and upload_diagnostics are not agent tools: they drop the charger's connection, can reboot it, or send its logs to a URL. clear_cache and transaction_status are.