Context & Problem Statement
The FlexMeasures StorageScheduler optimizes battery dispatch based on electricity prices, forecasts, and per-device flex_model constraints — but it has no mechanism to model the physical electrical topology of a site. Specifically, it does not propagate capacity constraints from parent assets (e.g., an inverter) down to its children (e.g., PV arrays, battery).
In a typical Helios residential site (e.g., the Rasolar installation), the topology looks like this:
Distribution Board
└── Hybrid Inverter (2.5 kW AC capacity)
├── PV Array East (1.5 kWp)
├── PV Array West (1.5 kWp)
└── LFP Battery (5 kWh, 2.5 kW DC)
The inverter is a shared AC bottleneck. All downstream devices must share a single 2.5 kW AC connection. When the sun produces ~2 kW and the scheduler simultaneously commands the battery to charge at 2 kW, the combined 4 kW exceeds the inverter's physical capacity. The resulting schedule is physically infeasible.
Observed behavior: FlexMeasures produces schedules where P_pv + P_battery > P_inverter_max, because each storage device is optimized independently against site-level constraints only. There is no shared-resource constraint linking sibling assets under a common parent.
Impact:
- Schedules cannot be executed on real hardware without clipping or violating inverter limits
- Battery cannot follow the planned dispatch during peak solar hours
- Solar energy is curtailed unnecessarily when PV alone saturates the inverter
- Planned cost savings are never realized because the schedule is infeasible
Open Questions
- Does FlexMeasures have any upstream plans or RFCs for shared-resource / parent-child constraint propagation?
- Is post-optimization clipping pass (reducing battery setpoints to fit inverter headroom) acceptable as an interim measure, or does it compromise too much schedule optimality? How does fm currently tackle this issue
Context & Problem Statement
The FlexMeasures
StorageScheduleroptimizes battery dispatch based on electricity prices, forecasts, and per-deviceflex_modelconstraints — but it has no mechanism to model the physical electrical topology of a site. Specifically, it does not propagate capacity constraints from parent assets (e.g., an inverter) down to its children (e.g., PV arrays, battery).In a typical Helios residential site (e.g., the Rasolar installation), the topology looks like this:
Distribution Board
└── Hybrid Inverter (2.5 kW AC capacity)
├── PV Array East (1.5 kWp)
├── PV Array West (1.5 kWp)
└── LFP Battery (5 kWh, 2.5 kW DC)
The inverter is a shared AC bottleneck. All downstream devices must share a single 2.5 kW AC connection. When the sun produces ~2 kW and the scheduler simultaneously commands the battery to charge at 2 kW, the combined 4 kW exceeds the inverter's physical capacity. The resulting schedule is physically infeasible.
Observed behavior: FlexMeasures produces schedules where
P_pv + P_battery > P_inverter_max, because each storage device is optimized independently against site-level constraints only. There is no shared-resource constraint linking sibling assets under a common parent.Impact:
Open Questions