Programmatic charger control

Programmatic charger control lets external software set power limits on your chargers and circuits through the Energy Management API, so charging can follow solar output, a battery’s state of charge, building load, or a signal from your own systems.

​

Overview

DLM distributes a fixed budget. Plenty of sites don’t have a fixed budget: the building draws power through the day, the roof produces some, a battery absorbs and releases more, and the amount left for chargers moves minute by minute. Deciding how much that is takes software that can see all of it — an energy management system, a battery controller, a smart meter integration, your own platform. Programmatic charger control opens that door. Spirii registers your software as an actor, grants it control over specific charge boxes and circuits, and from then on it can move limits up and down inside the boundaries Spirii enforces. DLM keeps distributing whatever the actor makes available, which is what the industry calls advanced dynamic load management (aDLM).

​

How it works

An actor works in two directions. Control requests go out over HTTP to a single endpoint that accepts every command type; the response only confirms the request was authenticated and queued, not that it was applied. The outcome arrives separately, as a message on one of the actor’s SNS topics, correlated by the request_id the actor chose. Spirii publishes results and telemetry to those topics: control responses, connector status updates, asset master data, and near-real-time power measurements. Four commands are available today: Every limit is temporary. Each request carries a valid_to timestamp, at least 15 seconds in the future, and when it passes the asset returns to its normal state on its own. A limit you forget to clear expires; a limit you want to hold has to be renewed. Requests are rate limited to one every 5 seconds, tracked separately for each asset and each action, which is roughly the time a charger needs to apply a profile and report back.

​

Choosing what happens to the capacity you release

When you cap a connector on a circuit running DLM, you decide what happens to the difference: Getting this backwards is the common mistake. Capping one connector with DISTRIBUTE while trying to cut site consumption achieves nothing: the power simply moves next door.

​

A worked example

A public CPO runs a DC site behind a battery that buffers the grid connection. The battery’s controller is registered as an actor and holds the circuit limit at 360 A, roughly 250 kW, while the battery has charge to give. When the battery’s state of charge drops below its threshold, the controller sends a circuit limit of 0 A and the chargers stop drawing until it recovers. Every request also carries a fallback: 43 A — about 30 kW, the level the grid connection can carry unaided — to apply 300 seconds after the request. If the controller goes quiet, or the meter it reads drops out, that fallback takes over five minutes later and the connection stays inside its limit without anyone intervening. The fallback is the part worth copying. Software that controls power has to fail safe, and the platform will hold that position for you rather than reverting to full capacity.

​

Options and configuration

Control is granted per asset. A charge box or circuit is subscribed to an actor, and the actor is told about it on its master data topic; unsubscribing sends the same message in reverse. One asset can be subscribed to several actors as long as they hold different capabilities — but two actors can’t hold the same capability on the same asset, because two systems setting the same limit would fight. Limits on connectors can be given in watts or amps. Where a conversion is needed, Spirii uses its own phase and voltage data for the connector unless the request overrides it, which is worth doing on sites where conditions fluctuate and precision matters.

​

When to use it

• A site with solar, a battery, or both. Your controller already knows how much power is available; this is how it tells the chargers.
• A grid connection shared with a building. Hold the chargers inside whatever the building isn’t using, and avoid a capacity charge or an upgrade.
• Your own optimisation logic. Priority rules, time-of-use strategies, or a model that beats the platform’s defaults for your operation.

Spirii’s own grid balancing service runs through this same mechanism, which is the clearest illustration of what it can carry.

​

Set up

Actor registration is done by Spirii, not self-serve.

​

Dependencies and limitations

• You bring the software. Spirii exposes the controls; the logic that decides what the limits should be is yours or your supplier’s.
• A limit is a ceiling, not a guarantee. It caps what a connector may draw. It doesn’t promise the vehicle will draw that much, and it doesn’t reserve capacity — DLM may still allocate less on a busy circuit.
• Circuit limits need DLM enabled on that circuit, and can be set between 0 and the configured circuit capacity. Without DLM, the request has no effect.
• Connector limits apply to live sessions. The connector has to be Charging, SuspendedEVSE or SuspendedEV. Setting a limit doesn’t itself start charging — a connector suspended by a schedule stays suspended.
• Hardware and user-set limits win. A control request can’t lift a connector above what the hardware or the operator’s own configuration allows.
• Active schedules override connector limits. Outside a schedule’s selected periods the effective limit is 0, whatever the actor asked for.
• The API sets limits; it doesn’t create schedules. Charging schedules are configured in Connect.
• Validated charger models only, assessed per model and per firmware version.

​

Related