GetBaseReport

Asks the station to describe itself — its full device model, or just what is configurable.

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

This is the message that makes the device model usable. Rather than probing for configuration keys and hoping, the CSMS asks the station to enumerate its own components and variables.

The report does not come back in the response. The station acknowledges, then delivers the contents through one or more NotifyReport messages carrying the requestId you supplied.

Request

Field	Type	Required	Description
`requestId`	integer	Required	Correlation id, echoed in the NotifyReport messages that follow.
`reportBase`	ReportBaseEnumType	Required	Which report to produce.

json

[2, "19223201", "GetBaseReport", {
  "requestId": 501,
  "reportBase": "FullInventory"
}]

Response

Field	Type	Required	Description
`status`	GenericDeviceModelStatusEnumType	Required	Whether the report will be produced.
`statusInfo`	StatusInfoType	Optional	Reason code.

json

[3, "19223201", {
  "status": "Accepted"
}]

Values

ReportBaseEnumType

Value	Meaning
`ConfigurationInventory`	Only variables that can be written.
`FullInventory`	Every component and variable the station has.
`SummaryInventory`	Variables that differ from their default, plus anything in a non-standard state.

GenericDeviceModelStatusEnumType

Value	Meaning
`Accepted`	The report will follow.
`Rejected`	Refused.
`NotSupported`	This report base is not supported.
`EmptyResultSet`	Nothing matched — no NotifyReport will follow.

Implementation notes

`EmptyResultSet` means no NotifyReport is coming. A CSMS that waits for one after this status will hang until it times out.

This is the first thing to run against an unfamiliar station. FullInventory is the 2.0.1 equivalent of dumping all of 1.6's configuration keys, and it is far more informative.

A full inventory on a large station arrives as many NotifyReport messages. Use tbc on each to know when the sequence has finished.