TransactionEvent

Core CS->CSMS OCPP 2.0.1

Reports transaction lifecycle events to the CSMS. Replaces StartTransaction and StopTransaction from OCPP 1.6J with a unified event-based model using Started, Updated, and Ended event types.

Quick Reference

Required Fields

eventType TransactionEventEnumType

Started (first event), Updated (during transaction), or Ended (last event)

timestamp string (date-time)

Date and time at which this event occurred

triggerReason TriggerReasonEnumType

Reason for sending this event (Authorized, CablePluggedIn, ChargingStateChanged, RemoteStart, etc.)

seqNo integer

Incremental sequence number starting at 0 for Started, incremented for each subsequent event

transactionInfo TransactionType

Object with transactionId (string, max 36) and optional chargingState, stoppedReason

transactionInfo.transactionId string(36)

Unique identifier for this transaction, assigned by the Charging Station

Optional Fields

meterValue array[MeterValueType]

Meter readings at the time of this event

offline boolean

True if this event occurred while the Charging Station was offline (default: false)

numberOfPhasesUsed integer

Number of phases used during charging

cableMaxCurrent integer

Maximum current of the connected cable in Ampere

reservationId integer

ID of the reservation that this transaction fulfills

evse EVSEType

EVSE identifier (id + optional connectorId)

idToken IdTokenType

Identifier used to start or stop the transaction

transactionInfo.chargingState ChargingStateEnumType

Current charging state: Charging, EVConnected, SuspendedEV, SuspendedEVSE, or Idle

transactionInfo.stoppedReason ReasonEnumType

Reason for stopping (only on Ended): Local, Remote, EVDisconnected, PowerLoss, etc.

Example Payload

{
  "eventType": "Started",
  "timestamp": "2024-01-15T10:30:00Z",
  "triggerReason": "Authorized",
  "seqNo": 0,
  "transactionInfo": {
    "transactionId": "txn-abc123",
    "chargingState": "Charging"
  },
  "idToken": {
    "idToken": "AABBCCDD",
    "type": "ISO14443"
  },
  "evse": {
    "id": 1,
    "connectorId": 1
  },
  "meterValue": [
    {
      "timestamp": "2024-01-15T10:30:00Z",
      "sampledValue": [
        {
          "value": 15200,
          "measurand": "Energy.Active.Import.Register",
          "unitOfMeasure": {
            "unit": "Wh"
          }
        }
      ]
    }
  ]
}

Example Full Frame

[
  2,
  "msg-001",
  "TransactionEvent",
  {
    "eventType": "Started",
    "timestamp": "2024-01-15T10:30:00Z",
    "triggerReason": "Authorized",
    "seqNo": 0,
    "transactionInfo": {
      "transactionId": "txn-abc123",
      "chargingState": "Charging"
    },
    "idToken": {
      "idToken": "AABBCCDD",
      "type": "ISO14443"
    },
    "evse": {
      "id": 1,
      "connectorId": 1
    },
    "meterValue": [
      {
        "timestamp": "2024-01-15T10:30:00Z",
        "sampledValue": [
          {
            "value": 15200,
            "measurand": "Energy.Active.Import.Register",
            "unitOfMeasure": {
              "unit": "Wh"
            }
          }
        ]
      }
    ]
  }
]

Format: [MessageType, MessageId, Action, Payload]

Open in Builder Go to Validator

Overview

TransactionEvent is one of the most significant changes in OCPP 2.0.1. It replaces the separate StartTransaction and StopTransaction messages from 1.6J with a unified event model. A transaction is described by a sequence of events: Started, zero or more Updated, and finally Ended.

When to Send

  • Started: When a transaction begins (after authorization accepted, cable connected, etc.)
  • Updated: When the charging state changes, meter values are reported, or any significant transaction event occurs
  • Ended: When the transaction stops for any reason

Expected Response

The CSMS responds with:

  • idTokenInfo (optional): Authorization result if the Charging Station requests it
  • updatedPersonalMessage (optional): Display message for the user

Key Differences from OCPP 1.6J

This message replaces both StartTransaction and StopTransaction:

OCPP 1.6JOCPP 2.0.1
StartTransactionTransactionEvent { eventType: "Started" }
StopTransactionTransactionEvent { eventType: "Ended" }
CSMS assigns transactionId (integer)Charging Station assigns transactionId (string, max 36)
idTag is a plain stringidToken is an object with idToken + type
Meter values in start/stop payloadmeterValue array in the event

Usage Notes

  • The Charging Station generates the transactionId — not the CSMS. Use a UUID or similar unique string.
  • seqNo starts at 0 for Started and must be monotonically incremented
  • The offline flag allows queuing events when disconnected and sending them later
  • meterValue in the Started event typically contains the start meter reading
  • meterValue in the Ended event contains the final meter reading

Best Practices

  1. Generate UUID for transactionId — Use a UUID v4 to avoid collisions across stations
  2. Include meterValues — Send meter readings in Started and Ended events for accurate billing
  3. Send Updated on state changes — Send an Updated event when chargingState changes (e.g., EVConnected → Charging)
  4. Queue offline events — If disconnected, queue events with offline: true and send when reconnected
  5. Always send Ended — Ensure the Ended event is sent even on error, power loss recovery, or forced stop

Testing Tips

  • Test the full sequence: Started (seqNo=0) → Updated (seqNo=1) → Ended (seqNo=2)
  • Test stoppedReason values: Local, Remote, EVDisconnected, PowerLoss
  • Test offline queuing and delivery on reconnect
  • Verify the Charging Station does NOT expect the CSMS to send back a transactionId

Common Errors

TypeConstraintViolation

Cause: seqNo is not incremented correctly

Solution: seqNo must start at 0 for Started and increment by 1 for each subsequent event in the same transaction

TypeConstraintViolation

Cause: transactionId is an integer instead of a string

Solution: In OCPP 2.0.1, transactionId is a string (max 36 chars). The CSMS no longer assigns it - the Charging Station generates it

PropertyConstraintViolation

Cause: eventType is Started but no idToken or evse provided

Solution: For Started events, include idToken and evse to identify the user and connector

TypeConstraintViolation

Cause: stoppedReason provided on a Started event

Solution: stoppedReason is only relevant on Ended events

Related Actions

Authorize MeterValues RequestStartTransaction RequestStopTransaction StatusNotification