Remote management encompasses all of the actions that can be taken by an operator remotely from the CSMS. These are vital for diagnosing and fixing issues without having to physically go to the station in question. They are also commonly used as the interaction point with external apps. For example an external payment app authorizing a driver to start charging may trigger an OCPI start transaction request which, if accepted by the CSMS, would trigger a RemoteStartTransactionRequest.
This article covers all of the remote actions available in OCPP 2.0.1. Some actions are best covered in other articles and those are linked at the bottom.
Allows the operator to authorize a driver to start charging remotely, and also de-authorize the transaction and instruct the charger to stop charging.
The RemoteStartTransactionRequest can be thought of as an authorization of the driver via the CSMS instead of the station. Some examples of when this would be used are;
Used to remotely disable a station, EVSE, or connector and prevent it from being used. This can be used for example before scheduled maintenance to ensure the station won’t be in use when access is needed. If the station accepts the request it must make the change locally then send StatusNotification messages for each affected connector with the status Unavailable.
If the connector doesn’t automatically unlock at the end of a charging session, this request can be used to force the station to unlock it again.
This is used to request the station to send a particular request to the CSMS. This is useful in a few scenarios but generally it is needed when the CSMS needs some information from the station and must encourage it to send it.
For example, when firmware is updating the charger will send FirmwareStatusNotifications updating the CSMS on the progress of the update. If this doesn’t happen correctly or the CSMS misses some message it can send a TriggerMessage to ask for the latest FirmwareStatusNotification to be sent again.
Set Network Profile - described in Security
Set Variables - described in Device Model
Get Variables - described in Device Model
Get Base Report - described in Device Model
Update Firmware - described in Firmware
Get Log - described in Logs
Install Certificates - described in Certificates
Get Installed Certificate IDs - described in Certificates
Get Transaction Status - described in Transactions
The OCPP protocol exhibits a degree of synchronicity in its communication, with each request expecting a matching response and the CSMS side discouraged from sending new requests until previous ones have had a response or timed out. However OCPP applications, particularly on the CS side, can act asynchronously and it can be important for CSMS users to be made aware of these distinctions. For example when a RemoteStartTransactionRequest is sent there is no guarantee of the transaction starting, the CSMS should wait for the RemoteStartTransactionResponse and subsequent TransactionEventRequest before displaying any success message to the user, even though the transaction in some cases will have started immediately on the reception of the RemoteStartTransactionRequest.