NotifyReport

Delivers the contents of a GetBaseReport or GetReport, in one or more parts.

Version: OCPP 2.0.1
Direction: Charge Point → CSMS
Functional block: Provisioning

The device model inventory arrives here, not in the response to the request that asked for it. Large reports are split across several messages, each numbered with seqNo and flagged with tbc — 'to be continued'.

The sequence is complete when a message arrives with tbc absent or false.

Request

Field	Type	Required	Description
`requestId`	integer	Required	Matches the `requestId` from GetBaseReport or GetReport.
`generatedAt`	dateTime	Required	When the station generated this part.
`seqNo`	integer	Required	Part number within this report, starting at 0.
`reportData`	ReportDataType[]	Optional	The component/variable entries, with their attributes and characteristics.
`tbc`	boolean	Optional	True when more parts follow. Defaults to false.

json

[2, "19223201", "NotifyReport", {
  "requestId": 501,
  "generatedAt": "2026-09-09T10:40:00Z",
  "seqNo": 0,
  "tbc": true,
  "reportData": [{
    "component": { "name": "OCPPCommCtrlr" },
    "variable": { "name": "HeartbeatInterval" },
    "variableAttribute": [{ "value": "300", "mutability": "ReadWrite" }],
    "variableCharacteristics": { "dataType": "integer", "supportsMonitoring": true }
  }]
}]

Response

No fields — the payload is an empty object {}.

json

[3, "19223201", {}]

Implementation notes

Do not treat the first message as the whole report. Accumulate until tbc is false, or you will build a device model from a fraction of the station's variables.

variableCharacteristics.dataType tells you how to interpret the string values, and mutability tells you whether SetVariables will work — both worth storing.

supportsMonitoring is what determines whether SetVariableMonitoring can watch this variable.