RemoteStartTransaction: behind every app tap

The message

// CSMS -> charge point
[2, "19223206", "RemoteStartTransaction", {
  "connectorId": 1,
  "idTag": "DR88231ABCD",
  "chargingProfile": {
    "chargingProfileId": 4471,
    "stackLevel": 2,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Relative",
    "chargingSchedule": {
      "chargingRateUnit": "W",
      "chargingSchedulePeriod": [{ "startPeriod": 0, "limit": 22000 }]
    }
  }
}]

// Charge point -> CSMS
[3, "19223206", { "status": "Accepted" }]

Targeting a connector

Omitting connectorId lets the charger choose any available connector, which raises the acceptance rate. Naming one is almost always what you actually want, because a driver is physically standing at a specific bay with a cable already plugged in.

Starting the wrong bay is worse than failing: a driver watches their app say charging while nothing happens at their vehicle, and somewhere across the car park another car begins charging on their credential.

Before sending, check StatusNotification for the target connector. Preparing is the ideal state — cable connected, waiting for authorisation. Sending to a connector in Available with nothing plugged in generally results in the charger waiting and then timing out.

AuthorizeRemoteTxRequests

A configuration key that changes the behaviour of this message significantly.

false is the usual production setting. The CSMS just decided this driver may charge — that is why it sent the command — so asking again adds latency for no new information.

Set it to true only where the charger must independently verify, such as a site with its own local authorisation policy. Be aware that on a roaming session this doubles the authorisation path: the CSMS asks the eMSP over OCPI, then the charger asks the CSMS again.

Why it fails

The second row is the most common real-world failure and it is not a fault. The driver has not plugged in yet, or has not pushed the connector home. A message telling them to check the cable resolves a meaningful share of these without any support contact.

The chain from OCPI

Driver app (eMSP)
      │  OCPI START_SESSION { token, location_id, evse_uid }
      ▼
   CPO / CSMS
      │  resolve evse_uid → connectorId
      │  OCPP RemoteStartTransaction { idTag, connectorId }
      ▼
   Charge point
      │  OCPP StartTransaction  ← the real confirmation
      ▼
   CPO  ──► OCPI CommandResult
        ──► OCPI Session (ACTIVE)
        ──► OCPI CDR at the end

Three network hops, each able to fail independently. Two rules keep this honest:

• Send the OCPI CommandResult when StartTransaction arrives, not on the OCPP acknowledgement. Forwarding the acknowledgement propagates a false confirmation to the eMSP, which then shows a driver that charging began when it did not.
• Carry authorization_reference through. Stitch it onto the transaction at creation, or the eventual CDR cannot be traced back to the request that caused it.

Production lessons

• Never show success on Accepted. Wait for StartTransaction.
• Always specify connectorId when the driver is at a known bay.
• Check connector status first — Preparing is the state you want.
• Leave AuthorizeRemoteTxRequests false unless a site genuinely requires local verification.
• Never auto-retry. A retry can produce two sessions; check for a StartTransaction first.
• Prompt about the cable on silent failure. It is the most common cause and the easiest fix.
• Measure command-to-StartTransaction latency per charger model. It sets the copy and the timeout your UI needs.