A ”CALLRESULT” message type (the response message) would be signalized by a ”3”, as shown

in listing 7. You will see this pattern throughout the following OCPP messages. The”19223201”
string in line 3 is the UniqueId within an OCPP messaging session. Each
”CALL” and ”CALLRESULT” message pair needs to have the same unique message ID in order to
assign a response message to a previously sent request message. That message ID increases with
each call request message.
The UniqueId is followed by the Action string, in this case it is a ”StatusNotification”
request message. Finally, an optional Payload is given at the end of a call message.

1 [
2 2,
3 ”19223201”,
4 ”StatusNotification”,
5 {
6 ”connectorId”: 1,
7 ”errorCode”: ”NoError”,
8 ”status”: ”Preparing”
9 }
10 ]
Listing 6: StatusNotification.req call message with status ”Preparing”

3. The CPO backend receives the new status notification and can use it to update status
information on a web frontend or mobile application.

4. An OCPP 1.6 JSON call result has the following syntax: [MessageTypeId, ”UniqueId”,
{Payload}]
The StatusNotification.conf has no payload fields defined. The
UniqueId field must be the exactly the same ID that was sent in the call request.

1 [
2 3,
3 ”19223201”,
4 {}
5 ]
Listing 7: StatusNotification.conf message as a call result to the previous call request. A figure
showing the entire DC charging session example is shown below [10].
17