Load management
Nohmad Engineering13 min readHardware-agnostic EV load management: what “OCPP compatible” means
Hardware-agnostic load management controls any charger that implements OCPP smart charging, not just one brand. Here is what OCPP 1.6J actually standardises, what it leaves to each charger, and what to ask before you call a charger compatible.
Last updated
Hardware-agnostic EV load management lets one controller share a site's limited supply across chargers from any manufacturer, provided each charger implements OCPP smart charging properly. “OCPP compatible” on a datasheet does not guarantee that. Here is what the standard fixes, and what it leaves open.
What is hardware-agnostic EV load management?#
Hardware-agnostic EV load management is a site controller that limits charging through open, standard interfaces instead of a manufacturer's private link. It sends each charger a current limit using OCPP smart charging and reads building load from any meter it can talk to, so chargers and meters from different brands can share one supply.
The alternative is brand-locked balancing. Many charger makers build load balancing into their own products: the chargers coordinate with each other, or with the maker's cloud. That works well while every charger on the site comes from the same maker.
Zaptec's documentation is unusually candid about the trade-off. Connecting its chargers directly over OCPP 1.6J "fully supports the standard OCPP 1.6J Smart Charging profiles" but does not support Zaptec's "proprietary and more advanced phase and load balancing features". Its cloud route keeps that balancing but "does not support any of the standard OCPP Smart Charging profiles" [4]. You get the maker's own balancing or open control by a third party, not both.
Vendor neutrality matters most where a site grows over years: a workshop or depot replacing a failed charger with whatever is available, or an apartment building where owners choose their own units.
Static vs dynamic load management: what's the difference?#
Static load management divides a fixed amount of capacity between chargers and never looks at what the rest of the building is drawing. Dynamic load management measures the real load on the supply, phase by phase, and gives the chargers whatever headroom is left, adjusting their limits as that load rises and falls through the day.
An illustrative example: a workshop has a 100 A per phase supply. Its compressors, hoists and lights peak at about 70 A per phase in the afternoon and sit near 20 A overnight. A static scheme has to plan around the afternoon peak, so it can promise the chargers only 30 A per phase, around the clock. A dynamic scheme can offer about 80 A per phase overnight and drop back to 30 A when the compressors start. That is arithmetic only (supply rating minus measured non-EV load, before any safety margin); your designer sets the real limits. Our capacity calculator runs the same sum for your site.
Dynamic limits need a meter, a controller, and chargers that obey. The rest of this guide is about the chargers.
What does OCPP 1.6J smart charging actually standardise?#
OCPP 1.6J smart charging standardises one message, SetChargingProfile, that tells a charger the most current or power it may deliver over time. It also defines three profile purposes, a stack-level rule for which profile wins, a choice of amps or watts, and configuration keys that let the management system discover what each charger can hold.
Three profile purposes#
| Purpose | Where it is set | What it limits | Typical load-management use |
|---|---|---|---|
ChargePointMaxProfile | Connector 0 only | All connectors on the charger combined | A ceiling for a multi-socket charger |
TxDefaultProfile | Connector 0 (all) or one connector | Transactions, unless a TxProfile is present | A safe default before allocation, and the fallback when contact is lost |
TxProfile | A connector with a running transaction | That transaction only; deleted when it ends | The live setpoint, updated as site load changes |
The charger merges purposes by taking the minimum at every moment: the result never exceeds the lowest of ChargePointMaxProfile and the transaction's TxProfile, or its TxDefaultProfile when no TxProfile exists [1].
Stack levels#
Within one purpose, profiles stack. The valid profile with the highest stackLevel prevails, and a new profile with the same purpose and stack level replaces the old one. The charger reports ChargeProfileMaxStackLevel, the highest stack level it accepts [1]. A controller that puts its live setpoint at stack level 16 cannot drive a charger that reports a maximum of 8 the same way.
- 10 ANo TxProfile yet, so the TxDefaultProfile applies.
- 24 AA TxProfile at stackLevel 0 sets the live limit.
- 16 AThe ChargePointMaxProfile window is lower, so it wins.
- 28 AA TxProfile at stackLevel 1 prevails over stackLevel 0, although its limit is higher.
Amps or watts, and the numberPhases trap#
A chargingRateUnit of A means amps per phase, not the sum of all phases. W means total power; for AC the charger converts it to current using the nominal line voltage (230 V here) and numberPhases, and if numberPhases is absent, 3 is assumed [1]. Worked arithmetic: send 7,360 W to a single-phase 32 A charger without numberPhases set to 1, and a charger following that rule computes 7,360 ÷ (230 × 3) ≈ 10.7 A, not 32 A. On AC sites, amps avoid the conversion.
Minimum rate and capability discovery#
The optional minChargingRate field tells a balancing algorithm the rate below which charging is inefficient. Separately, an AC charger signals the allowed current to the car over the control pilot, and that signal starts at 6 A (a 10 % duty cycle) [5], so most controllers pause a bay rather than offer it less.
A Smart Charging charger must report four keys through GetConfiguration: ChargeProfileMaxStackLevel, ChargingScheduleAllowedChargingRateUnit, ChargingScheduleMaxPeriods and MaxChargingProfilesInstalled. SupportedFeatureProfiles says which feature profiles it implements at all [1].
Offline behaviour#
A charger that loses its management system after receiving a TxProfile keeps using it for the rest of the transaction. One that goes offline earlier uses whatever ChargePointMaxProfile or TxDefaultProfile it holds. One with no profiles at all "SHALL execute a transaction as if no constraints apply" [1]. That clause is why a charger should never be left without a default profile.
What does OCPP leave to each charger?#
OCPP defines the messages, not the quality of each implementation. How many stack levels a charger holds, which units it accepts, how it treats phases, the lowest current it regulates to, how quickly the car follows a new limit, whether profiles survive a reboot and what it reports in MeterValues all vary between models and firmware versions.
- Phase handling. A charger can report each connector's phase rotation relative to the grid in
ConnectorPhaseRotation, and switching from three phases to one mid-session is optional [1]. Per-phase load management is only as good as that phase map. - Minimum and zero current. What the charger does with 0 A (suspend, reported as
SuspendedEVSE) and with a limit between 0 and 6 A is up to the firmware. - Response time. OCPP 1.6 sets no deadline for a new limit to reach the car. Measure it at commissioning.
- Persistence. OCPP 1.6 says the authorisation cache and local authorisation list should survive reboots and power outages. It says nothing equivalent for charging profiles. Ask, then test with a power cycle.
- Metering. The default
MeterValuesmeasurand isEnergy.Active.Import.Register. Per-phaseCurrent.Import, orCurrent.Offered(the current the charger says it is offering), appears only if the charger supports it andMeterValuesSampledDatarequests it, at the interval set byMeterValueSampleInterval[1]. - Acceptance. A
SetChargingProfileresponse reports whether the charger processed the message, and the specification adds that this "does not guarantee the schedule will be followed to the letter" [1].Acceptedis a promise, not a measurement.
What should “OCPP compatible” mean? A checklist for charger vendors#
“OCPP compatible” should mean that a charger implements the OCPP 1.6J Core and Smart Charging feature profiles, reports its smart-charging limits honestly, obeys SetChargingProfile within a time you have measured, falls back to a safe profile when offline, and can be pointed at any CSMS. These questions turn that into answers a vendor gives in writing.
| Ask the vendor | Why it matters |
|---|---|
| Which OCPP version and feature profiles does this firmware implement? | Smart Charging is optional in 1.6; “OCPP” can mean Core only |
| Is the model certified by the Open Charge Alliance, and for which profiles? | Certification covers named profiles, not OCPP as a whole |
What are ChargeProfileMaxStackLevel and MaxChargingProfilesInstalled? | The controller's profile layering has to fit |
Which units does ChargingScheduleAllowedChargingRateUnit list? | Amps avoid voltage and phase conversions on AC |
How does it handle numberPhases, and is ConnectorPhaseRotation reported? | Per-phase limits depend on knowing which phase each charger loads |
| What is the lowest non-zero current it regulates to, and what does 0 A do? | Below 6 A an AC charger cannot signal current to the car |
How long from Accepted until the car draws the new current? | Sets how fast the site can respond to a load spike |
| Do installed profiles survive a reboot or power cut? | OCPP 1.6 does not say |
Which measurands can MeterValues carry, per phase, and how often? | The controller needs them to check the charger obeys |
| Who can change the CSMS address, and how? | Decides whether you can ever leave |
How does a vendor-neutral controller cope with real-world variation?#
A vendor-neutral controller assumes nothing about a charger it has not checked. It reads each charger's smart-charging capabilities when it connects, installs a safe default profile before allocating anything, compares measured current with every setpoint, and measures site load at the switchboard instead of trusting the chargers to report it.
Probe on connect, alarm on shortfall. Read the discovery keys the moment a charger connects. If it falls short, say so at commissioning, not on the first cold evening.
Install a fallback first. A charger with no profiles charges unconstrained when it loses contact, so the first thing to install is a modest TxDefaultProfile. The OCPP 2.0.1 local smart charging example does exactly this, giving every charger a low default limit so that vehicles cannot start charging at full power before the local controller has set a charging profile [2].
Verify, then clamp. Compare each charger's measured current with its setpoint. A charger that keeps drawing well above its limit should lose its allowance, be probed in small steps and be reset if it still misbehaves, with an alarm at each stage. None of this replaces the breakers.
Measure the board, not the chargers. Charger meter values only see EV load. What moves a site's peak is everything else: lifts, pumps, compressors, hoists, apartments. A dynamic budget is the circuit's limit minus the measured non-EV load, per phase, read from a meter on the board. If that meter goes quiet, chargers should drop to a safe current rather than run on stale numbers.
Why are meters part of hardware-agnostic load management?#
Meters are the other half of hardware agnosticism. A controller that reads only one brand of meter, or only its own current clamps, locks a site in as firmly as one that controls only one brand of charger. The common open route is Modbus-TCP, which many commercial power analysers offer over Ethernet.
Reading a Modbus meter needs a register map: address, register type, data type, scale, and byte and word order. A preset bundles those for a known model. A configurable map, entered from the meter's manual, is what makes a controller genuinely meter-agnostic.
Two analysers from one maker show why. The Algodue UPM209 is a 4-module DIN-rail three-phase multifunction analyser; its Ethernet version speaks Modbus TCP [6]. The UPM309 is a 96 × 96 mm panel analyser, also available with Ethernet and Modbus TCP, rated class 0.5 to IEC/EN 61557-12 [7]. Their register maps differ, so a controller with only a UPM209 preset needs a configurable map to read a UPM309.
Both have "RGW" variants sold as kits with Rogowski coils, which suit retrofits. A Rogowski coil is a flexible, rope-style current sensor that opens around an existing cable or busbar, so "the user does not have to remove system parts" [8]. In a working switchroom that can avoid the shutdown solid-core current transformers would need. Fitting any sensor near live conductors is still electrician's work under the usual safety rules.
RS-485 (Modbus-RTU) meters can join a TCP-only controller through a Modbus gateway. Our guide to BMS integration over Modbus and MQTT covers the building side.
The exit test: could you point your chargers at someone else?#
The simplest test of a hardware-agnostic site is whether you could leave. An OCPP charger connects to whichever management system its connection URL points at, so a genuinely open charger can be re-pointed to another CSMS, keep authorising drivers and accept the new system's charging profiles, without the original vendor's involvement.
The catch: OCPP-J 1.6 leaves how a charger obtains that address "outside of the scope" of the specification [3]. It might be a local web page, an installer app, or a setting only the vendor's cloud can change. Ask which, and who holds the credentials. Re-pointing also drops anything proprietary, such as brand-specific balancing. Run the test on one charger at commissioning, while everyone is on site.
If you would rather keep an existing cloud CSMS and add site control, read OCPP proxy or on-site CSMS?
Where Nohmad Edge CSMS fits#
Nohmad Edge CSMS is an on-site OCPP 1.6J charge-point management system and load-management engine running together on one industrial PC at the site. It follows the vendor-neutral approach in this guide: standard OCPP smart charging to the chargers, open Modbus-TCP to the meters, and documented behaviour when either misbehaves.
- Chargers. OCPP 1.6J over WebSocket, Core and Smart Charging: any AC charger that implements OCPP 1.6J smart-charging profiles, single- or three-phase. A generic driver model means adding a charger model is a driver, not a fork. Unknown chargers wait in Pending until an operator approves them.
- Limits.
SetChargingProfile, with aTxProfilefor live sessions and aTxDefaultProfilefor idle connectors, re-allocated every 10 seconds (configurable 5–15 s). Each budget is the circuit limit minus the measured non-EV load, per phase where meters and charger phase mappings exist, otherwise on the worst phase. On connect it reads each charger'sChargeProfileMaxStackLeveland raises an alarm if the charger cannot hold the profiles it needs. - Offline fallback. It pushes an offline fallback profile (a
TxDefaultProfile, 10 A by default). If contact with the box is lost, a session already running keeps its last allocation; the fallback governs sessions without a transaction profile. - Misbehaving chargers. A charger that ignores its limit is clamped to 0 A, probed in steps, then reset (soft, then hard), with alarms. A charger silent for more than 300 seconds, or one that rejects a profile, has its bay clamped to 0 A with a critical alarm.
- Meters. A built-in Algodue UPM209 preset over Modbus-TCP (validated against an emulated meter so far). The UPM309 and any other Modbus-TCP meter connect through a configurable register map (address, data type, scale, byte order); there is no built-in UPM309 preset. Also an Eastron SDM630 preset; Modbus meters are polled every second by default. Shelly Pro 3EM meters publish over MQTT to the box's own broker. Modbus-RTU meters need a Modbus-TCP gateway.
- Tested so far. Simulators (120 chargers) and real chargers including an Orbis VIARIS UNI. There is no published compatibility list yet; if your plan depends on a particular charger model, ask us what has been tested.
- On the roadmap. OCPP 2.0.1.
Breakers remain the last line of protection; Edge CSMS manages load on top of them. It is available for early sites by enquiry. See Edge CSMS, the commercial and industrial and fleet and workshop solutions, or our partners page if you design or install these systems. For the cost side, read maximum demand and EV charging.
Sources#
These are the primary specifications and manufacturer documents behind the statements in this article. OCPP section numbers refer to OCPP 1.6 Edition 2 and OCPP 2.0.1 Edition 4, both published by the Open Charge Alliance, which also links its certification programme from the same page. Manufacturer pages were checked on 23 October 2026.
- Open Charge Alliance, OCPP 1.6 Edition 2: §3.3 feature profiles; §3.13 Smart Charging; §3.16 and §4.7 metering and
ConnectorPhaseRotation; §6.44SetChargingProfile.conf; §7.13–7.14ChargingSchedule; §9.4 smart-charging keys. - Open Charge Alliance, OCPP 2.0.1 Edition 4, Part 2, use case K03 Local Smart Charging; approval as IEC 63584 (2024).
- Open Charge Alliance, OCPP-J 1.6 Specification, §3.1.1 "The connection URL".
- Zaptec, OCPP within Zaptec.
- Beyond Logic, Prototype IEC61851 / J1772 EVSE Interface (control pilot duty cycle and the 6 A minimum).
- Algodue Elettronica, Three-phase network analyzer UPM209RGW.
- Algodue Elettronica, Three-phase network analyzer UPM309RGW.
- Automation World, Easy Retrofitting of Current-Measuring Technology, 9 July 2015.
Frequently asked questions
- What is dynamic load management for EV chargers?
- Dynamic load management measures the real load on a site's supply and adjusts each charger's current limit as that load changes, so the total stays inside the supply rating. Static load management splits a fixed capacity between chargers and never looks at what the building is drawing. Dynamic control usually fits more chargers on the same supply, because it uses headroom that fixed limits leave idle.
- Can I load balance different brands of EV chargers?
- Yes, if every charger implements OCPP smart charging and one controller manages them all. The controller sends each charger a current limit with the standard SetChargingProfile message, whatever the brand. Balancing built into one manufacturer's chargers or cloud usually coordinates only that manufacturer's units, so a mixed-brand site needs an OCPP-level controller instead.
- Does load management work with any OCPP charger?
- Not automatically. Smart Charging is an optional feature profile in OCPP 1.6, and chargers that implement it still differ in stack depth, rate units, phase handling and minimum current. Load management works with chargers whose Smart Charging implementation fits the controller's design, which is why a controller should read each charger's capabilities when it connects and raise an alarm when they fall short.
- What are OCPP 1.6 charging profiles?
- OCPP 1.6 defines three charging profile purposes. ChargePointMaxProfile limits a whole charger, TxDefaultProfile sets the default limit for transactions on a connector, and TxProfile limits one running transaction. Each profile carries a schedule of limits in amps or watts. Stack levels decide which profile of the same purpose wins, and the charger obeys the lowest limit across purposes.
- What meter do I need for EV load management?
- You need a meter on the supply or switchboard that feeds the chargers, measuring each phase, which the controller can read every second or so over an open protocol such as Modbus-TCP. Three-phase multifunction power analysers are typical. In existing switchrooms, analysers sold with Rogowski coils are often easier to fit, because the flexible coils open to wrap around a cable or busbar without disconnecting it.
- What happens if a charger ignores its load management limit?
- OCPP has no penalty for a charger that accepts a limit and keeps drawing more; the specification says an accepted profile does not guarantee the schedule is followed to the letter. A well-designed controller compares measured current with the setpoint, raises an alarm and cuts that charger's allowance until it behaves. Circuit breakers remain the last line of protection.
- How do I avoid vendor lock-in with EV chargers?
- Choose chargers that implement OCPP 1.6J Smart Charging, confirm that you, not only the vendor, can change the charger's CSMS address, and keep session and meter data in formats you can export. Then run the exit test on one charger: point it at a different CSMS and check that it connects, authorises a driver and accepts a charging profile.
- What is the difference between OCPP 1.6 and OCPP 2.0.1 for load management?
- Both versions limit charging with charging profiles sent from the management system to the charger. OCPP 2.0.1 adds smart-charging functions and a formal security model, and an edition of it was approved as international standard IEC 63584 in 2024. It is not backward compatible with 1.6, so a controller has to speak whichever version each charger actually runs.