Grid power target

By default the algorithm balances the grid connection to 0 kW: it steers the battery so that as little energy as possible flows in either direction. The grid power target moves that setpoint. Instead of aiming at zero, the algorithm aims at a small standing import, and holds the connection there.

This is a specialist setting. On an ordinary installation the right value is 0 kW, which is the default and keeps the behaviour described under self-supply and cost optimization unchanged.

The problem it solves

On some sites a third-party device caps the solar production to prevent injection into the grid. That device holds the connection at roughly zero export, which caps production at whatever the site consumes at that moment. This creates a deadlock: the algorithm measures no surplus, so the battery stays empty, and without extra consumption the device never releases more production. The energy that could have been harvested is lost, and the measurements do not show it.

How it works

Every control cycle the battery charges the target on top of the measured surplus. The connection then shows import, the external device sees room and releases more production, and the measured surplus rises by that amount. The next cycle repeats the step.

The result is a ramp that runs at whatever rate the external device actually follows, because the battery only ever gets ahead of it by the target. It also ends by itself: once production can no longer follow, the import stays at the target and the correction becomes zero. The whole cost of keeping it there is a standing import of at most the target.

flowchart LR
    A["Battery charges target plus measured surplus"] --> B["Connection shows import"]
    B --> C["External device releases more production"]
    C --> D["Measured surplus rises"]
    D -.->|"next cycle"| A

Only while producing

Grid power target only while producing caps the target at the current on-site generation. This is switched on by default, and it is what the curtailment case needs: with no production there is nothing to release, so the target drops to 0 kW and the algorithm balances to zero as before, instead of buying the target hour after hour through the night.

The cap follows generation continuously rather than switching on and off at a threshold. Generation below the target still starts the ramp, because every step releases more production, which in turn raises the cap.

Switching the option off holds the target around the clock. Only do that on a site that wants the import bias regardless of production, and be aware that it will import the target at night as well.

How it affects the dead zone

The dead zone moves along with the target: the algorithm leaves the battery alone while the connection is within the dead zone of the target, not of zero.

If the dead zone were wider than the target, it would contain 0 kW, which is where the site rests before any correction. The first correction would then read as "already there" and balancing would never start. So the algorithm narrows the dead zone to at most half the target when needed.

Limits

• The target is capped at the grid import limit of the project. A target beyond that limit would be a permanent limit violation.
• Only import targets are supported. Injecting on purpose is driven by prices and trading signals rather than by a balancing offset, so a negative value is treated as 0 kW.

Worked example

A site with a 2 kW target, solar production capped by an external device, and a load of 20 kW:

Each cycle the external device answers the extra import by releasing 2 kW more production, which the battery stores. The connection stays at the 2 kW target throughout, and the ramp stops by itself when production reaches its ceiling.

Where to configure it

The field sits under Configuration → Strategy, next to the dead zone. See project settings for the fields themselves.

See also

• Self-supply: the strategy this target works within.
• Peak shaving reserve: the other way to limit grid import.