Configuration keys are the least discussed and most common source of integration failure between a charger and a platform. They are how a backend inspects and adjusts a charger's behaviour, and the specification leaves considerable room for interpretation about which must exist.
That room is where interoperability problems live, and it is why version compliance on both sides guarantees very little.
What configuration keys do
A platform can ask a charger what its current settings are and can attempt to change them. Heartbeat interval, meter value sampling, connector timeouts, authorisation behaviour and many other parameters are exposed this way.
This is how a backend brings a newly connected charger into a consistent operating state without anyone visiting the site, which makes it fundamental to operating a fleet at any scale.
Required, optional and vendor specific
A platform written against one manufacturer's fleet often assumes optional keys are present because they always were. Introduce a charger that omits them and the platform cannot configure it, without either side being non-compliant.
- Some keys the specification requires every charger to support.
- Some are optional, and a compliant charger may simply not have them.
- Some are vendor specific, meaningful only to one manufacturer's units.
- Some are read only, and an attempt to change them will be refused rather than applied.
Rejected changes and silent non-application
When a platform attempts to set a key, the charger may accept it, reject it, accept it but require a reboot before it takes effect, or report acceptance while not applying it.
The third case is legitimate and specified. The fourth is a defect, and it is difficult to detect without reading the value back after setting it. Verified read-back is the only reliable way to know a configuration change took.
Where drift accumulates in a fleet
Chargers commissioned at different times, on different firmware, or reset by field engineers end up with different configurations while appearing identical in the platform. Fault patterns then become unreadable, because the same symptom has different causes depending on how a particular unit is set.
Periodically reading configuration back across the fleet, rather than assuming it matches what was pushed, is the practice that prevents this. Few operators do it until after an incident they could not explain.
Case sensitivity and naming
Key names are strings, and implementations vary in how strictly they match them. A platform requesting a key with different capitalisation than the charger uses may receive nothing, and conclude the key is unsupported when it is present.
This is a small detail with a large consequence, and it is worth ruling out before concluding that a charger lacks a capability.
What to establish during integration
- Read the full key list from the charger rather than assuming a standard set.
- Identify which keys the platform depends on, and confirm each exists.
- Test that changes apply, by reading back rather than trusting the response.
- Determine which keys require a reboot to take effect.
- Record the configuration baseline so drift can be detected later.
Why this is an interoperability question, not a compliance one
Nothing above involves either side violating the specification. Both can be entirely compliant and still unable to work together, because compliance defines a floor rather than a contract between two specific implementations.
This is the practical reason integration is verified against the platform and firmware version you intend to run, rather than inferred from a version number on a datasheet.