TransactionEvent: the 2.0.1 rewrite

Three messages become one

The motivation is that in 1.6J these three messages describe one thing — a transaction — while carrying inconsistent context. MeterValues might or might not carry a transaction ID. The relationship between a meter sample and the session it belongs to was implicit. Ordering between messages was not guaranteed.

One message type with a consistent envelope fixes all three.

The message

// Charge point -> CSMS
[2, "b7f14a2c", "TransactionEvent", {
  "eventType": "Updated",
  "timestamp": "2026-08-11T09:47:10Z",
  "triggerReason": "MeterValuePeriodic",
  "seqNo": 14,
  "transactionInfo": {
    "transactionId": "770142",
    "chargingState": "Charging",
    "timeSpentCharging": 2110
  },
  "evse": { "id": 1, "connectorId": 1 },
  "idToken": { "idToken": "DR88231ABCD", "type": "ISO14443" },
  "meterValue": [{
    "timestamp": "2026-08-11T09:47:10Z",
    "sampledValue": [
      { "value": 4490220, "measurand": "Energy.Active.Import.Register",
        "unitOfMeasure": { "unit": "Wh" } },
      { "value": 48.2, "measurand": "Power.Active.Import",
        "unitOfMeasure": { "unit": "kW" } },
      { "value": 74, "measurand": "SoC", "unitOfMeasure": { "unit": "Percent" } }
    ]
  }]
}]

// CSMS -> charge point
[3, "b7f14a2c", { "idTokenInfo": { "status": "Accepted" } }]

triggerReason: the field 1.6J lacked

In 1.6J, receiving a MeterValues message told you a sample arrived. It did not tell you why. triggerReason makes that explicit, and it turns the transaction stream into an event log you can actually reason about.

seqNo and chargingState

seqNo

A strictly incrementing counter within a transaction. It solves an ordering problem 1.6J left open: messages arriving out of order, particularly after an offline period, could not be reliably sequenced by timestamp alone when the charger's clock had drifted.

With seqNo you can order events definitively and, just as usefully, detect gaps. A jump from 14 to 16 means event 15 was lost, and you know to go looking rather than silently billing incomplete data.

chargingState

Replaces inference from StatusNotification with an explicit field on the transaction itself:

In 1.6J you correlated connector status against transaction state and hoped they agreed. Here the transaction reports its own charging state, which removes an entire class of reconciliation bug.

Migrating from 1.6J

The two versions are not wire-compatible and there is no upgrade path at the message level — a CSMS supports one, the other, or both side by side. In practice everyone runs both for years.

The last row causes real bugs. A platform that typed transaction IDs as integers has to widen that type everywhere, including in stored data and partner-facing references.

The right approach is to normalise at ingestion: translate both 1.6J messages and 2.0.1 TransactionEvents into one internal representation immediately, and keep version-specific handling at the protocol edge. Everything downstream — billing, roaming, reporting — should never know which version a charger speaks.

Production lessons

• Normalise both versions at the edge into one internal transaction model.
• Type transaction IDs as strings from the start, even on a 1.6J-only platform.
• Use seqNo gaps as a data-integrity alarm. A missing event means incomplete billing data.
• Index and dashboard triggerReason. It is the best diagnostic signal either version offers.
• Do not assume 2.0.1 means better data. Vendor implementations vary; certify each model.
• Keep CDR output identical across versions. A roaming partner must not be able to tell which OCPP version produced a charge.