Power policies¶

This guide demonstrates configuring power policies to control how energy flows between elements and at what cost. Policies let the optimizer make better decisions by distinguishing the value of power based on where it comes from and where it goes.

What are power policies?¶

Without policies, the optimizer treats all power flows equally — a kilowatt from solar feeding the grid is the same as a kilowatt from the battery feeding a load. Policies add source-to-target pricing that tells the optimizer "power flowing from Solar to Grid costs $0.02/kWh" while "power flowing from Solar to Load costs $0.00/kWh."

This lets you model real-world scenarios like:

• Solar self-consumption: Free solar power to loads, but export has feed-in tariff costs
• Battery export control: Battery discharge to loads is cheap, but grid export is expensive
• Grid charging constraints: Grid power to the battery incurs a premium

Prerequisites¶

This guide builds on the Sigenergy System walkthrough. Complete that walkthrough first — the steps here assume your system is already configured.

Adding policies¶

Each policy controls one direction of power flow between elements. Click Policies to add each rule — subsequent rules are appended to the same subentry.

Step 1: Solar export pricing¶

Solar power sent to the grid earns only the feed-in tariff rate of $0.02/kWh, while solar power used locally by loads is free.

‹ 1 / 19 Click Policy target ›

Step 2: Battery export policy¶

This policy makes battery discharge to the grid expensive, encouraging the optimizer to save battery power for local use.

‹ 1 / 20 Click Submit target ›

Step 3: Battery to load policy¶

A low price indicates that using battery power for loads is preferred.

‹ 1 / 20 Click Submit target ›

Step 4: Grid charging policy¶

Price grid power flowing to the battery to discourage charging unless prices are low enough.

‹ 1 / 20 Click Submit target ›

Step 5: Verify and review¶

Validate that all policies were saved correctly, then open the reconfigure view to see them. The first two rules were created automatically: the battery added charge and discharge cost rules. The load leaves its consumption cost unset by default, so no consumption cost rule is created.

validate_policies(hass, expected_rules=[
    "Battery charge cost",
    "Battery discharge cost",
    "Solar to Grid",
    "Battery to Grid",
    "Battery to Load",
    "Grid to Battery",
])

‹ 1 / 2 Reconfigure gear ›

How policies affect optimization¶

With these four policies configured, the optimizer now has detailed cost signals:

The optimizer uses these costs alongside grid import/export prices to find the cheapest overall schedule. For example, if grid import costs $0.25/kWh, shipping solar to a load (free) is strongly preferred over importing from the grid.

Policy scope: where a rule actually applies¶

A policy like Solar → Grid: $0.02/kWh prices solar-originated power — but only while that power still carries Solar's provenance. Intermediate sinks (battery, load, grid-as-destination) terminate the provenance, so policies do not follow energy past them.

In practical terms:

• Junction elements (inverters, switchboard nodes with both flags off) pass provenance through. A policy can price the whole source-to-destination chain that runs through junctions.
• Sink elements (loads, battery-when-charging) absorb the provenance. Any onward flow from a sink is re-tagged by that sink's own identity, or becomes unpolicied.
• Storage elements (batteries) are both source and sink. Energy charged into a battery is accounted for separately from energy discharged out of it. Two policies are needed to price both legs — for example Solar → Battery: -$0.001/kWh (charge incentive) and Battery → Grid: $0.10/kWh (discharge export cost).

If you need to route policied flow through a junction, model the junction as a plain Node (with is_source=false and is_sink=false) and hang the real sink/source elements off it. See Node roles and policy scope for the full rules.

Next steps¶