Remote Control Section — Migration Guide

High-Level Overview

In OCPP 2.0.1, connector state changes in remote control flows used StatusNotificationRequest. In OCPP 2.1, these are replaced by NotifyEventRequest.

Affected Use Cases

Message Format Comparison

OCPP 2.0.1 — StatusNotificationRequest:

{
  "timestamp": "2025-06-15T14:30:05.000Z",
  "connectorStatus": "Occupied",
  "evseId": 1,
  "connectorId": 1
}

OCPP 2.1 — NotifyEventRequest (replacement):

{
  "generatedAt": "2025-06-15T14:30:05.000Z",
  "seqNo": 0,
  "eventData": [
    {
      "eventId": 1,
      "timestamp": "2025-06-15T14:30:05.000Z",
      "trigger": "Delta",
      "actualValue": "Occupied",
      "eventNotificationType": "HardWiredNotification",
      "component": {
        "name": "Connector",
        "evse": { "id": 1, "connectorId": 1 }
      },
      "variable": {
        "name": "AvailabilityState"
      }
    }
  ]
}

CSMS Migration Action

3.1 IdTokenType

3.2 StatusInfoType

3.3 EVSEType

3.4 TransactionEventResponse (CSMS → CS)

New fields added in 2.1:

TransactionLimitType (new in 2.1):

{
  "maxCost": 50.00,
  "maxEnergy": 30000,
  "maxTime": 7200,
  "maxSoC": 80
}

3.5 TransactionType (inside TransactionEventRequest)

New fields added in 2.1:

3.6 TransactionEventRequest (CS → CSMS)

New top-level fields added in 2.1:

3.7 ReasonEnumType (stoppedReason) — New Values

3.8 ChargingProfileType / ChargingSchedulePeriod

4.1 F01 — Remote Start Transaction: Cable Plugin First

4.2 F02 — Remote Start Transaction: Remote Start First

4.3 F03 — Remote Stop Transaction Changed

TxStopPoint behavior (new in 2.1 documentation)

4.4 F04 — Remote Stop ISO 15118 Charging from CSMS

4.5 F05 — Remotely Unlock Connector Changed

4.6 F06 — Trigger Message Extended

MessageTriggerEnumType — Full Comparison

Overview

F07 is a new use case in OCPP 2.1 that enables the CSMS to set transaction limits (cost, energy, SoC, or time) during a remote start. When a limit is reached, the CS automatically suspends energy transfer.

Use cases: Prepaid balance, ad-hoc payment reservation amounts, energy/time-limited sessions.

Mechanism

Flow

1. CSMS sends RequestStartTransactionRequest (identical to F01/F02)
2. CS sends TransactionEventRequest with eventType=Started
3. CSMS responds with TransactionEventResponse that includes transactionLimit
4. CS echoes back the limit in the next TransactionEventRequest via transactionInfo.transactionLimit (confirming receipt)
5. When limit is reached, CS sends TransactionEventRequest with chargingState=SuspendedEVSE

TransactionLimit in TransactionEventResponse

{
  "transactionLimit": {
    "maxCost": 25.00,
    "maxEnergy": 20000,
    "maxTime": 3600,
    "maxSoC": 80
  }
}

Rules

• At least one limit should be provided
• If multiple limits are given, whichever is reached first stops energy transfer
• The CS echoes back the limits in transactionInfo.transactionLimit to confirm receipt

New stoppedReason Values for F07

When a transaction ends because a limit was reached, the stoppedReason in TransactionEventRequest will use one of these new values:

Implementation Requirements

• Add transactionLimit field support to your TransactionEventResponse builder
• Track which transactions have limits and verify the CS echoes them back
• Handle the new stoppedReason values (EnergyLimitReached, TimeLimitReached, SOCLimitReached, LocalOutOfCredit)
• Handle chargingState=SuspendedEVSE as an indicator that a limit was reached

Message Handler Updates Breaking / Behavioral

Schema Validation Updates Validation

New Fields to Support New

New Enum Values Enum

New Use Case Implementation F07

Behavioral Changes Behavioral