ChargingProfiles: smart charging across parties

Why smart charging crosses company lines

A charge point operator can already manage load on its own site using OCPP directly. ChargingProfiles exists for the cases where the party that needs to shape the load is not the CPO.

• A fleet operator wants its vehicles charged by 6am but slowly overnight to hit off-peak pricing.
• A building energy management system needs to cap total draw so the site does not exceed its grid connection.
• An aggregator is selling demand response and needs to curtail across chargers it does not own.
• A home charger is being coordinated against rooftop solar by the driver's energy retailer.

OCPI 2.2.1 formalises this with the SCSP role — Smart Charging Service Provider — a party whose only function is shaping charging behaviour. The SCSP is the Sender; the CPO is the Receiver.

The three operations

All three are asynchronous in the same two-phase way as Commands: an immediate ChargingProfileResponse, then the real answer posted to a response_url.

Note that profiles are addressed by session, not by EVSE. You cannot pre-load a profile onto a connector before a car arrives — a session must exist first. This is a frequent design surprise for teams coming from OCPP, where profiles can be installed on a charge point in advance.

Anatomy of a charging profile

A profile is a start time, an optional duration, a rate unit, and an ordered list of periods. Each period sets a limit that applies from an offset in seconds until the next period begins.

Worked example: overnight fleet charging

Charge slowly for the first four hours to sit in the off-peak window, then release to full power to guarantee a full battery by morning:

PUT /ocpi/2.2.1/chargingprofiles/sess-77c1
Authorization: Token <base64 token>
OCPI-from-country-code: IN
OCPI-from-party-id: SCS
OCPI-to-country-code: IN
OCPI-to-party-id: EFI

{
  "response_url": "https://scsp.example.com/ocpi/2.2.1/profiles/result/9f22a1",
  "charging_profile": {
    "start_date_time": "2026-08-11T22:00:00Z",
    "duration": 28800,
    "charging_rate_unit": "W",
    "min_charging_rate": 1400,
    "charging_profile_period": [
      { "start_period": 0,     "limit": 7400  },
      { "start_period": 14400, "limit": 22000 }
    ]
  }
}

The immediate acknowledgement:

HTTP/1.1 200 OK

{
  "data": { "result": "ACCEPTED", "timeout": 30 },
  "status_code": 1000,
  "timestamp": "2026-08-11T21:59:04Z"
}

And the asynchronous outcome once the charger has confirmed:

POST /ocpi/2.2.1/profiles/result/9f22a1

{
  "result": "ACCEPTED"
}

Result codes

TOO_OFTEN deserves attention because it has no equivalent elsewhere in OCPI. Smart charging invites tight control loops, and a naive implementation re-sending a profile every few seconds will be throttled. Design for a control interval measured in minutes and treat TOO_OFTEN as a signal to back off exponentially, not to retry harder.

How this maps onto OCPP

The CPO translates an OCPI charging profile into an OCPP SetChargingProfile message. The mapping is close but not exact, and the differences are where behaviour surprises people:

• OCPP has a stack of profiles with purposes and priorities — ChargePointMaxProfile, TxDefaultProfile, TxProfile. OCPI exposes only one profile per session. The CPO decides where yours sits in that stack, and a site-level cap set by the CPO will silently override yours.
• The effective limit is the minimum of every applicable constraint — your profile, the CPO's site limit, the EVSE's rating, the cable's rating, and what the vehicle will actually accept. Asking for 22 kW does not mean 22 kW.
• The vehicle has the final say. A car at 90% state of charge tapers regardless of any profile. Never present a profile as a promise to the end user.

Production lessons

• Verify with MeterValues, never assume. The only ground truth for delivered power is metering. Reconcile intended profile against actual draw and alert on sustained divergence — that is how you find chargers silently ignoring profiles.
• Always set min_charging_rate. Without a floor, an aggressive profile can drop a vehicle into a trickle that never completes, or cause some vehicles to abort the session entirely.
• Clear profiles explicitly at session end. Do not rely on the session ending to release a constraint; a stale profile applied to a reused session ID is a real failure mode.
• Back off on TOO_OFTEN. Exponential backoff, not a tighter retry loop.
• Detect NOT_SUPPORTED once and cache it per partner. Smart charging support across CPOs is uneven; probing on every session wastes calls and skews your error metrics.
• Do not build tariff logic here. ChargingProfiles shapes power, not price. Time-of-use pricing belongs in the Tariffs module, and conflating the two produces bills that do not reconcile.