Trigger Message

Source: OCPP 1.6 Specification — Section 5.17 (Operation), Sections 6.51 / 6.52 (Messages)

Overview

During normal operation, the Charge Point informs the Central System of its state and any relevant occurrences. If there is nothing to report the Charge Point will send at least a heartbeat at a predefined interval. Under normal circumstances this is just fine, but what if the Central System has reason to doubt the last known state? What can a Central System do if a firmware update is in progress and the last status notification it received about it was much longer ago than could reasonably be expected? The same can be asked for the progress of a diagnostics request. The problem in these situations is not that the information needed isn't covered by existing messages, the problem is strictly a timing issue. The Charge Point has the information, but has no way of knowing that the Central System would like an update.

The TriggerMessage.req makes it possible for the Central System to request the Charge Point to send Charge Point-initiated messages. In the request the Central System indicates which message it wishes to receive. For every such requested message the Central System MAY optionally indicate to which connector this request applies. The requested message is leading: if the specified connectorId is not relevant to the message, it should be ignored. In such cases the requested message should still be sent.

Inversely, if the connectorId is relevant but absent, this should be interpreted as "for all allowed connectorId values". For example, a request for a StatusNotification for connectorId 0 is a request for the status of the Charge Point. A request for a StatusNotification without connectorId is a request for multiple StatusNotifications: the notification for the Charge Point itself and a notification for each of its connectors.

The Charge Point SHALL first send the TriggerMessage response, before sending the requested message. In the TriggerMessage.conf the Charge Point SHALL indicate whether it will send it or not, by returning Accepted or Rejected. It is up to the Charge Point if it accepts or rejects the request to send. If the requested message is unknown or not implemented the Charge Point SHALL return NotImplemented.

Messages that the Charge Point marks as accepted SHOULD be sent. The situation could occur that, between accepting the request and actually sending the requested message, that same message gets sent because of normal operations. In such cases the message just sent MAY be considered as complying with the request.

The TriggerMessage mechanism is not intended to retrieve historic data. The messages it triggers should only give current information. A MeterValues message triggered in this way for instance SHOULD return the most recent measurements for all measurands configured in configuration key MeterValuesSampledData. StartTransaction and StopTransaction have been left out of this mechanism because they are not state related, but by their nature describe a transition.

Sequence Diagram

Figure 38. Sequence Diagram: Trigger Message

Central System  ──── TriggerMessage.req ────▶  Charge Point
                     (requestedMessage, connectorId?)
Central System  ◀─── TriggerMessage.conf ────  Charge Point
                     (status)
                ◀─── <triggered message>.req

Initiator

Central System → Charge Point

Fields

MessageTrigger values

• BootNotification
• DiagnosticsStatusNotification
• FirmwareStatusNotification
• Heartbeat
• MeterValues
• StatusNotification

TriggerMessageStatus values

• Accepted — Requested notification will be sent.
• Rejected — Requested notification will not be sent.
• NotImplemented — Requested notification cannot be sent because it is either not implemented or unknown.

Examples

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

{
  "status": "Accepted"
}

Schema

Source: schemas/TriggerMessage.json, schemas/TriggerMessageResponse.json (OCPP 1.6, JSON Schema draft-04)