Deep dive · In the raw · optional

One session as raw OCPP messages

About 12 min · 3 questions ·

Tuesday
The situation

The same session as in stops 04 and 05, this time as the backend logged it: every message between the charger and the backend, in the JSON that OCPP 1.6 sends over the WebSocket.

Nothing is simplified. Only the meter values between the second and the twenty-fifth minute are left out.

The questionCan you read the session from the raw messages alone: who sent what, when, and what it meant?

Guess firstThe display in the car park showed 9:12 AM when the card was tapped. What time does the first message carry?RevealHide

07:12 and a few seconds, with a Z at the end. OCPP timestamps are in UTC; the charger stands in Central European Summer Time, two hours ahead. Every tool that shows a log converts the times back.

What you are looking at

1.6 over JSON sends every message as a short array on the connection the charger opened at 6:00 AM (stop 02). The first element says what kind of message it is: 2 for a call, 3 for the result that answers it, 4 for an error. The second element is an id that ties call and result together, then comes the name of the action and its payload.

The log below was recorded by the backend. Lines sent by the charger start with 2 and name an action; lines sent by the backend in reply start with 3 and repeat the id. Select the numbered lines to read them like a support engineer.

OCPP 1.6J, connector 1, as logged by the backendThe session, message by message

Timestamps are UTC. The register values in watt-hours are the same ones the plot in stop 05 shows as energy added.

  2. Line 1The cable is in

    A call from the charger: 2 means request, 7a01 is its id, StatusNotification the action. Connector 1 reports Preparing: a car is plugged in and nobody has authorised yet. The timestamp is UTC; the display shows 9:11 AM, two hours ahead.

  9. [3,"7a04",{}]
  11. [3,"7a05",{}]
  13. [3,"7a06",{}]
  14. … further MeterValues calls, one per minute, and their results are left out …
  16. [3,"7a1d",{}]
  17. [2,"7a20","MeterValues",{"connectorId":1,"transactionId":48213,"meterValue":[{"timestamp":"2026-10-06T07:39:09Z","sampledValue":[{"value":"1263450","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","unit":"Wh"},{"value":"55.1","context":"Sample.Periodic","measurand":"Power.Active.Import","unit":"kW"},{"value":"91","context":"Sample.Periodic","measurand":"SoC","unit":"Percent"}]}]}]
  18. [3,"7a20",{}]
  22. [3,"7a22",{}]
  24. [3,"7a23",{}]
session-48213.log: the whole file, to copy
[2,"7a01","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Preparing","timestamp":"2026-10-06T07:11:58Z"}]
[3,"7a01",{}]
[2,"7a02","Authorize",{"idTag":"04A2B3C4D5E680"}]
[3,"7a02",{"idTagInfo":{"status":"Accepted","expiryDate":"2026-10-07T07:12:04Z"}}]
[2,"7a03","StartTransaction",{"connectorId":1,"idTag":"04A2B3C4D5E680","meterStart":1204330,"timestamp":"2026-10-06T07:12:09Z"}]
[3,"7a03",{"transactionId":48213,"idTagInfo":{"status":"Accepted"}}]
[2,"7a04","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Charging","timestamp":"2026-10-06T07:12:11Z"}]
[3,"7a04",{}]
[2,"7a05","MeterValues",{"connectorId":1,"transactionId":48213,"meterValue":[{"timestamp":"2026-10-06T07:13:09Z","sampledValue":[{"value":"1205190","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","unit":"Wh"},{"value":"78.6","context":"Sample.Periodic","measurand":"Power.Active.Import","unit":"kW"},{"value":"13","context":"Sample.Periodic","measurand":"SoC","unit":"Percent"}]}]}]
[3,"7a05",{}]
[2,"7a06","MeterValues",{"connectorId":1,"transactionId":48213,"meterValue":[{"timestamp":"2026-10-06T07:14:09Z","sampledValue":[{"value":"1206930","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","unit":"Wh"},{"value":"140.2","context":"Sample.Periodic","measurand":"Power.Active.Import","unit":"kW"},{"value":"15","context":"Sample.Periodic","measurand":"SoC","unit":"Percent"}]}]}]
[3,"7a06",{}]
[2,"7a1d","MeterValues",{"connectorId":1,"transactionId":48213,"meterValue":[{"timestamp":"2026-10-06T07:37:09Z","sampledValue":[{"value":"1261330","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","unit":"Wh"},{"value":"69.5","context":"Sample.Periodic","measurand":"Power.Active.Import","unit":"kW"},{"value":"88","context":"Sample.Periodic","measurand":"SoC","unit":"Percent"}]}]}]
[3,"7a1d",{}]
[2,"7a20","MeterValues",{"connectorId":1,"transactionId":48213,"meterValue":[{"timestamp":"2026-10-06T07:39:09Z","sampledValue":[{"value":"1263450","context":"Sample.Periodic","measurand":"Energy.Active.Import.Register","unit":"Wh"},{"value":"55.1","context":"Sample.Periodic","measurand":"Power.Active.Import","unit":"kW"},{"value":"91","context":"Sample.Periodic","measurand":"SoC","unit":"Percent"}]}]}]
[3,"7a20",{}]
[2,"7a21","StopTransaction",{"transactionId":48213,"idTag":"04A2B3C4D5E680","meterStop":1264430,"timestamp":"2026-10-06T07:40:11Z","reason":"Local"}]
[3,"7a21",{"idTagInfo":{"status":"Accepted"}}]
[2,"7a22","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Finishing","timestamp":"2026-10-06T07:40:12Z"}]
[3,"7a22",{}]
[2,"7a23","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Available","timestamp":"2026-10-06T07:40:41Z"}]
[3,"7a23",{}]
[2,"7a24","Heartbeat",{}]
[3,"7a24",{"currentTime":"2026-10-06T07:45:41Z"}]

A composed log in the message format of OCPP 1.6 over JSON. The register values match the composed session of stop 05; the card identifier reappears in the OCPI deep dive as the token that started the session. The format of the messages, the transaction ID assigned by the backend, the heartbeat rule and the clock set from the backend's answers are those of the OCPP 1.6 specification.

From two readingsThe session in four numbers
meterStart1,204,330Wh

the register at 07:12:09 UTC

meterStop1,264,430Wh

the register at 07:40:11 UTC

Energy60.1kWh

the difference, what the CDR will state

Duration28:02min

from the first to the last reading

Computed from the log. Where measuring law requires it, the two readings travel signed, and the signature can be checked against the meter's public key.

How to read a line

Four habits make a log readable:

  • Direction. A 2 with an action name is a call; in a log from the backend, calls that name Authorize, StartTransaction, MeterValues, StopTransaction, StatusNotification or Heartbeat come from the charger. Calls from the backend would name RemoteStartTransaction, Reset or SetChargingProfile (stop 06).
  • Pairs. Every call has a result with the same id. A call without a result is the first thing to look for when something hangs.
  • Time. Timestamps are UTC and end in Z. The charger's clock is set from the backend's answers, so gaps and order are reliable.
  • Energy. The register counts up for the life of the meter. Energy is always a difference between two readings; the power values are a courtesy for the app.

What the log does not contain

No price, no name, no contract. The log knows a card identifier, a connector, readings and times. The tariff, the driver's contract and the invoice live in other systems: the backend turns these messages into a , and the provider prices it, see the OCPI deep dive. The transaction ID, the message that changed most between OCPP 1.6 and 2.0.1, is the thread that holds the record together.

Check your understanding

3 questions. Answer all of them to complete this stop. Each answer explains itself.

01Question 1 of 3

A line in the log begins with 3 and carries the same id as the line before it. What is it?

02Question 2 of 3

meterStart was 1204330 and meterStop 1264430. What did the session deliver?

03Question 3 of 3

Who chose the number 48213 that every later message of the session carries?

Further in other paths

  1. OCPI and roaming · Deep diveOne CDR, field by fieldThe charge detail record of the 3:41 PM session as the Austrian operator sent it to the German provider: every field of the OCPI 2.3.0 record, read line by line, and the credit record that would cancel it.
  2. Payments and billing · Stop 06Why must the kilowatt-hours be measured to legal standards?From the meter to the invoice: accuracy classes, signed readings and what drivers can check, under the EU rules that apply from 2028.
  1. Open Charge Alliance: Open Charge Point Protocol (OCPP): versions 1.6, 2.0.1 and 2.1. https://openchargealliance.org/protocols/open-charge-point-protocol/. Checked 09 Oct 2026.
  2. Open Charge Alliance: Open Charge Point Protocol (OCPP): versions 1.6, 2.0.1 and 2.1. https://openchargealliance.org/protocols/open-charge-point-protocol/. Checked 09 Oct 2026.
  3. Open Charge Alliance: OCPP 1.6 edition 2 (2017): message format over JSON, Heartbeat, StartTransaction and Smart Charging; free download. https://openchargealliance.org/download-ocpp/. Checked 11 Oct 2026.
  4. Open Charge Alliance: Signed Meter Values (Eichrecht paper), version 1.0, February 2025. https://openchargealliance.org/wp-content/uploads/2025/05/signed_meter_values-v10-1.pdf. Checked 09 Oct 2026. Licence: CC BY-ND 4.0.
  5. Open Charge Alliance: What is new in OCPP 2.0.1? Whitepaper, version 1.0, March 2023. https://openchargealliance.org/wp-content/uploads/2024/01/new_in_ocpp_201-v10.pdf. Checked 09 Oct 2026. Licence: CC BY-ND 4.0.
Was this helpful?