GetCompositeSchedule
Asks the charge point for the flattened schedule it will actually follow, with all profiles already combined.
- Version
- OCPP 1.6
- Direction
- CSMS → Charge Point
- Feature profile
- Smart Charging
GetCompositeSchedule also exists in OCPP 2.0.1, with a different payload. See the OCPP 2.0.1 version.
This is the message that tells you whether your smart charging logic worked. The charge point resolves every applicable profile — max, default, transaction-specific, all stack levels — and returns the single schedule that results.
When a curtailment does not appear to take effect, this is the first thing to call.
Request
| Field | Type | Required | Description |
|---|---|---|---|
connectorId | integer | Required | Connector to report on. 0 for the whole charge point. |
duration | integer | Required | How many seconds ahead to report. |
chargingRateUnit | ChargingRateUnitType | Optional | A or W. Omit to let the charge point choose. |
[2, "19223201", "GetCompositeSchedule", {
"connectorId": 1,
"duration": 86400,
"chargingRateUnit": "A"
}]Response
| Field | Type | Required | Description |
|---|---|---|---|
status | GetCompositeScheduleStatus | Required | Whether a schedule could be produced. |
connectorId | integer | Optional | The connector the schedule is for. |
scheduleStart | dateTime | Optional | The time startPeriod: 0 refers to. |
chargingSchedule | ChargingSchedule | Optional | The combined schedule. |
[3, "19223201", {
"status": "Accepted",
"connectorId": 1,
"scheduleStart": "2026-09-09T10:00:00.000Z",
"chargingSchedule": {
"chargingRateUnit": "A",
"chargingSchedulePeriod": [
{ "startPeriod": 0, "limit": 32.0 },
{ "startPeriod": 21600, "limit": 16.0 }
]
}
}]Values
GetCompositeScheduleStatus
| Value | Meaning |
|---|---|
Accepted | A schedule was produced. |
Rejected | No schedule could be produced for the request. |
Implementation notes
`scheduleStart` is what makes the response readable. Without it the startPeriod offsets have no anchor. A charger that omits it on an Accepted response is leaving you to guess.
The charge point may return a shorter duration than requested. That is legal.
If the composite schedule disagrees with your intent, the usual causes are a stack level lower than something already installed, a TxProfile whose transactionId no longer matches, or a ChargePointMaxProfile capping from above.