Smart Charging

Smart Charging enables load balancing scenarios by letting the OCPP Backend or an OCPP-based Energy Manager define charging profiles and apply them on the Charge Controller. This guide assumes familiarity with the OCPP 1.6 Smart Charging specification (Edition 2).

1. Prerequisites

• OCPP Backend connection established and verified. See OCPP Connection.
• Internal Meters configured correctly and suitable for enabling Smart Charging. See Metering and your OEM's manual.

2. Backend Requirements

Backends must:

• Send profiles using chargingRateUnit: "A"
• Respect the Charge Controller's fixed configuration ChargingScheduleAllowedChargingRateUnit = "Current" (this usually goes hand-in-hand with the point above)
• (Optional) Provide GetCompositeSchedule to help with diagnosing Smart Charging configurations

tip

Talk to your Backend provider to verify the requirements above are fulfilled.

3. Configuration

Configure the following settings in the Config UI:

Location in Config UI	Setting	Description	Remarks
# Installation > General Installation	Phases connected to the ChargePoint	Number of phases available
# Installation > General Installation	Phase rotation of the ChargePoint	Ensures correct phase assignment	Incorrect phase rotation will cause measurements to be assigned to the wrong phase, leading to faulty calculations in the backend/energy manager.
# Load Management > Local	Enable Disconnected Upper Limit for SmartCharging	Use local limit when backend is offline
# Backend > OCPP	Disconnected Upper Limit [A] for SmartCharging	Limit applied when backend is disconnected
# Backend > Meter	Meter values sampled data (OCPP)	Measurands included in periodic MeterValues
# Backend > Meter	Meter Value Sample Interval (OCPP)	Sampling interval in seconds	The Meter Value Sample Interval (OCPP) can typically be set between 10 and 99999 seconds. If the OCPP Via Local Network minimum value '1' (OCPP-only setting) option is activated via OCPP ChangeConfiguration, the interval can be set from 1 to 99999 seconds. While the optimal interval depends on the specific application and network stability, typical recommendations are: <= 4 seconds for local network operation <= 10 seconds for backend operation in stable networks

3.1. Meter values sampled data

The Meter values sampled data (OCPP) setting controls which measurands are sent in MeterValues for evaluation.

3.1.1. Measurands and allowed phase suffix tokens

Measurand	Description	Allowed phase suffix tokens
# Current.Offered	Maximum allowed current	–
# Current.Import	Actual charging current	L1, L2, L3
# Power.Active.Import	Active power during charging	L1, L2, L3
# Power.Offered	Maximum power allowed (calculated)	–
# Energy.Active.Import.Register	Imported energy (session / total)	L1, L2, L3
# Voltage	Phase-to-phase or phase-to-neutral	L1, L2, L3, L1-N, L2-N, L3-N
# Frequency	Grid frequency	–

info

Phase-specific measurands must be explicitly listed in Meter values sampled data (OCPP) to appear in the OCPP Backend.

3.1.2. Syntax

The configuration parameter Meter values sampled data (OCPP) SHALL contain a comma-separated list of items. Whitespace is ignored.

Element	Rule
# Item	Each item SHALL be composed of a measurand name and an optional phase suffix.
# Measurand name	A measurand name SHALL consist of a dot-separated sequence of identifiers. Each identifier SHALL start with a letter, followed by zero or more letters, digits, or dots.
# Phase suffix	If present, the phase suffix SHALL consist of a dot (.) followed by one of the allowed phase suffix tokens for that measurand (see table below).
# List rules	The list MAY be empty. If non-empty, each item SHALL be separated from the next by a comma (,). Leading and trailing whitespace around items is ignored.

3.1.3. Rules and Constraints

These rules ensure the Charge Controller can unambiguously interpret Meter values sampled data (OCPP):

Rule	Explanation	Examples
# Don't mix generic and phase-specific versions of the same measurand	Use either the generic measurand (for example Current.Import) or all needed phase-specific versions (Current.Import.L1, Current.Import.L2, Current.Import.L3). Mixing both for the same measurand makes it unclear which value to report and is rejected.	Invalid combination (generic and phase-specific mixed): Current.Import,Current.Import.L1 Valid configuration using only the generic measurand: Current.Import Valid configuration using only phase-specific measurands: Current.Import.L1,Current.Import.L2,Current.Import.L3
# No duplicates	Each measurand may appear only once in the list. Duplicates cannot be resolved and cause the configuration to be rejected.	Invalid configuration with a duplicate entry: Current.Import.L1,Current.Import.L1 Correct the list so each measurand appears only once.
# Phase-specific measurands require a three-phase meter	Per-phase values such as .L1, .L2, .L3, .L1-N are only meaningful if the internal meter measures all three phases. On single-phase setups these should not be used.	Phase-specific entries are valid only on three-phase hardware.
# The meter must support the measurand	Only measurands supported by the internal meter can be used. Unsupported entries may lead to missing values in the OCPP Backend.	Check your OEM meter documentation before enabling per-phase power or current.

3.1.4. Examples

The following examples show typical Meter values sampled data (OCPP) configurations:

• Minimal
  Typical use: Simple current limiting and basic energy reporting
  Meter values sampled data (OCPP) field value:
  Energy.Active.Import.Register,Current.Offered

• Intermediate
  Typical use: Per-phase current-based load balancing and offered power
  Meter values sampled data (OCPP) field value:
  Current.Import.L1,Current.Import.L2,Current.Import.L3,Current.Offered,Power.Offered

• Full
  Typical use: Detailed per-phase power, current, voltage and limits plus frequency
  Meter values sampled data (OCPP) field value:
  Energy.Active.Import.Register,Power.Active.Import.L1,Power.Active.Import.L2,Power.Active.Import.L3,Current.Import.L1,Current.Import.L2,Current.Import.L3,Voltage.L1-N,Voltage.L2-N,Voltage.L3-N,Current.Offered,Power.Offered,Frequency

Counterexamples (The Charge Controller rejects these configurations):

• Invalid combination (generic and phase-specific mixed):
  Current.Import,Current.Import.L1 Valid configuration using only the generic measurand:
  Current.Import Valid configuration using only phase-specific measurands:
  Current.Import.L1,Current.Import.L2,Current.Import.L3

• Invalid configuration with a duplicate entry:
  Current.Import.L1,Current.Import.L1

3.1.5. Syntax checker

Put your Meter values sampled data (OCPP) configuration in the box below to check if it's valid.

Syntax Checker - MeterValuesSampledData

Validation Feedback

When entering Meter values sampled data (OCPP) via the WebUI, malformed input is rejected entirely by server-side validation. If any measurand is invalid or violates the rules below, the entire configuration change is rejected and an error notification appears in the WebUI.
The previous valid configuration remains in effect.

3.2. Scheduling rules

3.2.1. First Period

• Must start at startPeriod = 0
• Any other value results in profile rejection (invalid per OCPP 1.6)

3.2.2. Period continuity

• Periods are continuous:
• A period remains active from its startPeriod until the next period begins
• The next period’s startPeriod defines when the previous period ends

3.2.3. Duration

• If duration is not set, the last period remains active indefinitely (or until the transaction ends when using a relative schedule)
• If duration is set, the schedule applies until duration expires. After that, charging falls back to default behavior

3.2.4. Recurring Schedules

• Schedules do not need to cover the entire recurrence window

• If a recurring schedule’s duration is shorter than the recurrence window, the Charging Station falls back to default behavior after duration ends:

  • apply a lower stackLevel profile if available, otherwise
  • behave as if no ChargingProfile is installed

3.2.5. Scheduling cheat sheet

Scenario	Behavior
# First period does not start at 0	Profile rejected (invalid per OCPP 1.6)
# Gap inside a schedule	The previous period remains active until the next startPeriod
# After duration expires	Fall back to default behavior / lower stackLevel
# Recurring schedule shorter than recurrence window	Fall back to default behavior / lower stackLevel
# No valid profile	Default behavior (as if no profile is installed)

3.3. Profile precedence

When multiple charging profiles are active at the same time, the Charge Controller determines the effective limit in two steps:

1. Determine the applicable profiles for the connector and time.
2. Apply the lowest limit across all applicable profiles.

3.3.1. Precedence (applicability)

Priority	Profile	Applies when	Typical purpose
# 1	TxProfile	During an active transaction	Session-specific control
# 2	TxDefaultProfile	When no TxProfile applies	Default session behavior
# 3	ChargePointMaxProfile	Always (station-wide)	Site/station ceiling

3.3.2. Effective limit rule

The effective limit SHALL be the minimum of all applicable profile limits at that time:

• $EffectiveLimit = \min(ChargePointMaxProfile,\ TxDefaultProfile,\ TxProfile)$

(Diagram illustrating how the Charge Controller determines the effective charging limit by selecting all applicable profiles and applying the lowest limit.)

3.3.3. Limit example

ChargePointMaxProfile	TxDefaultProfile	TxProfile	Effective limit
# 32 A	20 A	25 A	20 A
# 16 A	30 A	25 A	16 A
# 32 A	28 A	10 A	10 A
# 16 A	16 A	16 A	16 A

4. Implementation details

OCPP Reference

The implementation is based on the OCPP 1.6 edition 2 FINAL, 3.13.1. specification.

The Charge Controller supports:

• ChargePointMaxProfile – station-wide ceiling
• TxDefaultProfile – default for new sessions
• TxProfile – per-session profile

Capacity:

• Up to 255 profiles
• Up to 255 periods per profile
• Profile types: Absolute, Recurring, Relative

4.1. Profile implementation details

Aspect	Description
# Fractional Ampere Handling	Fractional ampere values (e.g., 10.7 A) in charging schedules are truncated to whole amperes (10 A). The Charge Controller operates internally with integer ampere values only.
# Phase Parameter Ignored	The numberPhases parameter in charging schedules is ignored. Actual phase switching depends on hardware capabilities and the ConnectorSwitch3to1PhaseSupported setting.
# Profile Storage	The Charge Controller maintains a local cache of received profiles. See Clearing the Smart Charging cache for details.

4.2. Examples of Smart Charging profiles

4.2.1. Station-wide ceiling (ChargePointMaxProfile)

Use case: Site / station fuse protection. Hard ceiling that always applies.
Scope: Whole station (connectorId 0).
Behavior: Always applies.

{
  "connectorId": 0,
  "csChargingProfiles": {
    "chargingProfileId": 1001,
    "stackLevel": 0,
    "chargingProfilePurpose": "ChargePointMaxProfile",
    "chargingProfileKind": "Absolute",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 16 }
      ]
    }
  }
}

4.2.2. Default session behavior (TxDefaultProfile, recurring daily)

Use case: Off-peak throttling at night, normal current during daytime.
Scope: Connector-specific (example uses connectorId 1).
Behavior: Applies when no TxProfile is active.

This example defines a daily schedule with:

• 00:00–06:00 → 6 A
• 06:00–22:00 → 16 A
• 22:00–24:00 → 6 A

{
  "connectorId": 1,
  "csChargingProfiles": {
    "chargingProfileId": 2001,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxDefaultProfile",
    "chargingProfileKind": "Recurring",
    "recurrencyKind": "Daily",
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "duration": 86400,
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 6 },
        { "startPeriod": 21600, "limit": 16 },
        { "startPeriod": 79200, "limit": 6 }
      ]
    }
  }
}

4.2.3. Session-specific limit (TxProfile)

Use case: Start gently (grid stability / demand management), then ramp up.
Scope: One active transaction on connector 1.
Behavior: Applies only during the transaction referenced by transactionId.

This example sets:

• first 15 min → 10 A
• after 15 min → 20 A

{
  "connectorId": 1,
  "csChargingProfiles": {
    "chargingProfileId": 3001,
    "stackLevel": 0,
    "chargingProfilePurpose": "TxProfile",
    "chargingProfileKind": "Relative",
    "transactionId": 12345,
    "chargingSchedule": {
      "chargingRateUnit": "A",
      "chargingSchedulePeriod": [
        { "startPeriod": 0, "limit": 10 },
        { "startPeriod": 900, "limit": 20 }
      ]
    }
  }
}

5. Smart Charging cache

The Charge Controller uses a local cache. If needed, you can clear the Smart Charging cache.

Normally not required

In regular operation, the Smart Charging cache is managed by the OCPP Backend. Clear it only for testing, troubleshooting, backend migration, or after wiring/phase changes.

The Charge Controller keeps a local cache of limits/schedules received from the OCPP Backend. Clearing it removes all entries so the Charge Controller will accept new profiles or temporarily fall back to local defaults until new profiles arrive.

5.1. How to clear the cache

Location in Config UI	Parameter / Action	Description	Recommended setting
# Load Management > Local	Delete all Smart Charging profiles	Clears the local Smart Charging cache (all stored profiles/schedules).	Click Delete all during maintenance/no active sessions

5.2. When to clear the cache

• Backend changes → avoid conflicts when switching to a new OCPP Backend
• Commissioning & testing → start from a clean state
• Troubleshooting → resolve mismatch between the Charge Controller's schedule and the schedule intended by the OCPP Backend
• Wiring/config changes → e.g., phase rotation or number of phases

Live charging impact

Clearing the cache can immediately change active current limits. Do this only when no sessions are active.

5.3. Verifying Cache state

1. If available, from the OCPP Backend, call GetCompositeSchedule → should be empty/default until new profiles arrive.
2. Check Charge Controller logs for profile removal.
3. Confirm the OCPP Backend re-sends the intended profiles.

6. Verifying Smart Charging operation

After configuring Smart Charging, verifying Smart Charging is applied can be done in two ways:

On the Backend:

• If available, use GetCompositeSchedule to request the active limits for a connector.
• Confirm that the returned schedule matches the intended charging profile (limits, time windows, unit = amperes).

On the Charge Controller

• Check the UI under Load Management
• Review logs for profile acceptance or rejection

tip

When troubleshooting, compare the OCPP Backend’s GetCompositeSchedule output with what the Charge Controller shows in the logs or UI. They should match.

7. Frequently asked questions

• Only ampere-based profiles come into effect.

• The first period must start at 0 seconds.

• Periods are continuous. Each period remains active until the next begins.

• The lowest limit across all active profiles determines the effective charging current.

• If a schedule ends (for example due to ), charging falls back to default behavior, which may be determined by external or internal factors such as Energy Managers, Limits, or other mechanisms.

• After the configured , charging falls back to default behavior until the next recurrence cycle begins.

• Yes.

• The Smart Charging cache should be cleared.