GetChargingProfiles
Asks which charging profiles are installed. New in 2.0.1 — 1.6 had no way to read them back.
- Version
- OCPP 2.0.1
- Direction
- CSMS → Charge Point
- Functional block
- Smart Charging
1.6 could install and clear profiles but never list them, so a CSMS had to trust its own record of what it had sent. 2.0.1 closes that gap.
As with the device model reports, the content arrives separately — in ReportChargingProfiles messages carrying the requestId.
Request
| Field | Type | Required | Description |
|---|---|---|---|
requestId | integer | Required | Correlation id, echoed in ReportChargingProfiles. |
chargingProfile | ChargingProfileCriterionType | Required | Filter: purpose, stack level, profile ids, or source. |
evseId | integer | Optional | Limit to one EVSE. |
json
[2, "19223201", "GetChargingProfiles", {
"requestId": 701,
"evseId": 1,
"chargingProfile": { "chargingProfilePurpose": "TxDefaultProfile" }
}]Response
| Field | Type | Required | Description |
|---|---|---|---|
status | GetChargingProfileStatusEnumType | Required | Accepted or NoProfiles. |
statusInfo | StatusInfoType | Optional | Reason code. |
json
[3, "19223201", {
"status": "Accepted"
}]Implementation notes
`NoProfiles` means no ReportChargingProfiles will follow. Waiting for one after that status hangs until timeout.
This is the right way to reconcile smart charging state after a CSMS restart, instead of reinstalling profiles blindly.