Chargeflux.io

OCPP 1.6J charging session messages

A 1.6J session is four charger-originated messages: Authorize, StartTransaction, MeterValues, and StopTransaction. StatusNotification rides alongside so the map stays current.

The CSMS assigns transactionId on the StartTransaction reply. Later MeterValues and StopTransaction must repeat that ID or billing cannot join the samples. Field lists: OCPP 1.6 spec. App-started sessions: RemoteStartTransaction. Index: 1.6J samples.

The four session messages at a glance

MessageWhen it is triggered
AuthorizeDriver presents an RFID card, app token, or other idTag
StartTransactionThe charger begins a session on a connector after it is allowed to start
MeterValuesPeriodic energy (and sometimes power, current, voltage, SoC) during the session
StopTransactionThe session ends — local stop, remote stop, unplug, fault, or reset

Authorize sample

May this card charge here? The CSMS answers Accepted, Blocked, Expired, Invalid, or ConcurrentTx (already charging elsewhere).

Charge point → CSMS
JSON[
  2,
  "a7k2-auth-01",
  "Authorize",
  {
    "idTag": "TAG-1001"
  }
]
CSMS → charge point
JSON[
  3,
  "a7k2-auth-01",
  {
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

Many chargers still send Authorize after a remote start so the CSMS has an explicit yes or no on the token. Treat a missing Authorize as a vendor choice, not a protocol error — but test the path your hardware actually uses.

StartTransaction sample

Triggered when the session actually starts. meterStart is the meter reading at that moment (typically watt-hours). The office must return a numeric transactionId.

Charge point → CSMS
JSON[
  2,
  "a7k2-start-01",
  "StartTransaction",
  {
    "connectorId": 1,
    "idTag": "TAG-1001",
    "meterStart": 0,
    "timestamp": "2026-08-14T10:16:01.000Z"
  }
]
CSMS → charge point
JSON[
  3,
  "a7k2-start-01",
  {
    "transactionId": 1001,
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

Right after this, expect a StatusNotification with status Charging.

MeterValues sample

Triggered on a timer while Charging (and sometimes at begin/end). This is the message billing and session UIs break on when the shape or cadence is wrong.

Charge point → CSMS
JSON[
  2,
  "a7k2-mv-01",
  "MeterValues",
  {
    "connectorId": 1,
    "transactionId": 1001,
    "meterValue": [
      {
        "timestamp": "2026-08-14T10:17:01.000Z",
        "sampledValue": [
          {
            "value": "1850",
            "measurand": "Energy.Active.Import.Register",
            "unit": "Wh",
            "context": "Sample.Periodic"
          }
        ]
      }
    ]
  }
]
CSMS → charge point
JSON[
  3,
  "a7k2-mv-01",
  {}
]

Values are strings in the official JSON schema. Common measurands: Energy.Active.Import.Register, Power.Active.Import, Current.Import, Voltage, SoC. Chargeflux emits periodic energy samples while a connector is Charging so you can see the cadence in the console.

StopTransaction sample

Triggered when the session ends. meterStop is the closing reading. reason tells the CSMS why.

Charge point → CSMS
JSON[
  2,
  "a7k2-stop-01",
  "StopTransaction",
  {
    "transactionId": 1001,
    "idTag": "TAG-1001",
    "meterStop": 5550,
    "timestamp": "2026-08-14T10:19:10.000Z",
    "reason": "Local"
  }
]
CSMS → charge point
JSON[
  3,
  "a7k2-stop-01",
  {
    "idTagInfo": {
      "status": "Accepted"
    }
  }
]

Reasons you will see in the field:

  • Local — stopped at the charger
  • Remote — stopped by the CSMS
  • EVDisconnected — cable unplugged
  • DeAuthorized — the token was revoked mid-session
  • PowerLoss, HardReset, SoftReset, EmergencyStop

After StopTransaction, status usually moves Finishing → Available. That is covered on connector status.

A local session in order

StatusNotification Available
→ cable in → StatusNotification Preparing
→ Authorize (idTag) → Accepted
→ StartTransaction → transactionId
→ StatusNotification Charging
→ MeterValues (repeat)
→ StopTransaction (reason Local)
→ StatusNotification Finishing → Available

Plug-in-first vs card-first order varies by charger vendor. Test both if your CSMS claims to support mixed hardware.

How to walk this in Chargeflux

  1. Connect and wait for an accepted BootNotification.
  2. On an Available connector, select Start Charging in the simulator.
  3. Confirm Authorize → StartTransaction → Charging → MeterValues in the console.
  4. Select Stop Charging and check StopTransaction plus the final status.

Need the CSMS to start the session instead? Test RemoteStartTransaction.

Related

FAQ

Which OCPP 1.6J messages make up a charging session?

Authorize (may this idTag charge?), StartTransaction (the session began), MeterValues (energy samples while it runs), and StopTransaction (the session ended). StatusNotification rides alongside so the map stays current.

When is StartTransaction sent?

After the charger is allowed to start — usually after an accepted Authorize or RemoteStartTransaction — at the moment the session actually begins. The CSMS must return a transactionId.

When is MeterValues sent?

On a configured interval during the transaction (MeterValueSampleInterval), and often at begin/end. Include transactionId while a session is active so the CSMS can attach samples to the right bill.

What does StopTransaction reason Local vs Remote mean?

Local means someone stopped at the charger (button, card, unplug depending on the vendor). Remote means the CSMS asked for the stop, usually after RemoteStopTransaction.

Last reviewed August 2026 · Chargeflux.io