Firmware updates and diagnostics

UpdateFirmware

// CSMS -> charge point
[2, "19223240", "UpdateFirmware", {
  "location": "https://firmware.example.com/model-x/v2.4.1.bin",
  "retrieveDate": "2026-08-12T02:00:00Z",
  "retries": 3,
  "retryInterval": 600
}]

// Charge point -> CSMS
[3, "19223240", {}]

The empty response is significant: the charger acknowledges receipt and nothing else. There is no accept or reject. The only visibility into what happens next comes from FirmwareStatusNotification.

FirmwareStatusNotification

InstallationFailed is the status that costs money. Depending on the vendor's bootloader the charger may recover to the previous image, boot into a recovery mode, or fail to come back at all. That last case is a truck roll.

A charger that goes silent during Installing and does not reconnect within a reasonable window should be escalated rather than waited on.

Rollout discipline

The protocol lets you update the whole fleet at once. Doing so is how an operator turns a firmware bug into an outage.

1. Lab first. One unit of the exact model and hardware revision, on the bench.
2. Canary. A handful of units on a low-traffic site you can physically reach. Run them for days, not hours.
3. Staged rollout. 5%, then 25%, then the rest, with a hold between each stage.
4. Never all at once, and never across multiple models in the same window — you lose the ability to attribute a regression.

What to watch between stages, all of which are available for free from messages you already receive:

• Reconnection rate after install — units that never come back.
• Stop reason distribution — a rise in Reboot or Other means instability.
• StatusNotification error codes — new fault types appearing after an update.
• Transaction success rate on updated versus not-yet-updated units of the same model.

Diagnostics

GetDiagnostics tells the charger to upload a log bundle to a location you provide:

[2, "19223245", "GetDiagnostics", {
  "location": "ftp://diag.example.com/upload/",
  "startTime": "2026-08-10T00:00:00Z",
  "stopTime":  "2026-08-11T00:00:00Z",
  "retries": 2
}]

[3, "19223245", { "fileName": "CP014_diag_20260811.tar.gz" }]

DiagnosticsStatusNotification then reports Uploading, Uploaded or UploadFailed.

Two practical notes. The upload target is often FTP, which many vendors still assume — check what the model supports before promising a secure endpoint. And diagnostics bundles are frequently large; pulling them across a metered cellular link is expensive, so request bounded time windows rather than everything.

Production lessons

• Never update during an active transaction. Gate on idle state.
• Stage every rollout. Lab, canary, then percentage bands with holds.
• Re-apply configuration after every install. Updates commonly reset keys to defaults.
• Verify the firmware URL is reachable from the charger's network, not just from yours.
• Track downloaded-versus-installed separately. They are different fleet states.
• Escalate silence during Installing rather than waiting indefinitely.
• Schedule retrieveDate for low-usage hours and stagger it across the fleet so downloads do not all hit at once.
• Keep a per-charger firmware version inventory. Without it you cannot attribute a regression to a version.