The OCPP Charger and CMS Compatibility Checklist

Connection and registration

• Charger connects to the backend URL and stays connected
• Registration is accepted, and the charger identity appears as expected
• Configuration keys the platform needs are present and readable
• Heartbeat interval agreed and honoured by both sides
• Charger reconnects automatically after a deliberate network interruption

Transactions

• Session starts on local authorisation, if used
• Session starts on remote command from the platform
• Session stops cleanly from both charger and platform
• Transaction identifiers match on both sides throughout
• A session survives a brief connection loss and reconciles afterwards
• A session interrupted by charger restart resolves rather than remaining open

The last two are where billing integrity is won or lost, and they are the ones most often skipped in acceptance testing.

Meter values

• Values arrive at the interval configured
• Units and measurand match what the platform expects
• Context values are usable for billing rather than only for display
• Start and stop readings are consistent with the session total

Remote commands and firmware

• Remote start, stop, unlock and reset each execute at the charger, not merely acknowledge
• Availability changes take effect and report back
• Firmware update can be triggered, and status reports through to completion
• The charger recovers correctly from an interrupted firmware update
• Configuration changes persist across a restart

The distinction between acknowledged and executed is the single most common false pass in this list.

Interrupted and negative cases

Pull the network mid-session. Restart the charger with a session open. Restart the platform. Send a command the charger should refuse. Set the clocks apart and see how records reconcile. These are the conditions every deployed fleet meets, and the happy path tells you nothing about them.

Record what you find

Keep the message exchange for every case, against the firmware and platform versions tested. That record settles later disputes by reading rather than by argument, and it defines the regression set to rerun whenever either side releases.

How we would work through this with you

This checklist is written to be used against us as much as against anyone else. Send it to every vendor on your list including RIOD, and compare the answers.

If you would rather have the testing done independently, we will run it with your team against whichever hardware you are considering, ours included, and show the results either way. A test we only pass when we mark our own work is not worth commissioning.

The negative tests, which are the ones that matter

Most compatibility testing verifies that things work when everything is available. The failures that cost money happen when something is not.

• Power loss mid-session, and what the record looks like afterwards
• Network loss mid-session: does charging continue, and does the transaction arrive later
• Backend unreachable at session start: does local authorisation behave as configured
• Backend returning errors rather than failing silently
• A transaction interrupted and never closed, and how it is reconciled
• Reconnection after a long outage, including whether buffered sessions arrive without duplicating
• Several chargers reconnecting simultaneously, which is what happens after a regional outage
• Firmware update interrupted part way, and whether the unit recovers
• Clock wrong or unset, since certificate validation and session records both depend on it

A pairing that passes the positive tests and fails these is a pairing that works in a demonstration and loses revenue in service.