Remote commands¶
The API offers its users to trigger certain ocpp requests to the station. This requests can be found within the section Remote Command in the api. Those requests will propagate the requests in the OCPP version of the station to the station. In case you want to see the resulting OCPP requests, you can consult the communication log detail page, where you should see the according requests.
The API abstracts the fact that those calls happen often asynchronous. For all stations which are connected with the OCPP Broker we can provide a response with the response data of the OCPP responses. For stations which are connected via the legacy websockets, we cannot offer this functionality. This results in certain response object be not filled in (e.g. a GetConfigurationResponse will not contain any configuration values received).
As we offer an abstraction on the remote requests, where we handle potential asynchronicity, we run in potential long running requests. To safe the system for too much concurrent remote requests, we limit those endpoints with a counter. Currently you can run 10 requests in parallel. The counter will be reduced everytime the response was generated.
Synchronous¶
GetConfiguration¶
The GetConfiguration requests can be triggered with the endpoint /remote_commands/synchronous/{cpId}/get_configuration. This request can either contain no keys, which will result in all keys offered by the station or you can provide certain keys which needs to be fetched by the station. All the configuration keys received are also stored, in the databases of be.ENERGISED. In case you have to deal with, legacy websocket stations, you can also use the configuration fetch endpoint to retrieve those values. It is recommended to wait at least a few seconds after you fetch the data from this endpoint. Keys which are not known by the station, will be reported back by the unknownKeys property in the response.
Change Configuration¶
The ChangeConfiguration requests can be triggered with the endpoint /remote_commands/synchronous/{cpId}/change_configurations. This request can set one to many keys, where each key will result in one ChangeConfiguration OCPP request. In case you have to deal with, legacy websocket stations, you will not receive the OCPP response status values.
Reset¶
The Reset requests can be triggered with the endpoint /remote_commands/synchronous/{cpId}/reset. This request will trigger a ResetRequest in OCPP. This request, ask for a type as parameter which can be either Hard (a hard reset usually implemented as a full reboot on the station) or a soft reset (which usually only restarts certain parts on the station).
UnlockConnector¶
The UnlockConnector POST request can be triggered with the endpoint /remote_commands/synchronous/{cpId}/unlock_connector/{cpConnectorUuid}. This request will trigger a UnlockConnectorRequest in OCPP.
Asynchronous¶
RemoteStartAttempt¶
The RemoteStartAttempt POST request can be triggered with the endpoint /remote_commands/asynchronous/remote_start_attempt. This request will trigger a RemoteStartAttemptRequest.
If validUntil is not set it is automatically set to now +10 minutes.
stopMinutes are not affecting the validUntil time. It only shows after which time(in minutes) a remote stop is triggered from the system.
RemoteStartAttempt will not work if the connector or the station is permanently locked.
The RemoteStartAttempt GET request can be triggered with the endpoint /remote_commands/asynchronous/remote_start_attempt/<RemoteStartAttemptId>. This request will show the information of a RemoteStartAttempt.
RemoteStop¶
The RemoteStop POST request can be triggered with the endpoint /remote_commands/asynchronous/remote_stop.
ClearCache¶
The ClearCache POST request can be triggered with the endpoint /remote_commands/asynchronous/{cpId}/clear_cache. This request will trigger a ClearCacheRequest in OCPP.
You can use the GET request in order to see the status /remote_commands/asynchronous/{cpId}>/clear_cache/status/{referenceId}.