A notice arrives, and nobody can answer it
A manufacturer emails installers about a firmware release that fixes a problem with sessions stopping early. Which of the chargers you look after are affected? Some are on one management platform, some on another, some on customers' home Wi-Fi with only the manufacturer's app. The engineer who knows most about that model is on a job. A site host who has had sessions stop early wants to know whether you are dealing with it.
Versions live on the chargers
Firmware is reported by the charger to whichever back office it talks to. If you maintain chargers on several platforms, or chargers you installed but do not manage, the versions are spread across systems. Notices come by email, installer portal or distributor newsletter. Nothing connects the notice to your list of units.
- No single list of chargers with their current firmware.
- Manufacturer notices arrive in personal inboxes.
- Updates are pushed ad hoc, and their result is not recorded.
- Some updates need a site visit, and those are not scheduled.
- Nobody knows which units failed to update.
What that costs
Known issues keep causing faults and call-outs after a fix exists. Site hosts lose confidence when you cannot say whether their chargers are up to date. Updates pushed without a plan occasionally cause their own problems, and without a record, you cannot tell which units were changed when. And any warranty or support conversation with the manufacturer starts with you not knowing the version.
Roaming and payment services also depend on chargers behaving consistently. When units at one site run different firmware from each other, the same fault can look different on each bay, and the support team wastes time chasing what is really a version difference.
The firmware register we build
- We pull charger identity and firmware version from each management platform you use, through its API or export, and from your commissioning records for units you do not manage online.
- Every unit appears in one register with site, model, current version and when it was last seen.
- Manufacturer notices are logged against the model and versions they affect, forwarded from wherever they arrive. The register lists the affected units straight away.
- Your team decides whether and when to update. Approved updates are planned per site, remote or visit, with site host notice where your contracts require it.
- After each update, the register checks the reported version and flags units that did not change.
- A history per charger shows every version it has run and when, which helps with fault diagnosis and manufacturer support.
| Question | Answer today | Answer from the register |
|---|---|---|
| What firmware is this unit on? | Log in to its platform | One lookup |
| Which units does this notice affect? | Nobody can say | Listed from model and version |
| Was the update applied? | Assumed | Checked against reported version |
| What changed on this unit and when? | Unknown | Version history per charger |
Whether to apply a given update is your engineers' decision with the manufacturer's guidance. The register makes sure the question is asked and the answer recorded.
Answers when the notice arrives
The next manufacturer notice becomes a filtered list within minutes. Updates are planned and confirmed rather than hoped for. Site hosts can be told what version their chargers run and what is planned. And fault diagnosis starts with the version history in front of the engineer.
For new maintenance contracts, the register gives you a baseline on day one: every charger's version when you took over, which is useful if something that happened before your time surfaces later.
Signs you need a firmware register
- You could not list chargers on a particular firmware version today.
- Manufacturer notices go to one engineer's inbox.
- Updates are pushed without a record of the result.
- You maintain chargers across more than one platform.
- Faults recur that a firmware notice said were fixed.