Trigger Message

Source: OCPP 2.0.1 Part 2 — Specification (Edition 2, 2022-12-15) — Section 1.61 (Messages); Use Case F06 — Trigger Message (Functional Block F. RemoteControl)

Overview

The CSMS sends TriggerMessageRequest to ask the Charging Station to send a CS-initiated message on demand — typically used when the CSMS suspects its view of the CS state is stale (e.g. firmware update progress, status notification).

The Charging Station first responds with TriggerMessageResponse (Accepted/Rejected/NotImplemented), then sends the requested message if Accepted. If a normally-scheduled message of the requested type is sent in the meantime, it MAY be considered as fulfilling the request.

In OCPP 2.0.1 the trigger mechanism is unified — there is no separate ExtendedTriggerMessage like in 1.6 security.

Sequence Diagram

CSMS  ──── TriggerMessageRequest ────▶  Charging Station
            (requestedMessage, evse?)
CSMS  ◀─── TriggerMessageResponse ────  Charging Station
            (status, statusInfo?)
        ◀─── <triggered message>Request ────  Charging Station

Initiator

CSMS → Charging Station

Fields

MessageTriggerEnumType values

BootNotification, LogStatusNotification, FirmwareStatusNotification, Heartbeat, MeterValues, SignChargingStationCertificate (triggers SignCertificate for the CS certificate), SignV2GCertificate (triggers SignCertificate for V2G), StatusNotification, TransactionEvent, SignCombinedCertificate, PublishFirmwareStatusNotification.

TriggerMessageStatusEnumType values

Accepted, Rejected, NotImplemented.

Examples

{
  "requestedMessage": "StatusNotification",
  "evse": { "id": 1, "connectorId": 1 }
}

{
  "status": "Accepted"
}

Schema

Source: schemas/TriggerMessageRequest.json, schemas/TriggerMessageResponse.json (OCPP 2.0.1 FINAL)