SetChargingProfile is a single OCPP command, but CSMS teams use it in two very different ways: as a fixed limit configured once and applied to every session automatically, or as a live lever pulled mid-transaction in response to something happening right now, such as a grid signal, another connector starting a session, or a demand-response event. (See OCPP Smart Charging Explained for the profile model itself: purposes, stack levels, schedule periods. This guide is the hands-on testing path for both usage patterns.)
Static: a profile that applies to every session automatically
A static profile is set once, before any transaction exists, and never touched again. It is typically a TxDefaultProfile: the default applied to any new transaction on a connector, or on every connector at connector ID 0, without the CSMS needing to know a transaction ID in advance.
- Create a charging station via the API and let it connect to your CSMS.
- Before starting any session, send SetChargingProfile with chargingProfilePurpose: TxDefaultProfile, a fixed stackLevel (e.g. 0), and a schedule with one or two power-limited periods.
- Plug in a virtual EV and start a transaction. Watch the MeterValues stream. Reported power should never exceed the profile's limit at any point.
- Stop that session, then start a second and third one without touching the profile again. The same limit should apply automatically every time, with no further CSMS involvement per session.
Dynamic: a profile pushed live, mid-transaction
A dynamic override is a new SetChargingProfile call sent while a transaction is already running. It is usually a TxProfile, which applies only to the connector's currently active transaction and takes priority over any TxDefaultProfile underneath it.
- With a transaction already running under the static baseline above, send a new SetChargingProfile targeting the same connector, with chargingProfilePurpose: TxProfile and a different power limit.
- Check the very next MeterValues sample. No restart or reconnect is required: SimItNow re-evaluates the full profile stack on every meter reading, so the new limit should be reflected immediately.
- Call GetCompositeSchedule for that connector to fetch what the station believes the effective limit is right now. This is the standard OCPP way to confirm your CSMS's own expectation matches the station's actual state.
- Send ClearChargingProfile for the TxProfile you just added and confirm the connector falls back to the original TxDefaultProfile, rather than dropping to zero or staying stuck on the override.
Why the priority order matters
SimItNow resolves conflicts per OCPP §7.3.2. An optional ChargePointMaxProfile sets a station-wide ceiling regardless of individual connectors. Below that, the highest-stack-level TxProfile wins if one exists for the active transaction, otherwise the connector's own TxDefaultProfile applies, falling back to a station-wide default at connector 0 if that is all that was set. Testing against a simulator that enforces this order means your assertions check your CSMS's arithmetic against known station behaviour.
Bugs this setup catches
- A profile meant for one connector accidentally applied station-wide, or the reverse.
- A ChargePointMaxProfile ceiling lower than the sum of active TxProfiles, so connectors silently under-deliver and nobody notices until a customer complains.
- ClearChargingProfile filters (by ID, purpose, connector, or stack level) matching the wrong entries and clearing more or less than intended.
- Assuming a profile change only takes effect on the next transaction, when a live override is supposed to apply immediately.
Create a free SimItNow account and test both static and dynamic charging profiles without a lab full of power equipment.