How to test RemoteStartTransaction (OCPP 1.6J)

RemoteStartTransaction is the CSMS asking the charger to start — usually because a driver hit Start in an app. The charger answers Accepted or Rejected, then sends the same StartTransaction it would send after a card tap.

The charger opens the WebSocket, so the CSMS can still push RemoteStart through NAT. Spec: OCPP 1.6 download. If the start arrived from another roaming network first, that hop is OCPI START_SESSION.

When RemoteStartTransaction is triggered

• A driver taps Start in a mobile app that talks to your CSMS.
• An operator starts a connector from the control room.
• A QA job or API script exercises the remote-start path.

The charger should already be connected, Accepted, and the target connector should normally be Available. If the connector is Faulted, Unavailable, or already Charging, expect Rejected.

RemoteStartTransaction sample message

JSON[
  2,
  "csms-rs-01",
  "RemoteStartTransaction",
  {
    "connectorId": 1,
    "idTag": "TAG-1001"
  }
]

JSON[
  3,
  "csms-rs-01",
  {
    "status": "Accepted"
  }
]

connectorId is optional in the schema; if the CSMS omits it, the charger picks a free connector. In tests, send it explicitly so both sides agree which plug started.

After Accepted, a healthy charger continues with the normal session story:

RemoteStartTransaction → Accepted
→ (optional) Authorize for the same idTag
→ StartTransaction → transactionId
→ StatusNotification Charging
→ MeterValues…

If you only see the RemoteStart pair and nothing else, the CSMS accepted the command but the station never began energy. That is a different bug from “the CSMS never sent RemoteStart.”

When RemoteStopTransaction is triggered

• The driver taps Stop in the app.
• An operator ends a runaway or forgotten session.
• A policy stops the session (time cap, payment failure, safety).

RemoteStopTransaction sample message

JSON[
  2,
  "csms-rst-01",
  "RemoteStopTransaction",
  {
    "transactionId": 1001
  }
]

JSON[
  3,
  "csms-rst-01",
  {
    "status": "Accepted"
  }
]

JSON[
  2,
  "a7k2-stop-01",
  "StopTransaction",
  {
    "transactionId": 1001,
    "meterStop": 5550,
    "timestamp": "2026-08-14T10:22:18.000Z",
    "reason": "Remote"
  }
]

Stopping by transactionId — not by connector — is the 1.6 contract. If your CSMS sends the wrong ID, the charger should Rejected and leave the session running.

How to test this without hardware

1. Launch the OCPP 1.6 simulator and connect your CSMS.
2. Confirm BootNotification is Accepted and connector 1 is Available.
3. From the CSMS, send RemoteStartTransaction with a known idTag.
4. In the Chargeflux console, correlate the CALL / CALLRESULT by unique ID, then look for StartTransaction and MeterValues.
5. Send RemoteStopTransaction with the transactionId your CSMS assigned.
6. Confirm StopTransaction reason is Remote and status returns to Available.

Compare this path with a local start from the UI. Authorization and remote-start code often diverge in CSMS products — that is the whole reason to test both. See test CSMS without hardware.

Rejected cases worth automating

• RemoteStart on a Faulted or Unavailable connector.
• RemoteStart while a transaction is already active.
• RemoteStop with an unknown transactionId.
• RemoteStart before BootNotification is Accepted.

Chargeflux returns framed Accepted / Rejected replies for these commands so your CSMS sees real OCPP-J, not a mocked HTTP 200.

Related

• OCPP 1.6J sample messages — Every core message, when it fires, and a full session sample.
• BootNotification — The charger introduces itself. Heartbeat keeps the line alive.
• Connector status — StatusNotification and the nine connector states in plain language.
• Charging session messages — Authorize, StartTransaction, MeterValues, and StopTransaction.

• 2.0.1 RequestStartTransaction
• OCPI START_SESSION
• Launch simulator

• OCPP 1.6 simulator — supported incoming commands
• API — drive the same path from CI

FAQ

Last reviewed August 2026 · Chargeflux.io