Charging profiles are a rollout control surface
Most teams encounter charging profiles as a protocol feature. Deployers should treat them as a control surface that can either protect a site or destabilize it.
The useful question is not only:
Which charging profile purpose do we use?
It is:
Which system is allowed to set power limits, how do those limits interact, and how do we know the charger is actually enforcing them?
That is what determines whether smart charging works safely in production.
What are charging profiles?
Charging profiles are OCPP's mechanism for controlling how much power a charger delivers and when. They're the building blocks of smart charging — without them, every charger draws maximum power at all times.
A charging profile is essentially a schedule: "Between time A and time B, limit power to X kW."
The four profile purposes
OCPP defines charging profiles by their purpose — what scope they control.
┌─────────────────────────────────────────────────────────────┐
│ CHARGING STATION │
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ ChargePointMaxProfile (Purpose 0) │ │
│ │ "The entire station cannot exceed 100 kW" │ │
│ │ │ │
│ │ ┌──────────────────┐ ┌──────────────────┐ │ │
│ │ │ EVSE 1 │ │ EVSE 2 │ │ │
│ │ │ │ │ │ │ │
│ │ │ TxDefaultProfile │ │ TxDefaultProfile │ │ │
│ │ │ (Purpose 1) │ │ (Purpose 1) │ │ │
│ │ │ "Default: 22 kW" │ │ "Default: 22 kW" │ │ │
│ │ │ │ │ │ │ │
│ │ │ ┌──────────────┐ │ │ ┌──────────────┐ │ │ │
│ │ │ │ TxProfile │ │ │ │ TxProfile │ │ │ │
│ │ │ │ (Purpose 2) │ │ │ │ (Purpose 2) │ │ │ │
│ │ │ │ "This session│ │ │ │ "This session│ │ │ │
│ │ │ │ gets 11 kW" │ │ │ │ gets 7 kW" │ │ │ │
│ │ │ └──────────────┘ │ │ └──────────────┘ │ │ │
│ │ └──────────────────┘ └──────────────────┘ │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘Purpose 0: ChargePointMaxProfile
Scope: The entire charging station.
This is the absolute ceiling. No matter how many EVSEs are active or what their individual profiles say, the total power draw of the station cannot exceed this limit.
When to use it:
- Your building has a fixed grid connection (e.g., 150 kW)
- You need to comply with demand response signals from the grid operator
- Load shedding during peak hours
Example: A parking garage has 200 kW available from the grid. Set ChargePointMaxProfile to 200 kW. Even if 10 chargers each try to draw 22 kW (220 kW total), the station firmware caps total draw at 200 kW.
Purpose 1: TxDefaultProfile
Scope: A specific EVSE (connector group).
This is the default profile applied to every new transaction on that EVSE. If no transaction-specific profile (Purpose 2) is set, this is what governs the session.
When to use it:
- Time-of-day scheduling: lower power during office hours, full power overnight
- Default limits based on connector type: 7 kW for AC, 50 kW for DC
- Seasonal adjustments: different defaults in summer vs winter
Example:
TxDefaultProfile for EVSE 1:
┌──────────────────────────────────────────────────────┐
│ │
│ 22 kW ─── ┐ ┌─── 22 kW│
│ │ │ │
│ 11 kW ─── │──────────────────────────────│ │
│ │ Office hours │ │
│ 7 kW ─── │ (09:00 - 18:00) │ │
│ │ │ │
│ │ │ │
│ ──────────┼──────┬──────┬──────┬────────┼──────── │
│ 00:00 06:00 09:00 18:00 00:00 │
│ │
│ Night: 22 kW │ Morning: 11 kW │ Day: 7 kW │ Eve │
└──────────────────────────────────────────────────────┘Purpose 2: TxProfile
Scope: A specific, active transaction.
This overrides the TxDefaultProfile for one particular charging session. It's the most granular level of control.
When to use it:
- Fleet priority: "This delivery van must be at 80% by 6 AM — give it maximum power"
- User tiers: premium users get higher power, free tier gets limited
- Dynamic optimization: adjust based on real-time grid prices or solar production
Example: A fleet vehicle plugs in at 22:00 and needs to depart at 05:00. The TxDefaultProfile says 7 kW (office hour remnant), but you set a TxProfile for this specific transaction:
TxProfile for Transaction #4521:
22:00 - 02:00 → 22 kW (charge fast while grid is cheap)
02:00 - 04:00 → 11 kW (grid price increases)
04:00 - 05:00 → 22 kW (final boost before departure)Purpose 3: TxDefaultProfile (OCPP 2.0.1 only)
In OCPP 2.0.1, Purpose 3 is reserved for ChargePointMaxProfile at EVSE level. It limits the maximum power for a specific EVSE regardless of active transactions.
This fills a gap from OCPP 1.6 where you could only set a station-wide max (Purpose 0) or per-transaction limits (Purpose 1 and 2), but nothing at the EVSE level.
Stack levels: resolving conflicts
What happens when multiple profiles apply to the same session? OCPP uses stack levels (0-9+) to establish priority.
Higher stack level = higher priority.
Stack Level 3: TxProfile (fleet override) → 22 kW
Stack Level 2: TxProfile (dynamic pricing) → 15 kW
Stack Level 1: TxDefaultProfile (schedule) → 11 kW
Stack Level 0: TxDefaultProfile (base) → 7 kW
─────────────────────────────────────────────────────
Effective limit = highest stack level = 22 kW
BUT: ChargePointMaxProfile says station max = 50 kW
AND: Two EVSEs active, each at 22 kW = 44 kW total
44 kW < 50 kW → OK, both sessions get their requested powerThe effective power for any session is:
effective_power = MIN(
ChargePointMaxProfile (remaining capacity),
MAX(all TxDefaultProfiles by stack level),
TxProfile (if set, highest stack level wins)
)Visual: how profiles stack
Here's a real-world scenario with all profile types active:
Station: 100 kW grid connection
EVSE 1: Session A (fleet van, priority)
EVSE 2: Session B (employee car, standard)
EVSE 3: Empty
┌─────────────────────────────────────────────┐
│ ChargePointMaxProfile: 100 kW │
│ │
│ EVSE 1 (Session A) EVSE 2 (Sess B)│
│ ┌───────────────────┐ ┌──────────────┐│
│ │ TxDefault: 22 kW │ │ TxDefault: ││
│ │ TxProfile: 50 kW │ │ 22 kW ││
│ │ (fleet override) │ │ (no override) ││
│ │ │ │ ││
│ │ Effective: 50 kW │ │ Effective: ││
│ │ │ │ 22 kW ││
│ └───────────────────┘ └──────────────┘│
│ │
│ Total: 50 + 22 = 72 kW │
│ Under 100 kW limit ✓ │
└─────────────────────────────────────────────┘If Session B tried to draw 60 kW (e.g., DC fast charging), the station would cap it at 50 kW (100 kW station max minus 50 kW already allocated to Session A).
Profile scheduling periods
Each profile contains a charging schedule made of periods. Each period specifies:
- Start period — seconds from the schedule start
- Limit — power limit in watts (or amps, depending on unit)
- Number of phases — for AC: 1 or 3 phases
Profile: "Night Optimization"
Schedule start: 2026-03-12T18:00:00Z
Duration: 43200 seconds (12 hours)
Unit: Watts
Periods:
┌─────────┬──────────────────┬──────────┐
│ Start │ Time │ Limit │
├─────────┼──────────────────┼──────────┤
│ 0 sec │ 18:00 │ 7,400 W │
│ 7200 │ 20:00 │ 11,000 W │
│ 14400 │ 22:00 │ 22,000 W │
│ 36000 │ 04:00 │ 11,000 W │
└─────────┴──────────────────┴──────────┘OCPP 1.6 vs 2.0.1 differences
| Feature | OCPP 1.6 | OCPP 2.0.1 | |---------|----------|------------| | Profile purposes | 0, 1, 2 | 0, 1, 2, 3 | | Unit | Amps or Watts | Amps or Watts | | Recurrency | Daily, Weekly | Daily, Weekly | | Cost optimization | No | Yes (via NotifyEVChargingNeeds) | | Vehicle needs reporting | No | Yes | | Profile reporting | GetCompositeSchedule | GetCompositeSchedule + ReportChargingProfiles | | EVSE-level max | No (only station-wide) | Yes (Purpose 3) |
Common mistakes
Setting profiles on the wrong EVSE. In OCPP 1.6, connectorId=0 means the entire station. ConnectorId=1 means the first connector. Mixing these up applies profiles at the wrong scope.
Forgetting about recurrence. A daily recurring profile repeats every 24 hours from the start time. If you set a non-recurring profile, it expires after its duration.
Not using GetCompositeSchedule. After setting multiple profiles, use GetCompositeSchedule to see what the charger will actually do. The composite schedule shows the effective power limit at each point in time, accounting for all stacked profiles.
Exceeding stack level limits. Some chargers only support a limited number of stack levels or profiles per EVSE. Check your charger's capabilities.
Minimum tests before production
Before you rely on charging profiles in a live deployment, validate:
- Site cap enforcement Confirm that aggregate station power respects the upstream limit under simultaneous sessions.
- Scope correctness Verify that station-wide, EVSE-default, and transaction-specific profiles are applied where you expect.
- Stack resolution Test overlapping profiles so you know which effective limit wins in practice.
- Boundary behavior Validate schedule transitions, recurrence windows, and overnight changes.
- Charger variance Compare the same profile logic across charger vendors and firmware versions.
- Fallback behavior Check what happens when connectivity to the CSMS or energy-management source is interrupted.
If you cannot pass those tests, your charging-profile strategy is not deployment-ready yet.
How EV Cloud manages charging profiles
EV Cloud provides a visual profile management system:
- Drag-and-drop schedule editor — create time-based profiles visually
- Profile stacking preview — see how multiple profiles combine before applying
- Fleet rules engine — automatically assign TxProfiles based on user group, vehicle type, or departure time
- Real-time monitoring — see active profiles and actual power draw per session
- API-driven profiles — integrate with building energy management, solar inverters, or grid signals
Next step for rollout teams
If charging profiles are part of your rollout plan, continue with:
- Smart charging with OCPP for site-level control and acceptance-test guidance.
- OCPP platform buyer guide if profile control quality matters in procurement.
- Talk to EV Cloud if your team needs help validating profile behavior across mixed fleets.
