Migration Guide 2.0.1 → 2.1 Section G

Availability Section — Migration Guide

Covers use cases G01–G05 (Availability functional block). Perspective: CSMS Developer.

9 Sections
5 Use Cases
G01 – G05

Created by tzi.app — your guide to migrating from OCPP 2.0.1 to OCPP 2.1.

1. Summary of Changes

Area Change Type Impact
G01: StatusNotificationRequest Deprecated Must add NotifyEventRequest as primary handler
G01: NotifyEventRequest Promoted Was alternative in 2.0.1, now the preferred method
G01: Use case name Renamed "Status Notification" → "Report Connector AvailabilityState"
G03/G04: Follow-up notifications Changed Follow-ups now primarily use NotifyEventRequest instead of StatusNotificationRequest
G03/G04: EVSE-level follow-up New CS now also sends EVSE-level and station-level NotifyEventRequest after availability changes
G05: Unlock failure New Lock failure can now also be reported when unlocking fails (not just locking)
Schema: statusInfo.additionalInfo Extended Max length increased: 512 → 1024 characters
Schema: EventDataType.severity New Optional severity field added (integer, minimum 0)

2. G01 — Report Connector AvailabilityState

Breaking Change: StatusNotificationRequest is now deprecated

NotifyEventRequest is now the preferred (primary) method for connector status reporting.

Behavior Comparison

2.0.1 Behavior
  • StatusNotificationRequest is the primary mechanism
  • NotifyEventRequest is an alternative ("not yet proven in the field")
2.1 Behavior
  • NotifyEventRequest is the preferred (primary) method
  • StatusNotificationRequest is deprecated — still supported but will be removed

CSMS Migration Action

  1. Implement NotifyEventRequest handler for connector status if not already done. This is now the expected path. Filter for:
Filter Criteria 
eventData[].component.name == "Connector"
eventData[].variable.name  == "AvailabilityState"
eventData[].trigger        == "Delta"
  1. Keep StatusNotificationRequest handler for backward compatibility with 2.0.1 stations, but treat it as a legacy code path.
  2. Update routing logic — both NotifyEvent and StatusNotification actions should update the same connector status records.

Use Case Rename

Version Name
2.0.1 G01 — Status Notification
2.1 G01 — Report Connector AvailabilityState

No functional impact — this is a documentation/naming change only.

3. G02 — Heartbeat

No Breaking Changes

The heartbeat flow is functionally identical between 2.0.1 and 2.1. The same messages, fields, and behavior apply.

Minor Additions in 2.1

Change Details
WebSocket ping/pong note 2.1 explicitly notes that when using JSON over WebSocket, the WebSocket ping/pong mechanism also provides liveness detection. The heartbeat's primary value becomes time synchronization.
24-hour minimum 2.1 explicitly recommends at least one heartbeat per 24 hours for clock sync (this was already in 2.0.1 as G02.FR.07 but is now emphasized differently).

CSMS Migration Action

No code changes required. Optionally refine offline detection logic to account for WebSocket-level liveness signals.

4. G03 — Change Availability EVSE/Connector

Change: Follow-up notifications default to NotifyEventRequest

2.0.1 Behavior
  • After a ChangeAvailabilityResponse, the CS sends StatusNotificationRequest for each affected connector
  • NotifyEventRequest is mentioned as an alternative
2.1 Behavior
  • CS sends NotifyEventRequest for each affected connector
  • CS also sends an EVSE-level NotifyEventRequest
  • StatusNotificationRequest is still possible but deprecated

Schema Change: statusInfo.additionalInfo max length

Version additionalInfo max length
2.0.1 512 characters
2.1 1024 characters

Removed Requirement: G03.FR.09

Req ID 2.0.1 2.1
G03.FR.09 Reserved connector stays Reserved when EV connects without matching IdToken Not listed in G03 requirements (behavior still covered by G01 state transition rules, but no longer has a dedicated FR)

CSMS Migration Action

  1. Handle EVSE-level NotifyEventRequest — after a ChangeAvailabilityRequest response, expect both Connector-level and EVSE-level NotifyEventRequest messages. Update your handler to also check for:
EVSE-Level Filter 
eventData[].component.name == "EVSE"
eventData[].variable.name  == "AvailabilityState"
  1. Update statusInfo.additionalInfo validation — increase max accepted length from 512 to 1024 characters if you validate this field.

5. G04 — Change Availability Charging Station

Change: Follow-up notifications default to NotifyEventRequest

2.0.1 Behavior
  • After a station-level ChangeAvailabilityResponse, the CS sends StatusNotificationRequest for each connector on each EVSE
2.1 Behavior
  • CS sends NotifyEventRequest for each connector on each EVSE
  • CS also sends a station-level NotifyEventRequest

CSMS Migration Action

  1. Handle station-level NotifyEventRequest — in addition to per-connector notifications, expect a ChargingStation-level event:
Station-Level Filter 
eventData[].component.name == "ChargingStation"
eventData[].variable.name  == "AvailabilityState"
  1. Update internal state model — track station-level operationalStatus separately, as 2.1 makes the hierarchy more explicit:
State Hierarchy 
ChargingStation (operationalStatus)
 └── EVSE (operationalStatus)
      └── Connector (operationalStatus + connectorStatus)

6. G05 — Lock Failure

Minor Addition: Unlock failure scenario

2.0.1 Behavior

Lock failure is reported when the connector retention lock fails to engage (lock attempt fails before charging starts).

2.1 Behavior

Lock failure can also be reported when unlocking fails (in addition to locking failure).

CSMS Migration Action

  1. Update lock failure handler — when processing ConnectorPlugRetentionLock / Problem / true events, consider that the failure may be an unlock failure (not just a lock failure). This may affect operator notifications and maintenance workflows.
  2. No message format changes — the same NotifyEventRequest structure is used.

7. Schema Changes Summary

EventDataType — New severity field

Added in 2.1: This field may appear in any NotifyEventRequest event data entry. The CSMS should accept and optionally store/process this field.

Field Type Required Description
severity integer (minimum 0) No Severity level of the event

StatusInfoType — additionalInfo max length increase

Field 2.0.1 2.1
additionalInfo max 512 chars max 1024 chars

Update any validation or database column size constraints.

StatusNotificationRequest — Deprecated

Version Status
2.0.1 Primary message for connector status reporting
2.1 Deprecated Still supported, will be removed in a future release

8. Message Routing Changes

2.0.1 Routing
Inbound Action Primary Handler
StatusNotification G01 (primary)
NotifyEvent G01 (alternative) / G05
Heartbeat G02
2.1 Routing
Inbound Action Primary Handler
NotifyEvent G01 (primary) / G05 (check component.name)
StatusNotification G01 (deprecated fallback)
Heartbeat G02

9. Migration Checklist

Must Do Required

G01

Implement NotifyEventRequest as the primary handler for connector status changes if not already done

G03

Handle EVSE-level NotifyEventRequest follow-ups after ChangeAvailabilityRequest

G04

Handle ChargingStation-level NotifyEventRequest follow-ups after station-wide ChangeAvailabilityRequest

Schema

Update statusInfo.additionalInfo max length validation from 512 → 1024 characters

Schema

Accept the new severity field in EventDataType without rejecting the message

Should Do Recommended

G01

Keep StatusNotificationRequest handler for backward compatibility with 2.0.1 stations

G05

Update lock failure handling to account for unlock failures

G04

Track station-level and EVSE-level operationalStatus separately in your data model

Optional Nice to Have

Log/store the severity field from NotifyEventRequest events for operational insights

Add deprecation warnings in logs when receiving StatusNotificationRequest from 2.1 stations

OCPP 2.1 Availability Section Migration Guide — Use Cases G01–G05 — CSMS Developer Perspective