OCPP Remote Start & Stop: How CPO Apps Trigger Charging

By Rodolfo Carrillo

Quick answer

The CSMS sends RemoteStartTransaction with an idTag (and optionally a connectorId). The Charge Point responds Accepted or Rejected — then sends a regular StartTransaction when energy actually flows. To end a remote session, the CSMS sends RemoteStopTransaction with the transactionId; the Charge Point then sends a regular StopTransaction.

Remote vs local start

OCPP supports two ways to start a charging session:

🪪 Local start

Driver presents an RFID card or plugs in (for autostart). The Charge Point sends Authorize, then StartTransaction. No CSMS command needed to initiate.

📱 Remote start

A CPO backend or driver app sends RemoteStartTransaction via the CSMS. The Charge Point receives the command and starts a session — no physical token presented at the charger.

Remote start is the foundation of every "start charging from the app" user experience. It is also used for fleet management, automated workplace charging, and price-triggered smart charging sessions.

RemoteStartTransaction

Field	Required	Description
idTag	Yes	Authorization token for the session. Max 20 characters. Must pass local or online authorization at the Charge Point.
connectorId	No	Target connector. If omitted, the Charge Point picks an available connector. Must be ≥ 1.
chargingProfile	No	An optional TxProfile that limits power for this specific session from the moment it starts. See the section below.

The Charge Point responds with status: "Accepted" or status: "Rejected". Accepted means the command was received and will be executed — not that the session has started. Rejected typically means the connector is occupied, the Charge Point is in maintenance mode, or the idTag failed local authorization.

CSMS → CP: RemoteStartTransaction

[ 2, "rst-001", "RemoteStartTransaction",  "idTag": "APP-SESSION-42", "connectorId": 1  ]

Full start sequence

Remote start — complete message flow

1. App triggers session via CPO backend API 2. CSMS → CP RemoteStartTransaction { idTag: "APP-SESSION-42", connectorId: 1 } 3. CP → CSMS  (command accepted, will try to start) RemoteStartTransactionResponse { status: "Accepted" } 4. CP connector transitions: Available → Preparing StatusNotification { connectorId: 1, status: "Preparing", errorCode: "NoError" } 5. EV plugs in / cable authorized — energy flows StartTransaction { connectorId: 1, idTag: "APP-SESSION-42", meterStart: 45230, timestamp } StartTransactionResponse { transactionId: 1002, idTagInfo: { status: "Accepted" } } 6. CP → Charging status StatusNotification { connectorId: 1, status: "Charging" } 7. App shows "Charging started" ← triggered by StartTransaction, NOT RemoteStart Accepted

RemoteStopTransaction

To stop a remote session, the CSMS sends RemoteStopTransaction with the transactionId assigned by the CSMS in the StartTransaction response. This is the only field — unlike RemoteStart, there is no idTag or connectorId.

CSMS → CP: RemoteStopTransaction

[ 2, "rsp-001", "RemoteStopTransaction", "transactionId": 1002 ]

After responding Accepted, the Charge Point sends a regular StopTransaction with reason: "Remote". The CSMS should wait for StopTransaction before showing "Session ended" — the Accepted response means only that the command was received.

Starting with a charging profile

RemoteStartTransaction can embed a TxProfile charging profile that takes effect the moment the session starts. This lets the backend control session power without a separate SetChargingProfile command after StartTransaction.

RemoteStartTransaction with 7.4 kW power limit

[ 2, "rst-002", "RemoteStartTransaction",  "idTag": "APP-SESSION-43", "connectorId": 1, "chargingProfile":  "chargingProfileId": 10, "stackLevel": 0, "chargingProfilePurpose": "TxProfile", "chargingProfileKind": "Relative", "chargingSchedule":  "chargingRateUnit": "W", "chargingSchedulePeriod": [ "startPeriod": 0, "limit": 7400 // 7.4 kW ]
   ]

OCPP 2.0.1 differences

In OCPP 2.0.1, the messages are renamed and the payload restructured:

RemoteStartTransaction → RequestStartTransaction: uses an IdToken object (with required type field) instead of a plain idTag; targets an evseId instead of connectorId.
RemoteStopTransaction → RequestStopTransaction: same concept, payload unchanged (transactionId only).
The response adds a statusInfo object for richer rejection reasons.

Common use cases

📱 Driver app

User taps "Start charging" in the CPO app. The app calls the backend API; the backend sends RemoteStartTransaction with a session-specific idTag.

🏢 Workplace charging

IT system auto-starts sessions for registered employee vehicles when they arrive. A bay assignment system selects the target connectorId.

💰 Dynamic pricing

Backend waits for off-peak tariff window, then sends RemoteStartTransaction with an embedded TxProfile limiting to full power only during cheap hours.

🚛 Fleet management

Depot management system queues sessions overnight. At calculated start times, RemoteStartTransaction is sent with per-vehicle power limits.

Common errors

Treating RemoteStartTransaction Accepted as session started

Accepted only confirms the command was received. Show "Starting…" in the UI until StartTransaction arrives from the Charge Point — that is the real confirmation.

No timeout after Accepted

If the cable is not plugged in, the Charge Point may respond Accepted but never send StartTransaction. Implement a 60–120 s timeout in the CSMS and surface the failure to the user.

Using connectorId 0 in RemoteStartTransaction

ConnectorId 0 refers to the whole Charge Point, not a specific connector. It is not valid for RemoteStartTransaction. Use a specific connector ID ≥ 1, or omit the field to let the Charge Point choose.

idTag not pre-loaded in the Charge Point

If AllowOfflineTxForUnknownId is false and the idTag is not in the local list or authorization cache, the Charge Point will reject the session despite responding Accepted to RemoteStartTransaction. Pre-load all remote session tokens in the local list.

Rodolfo Carrillo

OCPP integration engineer and creator of OCPP Tools. All articles are verified against the official OCA specification and tested using the on-site tools.

Tool

Build a frame in seconds

Form-driven payload builder — pick fields, get a valid frame, copy to clipboard.

Open Builder →

Frequently asked questions

What is the difference between RemoteStartTransaction Accepted and the session actually starting?

RemoteStartTransaction Accepted means the Charge Point has received the command and will attempt to start a session. It does NOT mean a session has started. The actual StartTransaction message — sent when energy flow begins — is the confirmation that the session is live. Always wait for StartTransaction before showing "Charging" in your app.

Is connectorId required in RemoteStartTransaction?

No. connectorId is optional. If omitted, the Charge Point chooses an available connector itself. If specified, the session must start on that exact connector — the Charge Point can respond with Rejected if that connector is unavailable.

What happens if RemoteStartTransaction is Accepted but no StartTransaction arrives?

The CSMS should implement a timeout (typically 60–120 seconds) after receiving Accepted. If no StartTransaction arrives within that window, the CSMS should assume the session failed to start — possibly because the EV was not plugged in, or the connector was in a fault state.

Can the Charge Point reject a RemoteStopTransaction?

Yes. The Charge Point can respond with status Rejected if the transactionId does not match an active transaction on that Charge Point. This can happen if the CSMS sends the stop to the wrong unit, or if the transaction already ended locally.

What idTag should the CSMS use in RemoteStartTransaction?

The idTag should be a valid token that will pass authorization at the Charge Point. If the Charge Point uses a local authorization list, the idTag must be in that list or the Charge Point must have AllowOfflineTxForUnknownId enabled. In practice, CPO backends use a reserved "remote start" idTag pre-loaded in all Charge Points.

How does OCPP 2.0.1 rename these messages?

In OCPP 2.0.1, RemoteStartTransaction is renamed RequestStartTransaction and RemoteStopTransaction becomes RequestStopTransaction. The concept is the same but the payload is restructured to use IdToken objects and optionally attach EVSE-level targeting.

Sources & further reading

· Open Charge Alliance. (2015). Open Charge Point Protocol 1.6, Edition 2, §4.3 — RemoteStartTransaction. https://openchargealliance.org/my-oca/ocpp/
· Open Charge Alliance. (2015). Open Charge Point Protocol 1.6, Edition 2, §4.4 — RemoteStopTransaction. https://openchargealliance.org/my-oca/ocpp/
· Open Charge Alliance. (2020). Open Charge Point Protocol 2.0.1, §5 — RequestStartTransaction. https://openchargealliance.org/my-oca/ocpp/

Last technical review: May 12, 2025

Continue learning

Reference

StartTransaction & StopTransaction

Remote start triggers StartTransaction — understanding the full transaction lifecycle.

Reference

Authorization Guide

The idTag in RemoteStartTransaction follows the same authorization rules.

Advanced

Smart Charging: SetChargingProfile

RemoteStartTransaction can embed a charging profile to control session power from the start.