Skip to main content
A roaming hub sits between CPOs and eMSPs so each one integrates once. OCPI 2.2 gave hubs a precise job: forward a request to the party it is addressed to, with the routing and message-id headers the specification requires, leave the object untouched, and carry the receiver’s answer back. ChargerDojo checks that job against your own hub. Before you register anything, open the reference hub sample. It is a full relay report from our reference hub, a test peer we run that follows every rule below and does nothing optional. Every plan can read it, signed in or not. Your report has the same shape, read from your hub’s own traffic.

​
Which versions

Hub testing runs on OCPI 2.2, 2.2.1 and 2.3.0, the versions that define message routing. OCPI 2.1.1 mentions hubs in its introduction (“A good roaming system (for bilateral usage and/or via a hub)”) but has no routing headers, no Role enum and no HubClientInfo module, so there is nothing in it for a hub test to check.

​
Check your hub’s identity

Identity testing needs one registration and runs on Integrate.
  1. In ChargerDojo, open Endpoints, choose Add endpoint and pick Test a roaming hub. The command palette entry Test a roaming hub opens the same form with the persona chosen.
  2. Keep the mode on Identity. Enter your hub’s base URL and its OCPI version. The form shows the exact versions URL we will ask for.
  3. Enter your hub’s own party. It is required on 2.3.0, where a hub names itself by hub_party_id.
  4. Enter the CPO test party your hub provisioned for us and the registration token (Token A) it issued for that party, then Register.
When the registration completes, Check identity on the endpoint opens the identity journey. It reads your hub’s Credentials and watches the Configuration Module requests your hub sends us.

​
Trace a relay between two test parties

Relay testing runs on Automate. We join your hub as two parties, a CPO and an eMSP, so a request one sends can be watched arriving at the other.
  1. In the same form, switch the mode to Relay.
  2. Enter a CPO test party and an eMSP test party, each with the registration token your hub issued for it. The two parties must differ, and the pair uses two of your plan’s endpoints.
  3. Register both. Each side registers on its own. If one side fails, its row shows Retry beside it, and the healthy side stays registered.
Test relay on the endpoint runs the relay journey. Our CPO party sends a Session through your hub to our eMSP party, sends an update for a Session the eMSP party never received so the error response comes back through the hub, and addresses one request to a party your hub does not know. Some hubs deliver between two parties only after a roaming agreement exists between them. On 2.2 and 2.2.1, when your hub’s HubClientInfo list reports our eMSP party as anything other than CONNECTED, the run sends no relay traffic and marks the relay checks unobservable with that reason. Set up the agreement between the two test parties, then run again. Automate also schedules the relay. Open Schedule on the paired endpoint, choose Hub relay, and every scheduled run re-reads both registrations and your current plan before it sends anything. A schedule pauses itself when either registration goes away and resumes on its next slot once the pair is back. Certified covers many hubs and pairs under fair use, on a quote.

​
What each check grades

Every hub journey check cites the clause it grades. These SHALL rules can fail your hub: The quotes are from the OCPI 2.2.1 chapters Message routing, Unique message IDs, Hub errors and Credentials. OCPI 2.2 and 2.3.0 print the same routing, message-id and error text; the 2.3.0 Credentials chapter carries hub_party_id where 2.2 and 2.2.1 carry the Hub role. Party ids compare as case-insensitive strings, as their CiString type says. Message ids compare byte for byte. last_updated compares as an instant, so 10:00:00Z and 10:00:00.000Z are the same value. U08 grades what the list proves. A list missing our other party is unobservable rather than failed, because a party can be activated by the relay itself, and a later delivery proves nothing about an earlier listing. An omitted, null or empty list is permitted. A list container that is present and is not a list fails. These three are observations. They appear in the report and never fail your hub: When a check’s premise is missing, the check is unobservable and the report says why. A relay that never reached our eMSP party makes U01 to U05 unobservable instead of failed, and the report shows which hop was not observed.

​
What hub testing leaves alone

Broadcast Push, Open Routing, GET All via Hubs, the HubClientInfo push and its still-alive check, chains of hubs and commands through a hub are optional for a hub or not tied to it by any clause, so no check grades them. A Gireve or Plugsurfing Roam profile is a partner expectation and never a specification verdict.

​
Learn the terms

The Learning Hub’s key terminology explains what a hub is in OCPI, the Explorer walks the Credentials and HubClientInfo modules, and the Payload Workbench checks a single Session or Credentials object in the browser. None of them sends traffic through your hub, so only the journeys above test delivery.