[Feature Request] Multi‑Objective Optimization with Peak Power Consideration

[matti-oss]

EMHASS provides a flexible framework for integrating forecasting and optimization into Home Assistant energy management workflows.
This proposal is a future topic of interest that could further expand EMHASS’s capabilities.

Motivation
The current EMHASS optimization framework focuses primarily on minimizing energy costs and maximizing self‑consumption. However, in many electricity markets, distribution companies apply additional charges based on peak power demand during a billing period. This means that even if total energy costs are minimized, a single high‑power spike can significantly increase consumer bills.

As highlighted in Multi‑objective optimization of energy systems (ScienceDirect, 2020), multi‑objective optimization approaches can balance competing goals such as cost minimization and peak load reduction. Incorporating this methodology into EMHASS would make the optimizer more grid‑friendly and economically robust.

Proposed Enhancement:

• Introduce multi‑objective optimization into EMHASS, where the solver considers both:
• Energy cost minimization (existing objective).
• Peak power reduction / load equalization (new objective).

A Pareto‑optimal solution set could be generated, allowing users to select trade‑offs between minimizing costs and reducing peak demand. This would:

• Equalize power loads across the optimization horizon.
• Reduce stress on the distribution grid.
• Lower peak‑related charges for consumers.

The user could control the operation using a relatively simple weighting rule, such as:

optimization_objectives:

• cost_weight: 0.7
• peak_weight: 0.3

Future impact
The support for grid‑friendly power management could become a positive differentiator for the EMHASS community. EMHASS could proactively balance loads on the consumer side and directly address the arguments often used to justify forced peak power tariffs.

[scruysberghs]

not sure how that would/could work. emhass optimisation window is typically 24 or 48 hrs while a billing period is monthly in most countries

max power from grid is already a constraint you can pass to emhass. You would have to calculate/predics the optimal valua for this once at the start of a billing period for your specific usage profile

[matti-oss]

Good point. For what it’s worth, monthly peak‑power billing benefits the utility. But if the goal is to maximize grid capacity, peak charges should be calculated daily. That way, one high‑use day doesn’t erase the incentive to manage consumption on the other 30 days.

EMHASS allows adjusting maximum_power_from_grid and re‑running the optimization with different values.
By sweeping this parameter, it is possible to approximate a Pareto frontier that balances peak grid power against
overall energy cost. In an MPC context, this balance would not need to be recalculated at every optimization step.
This provides a practical way to explore trade‑offs, though it remains a simpler approach compared to formal
multi‑objective optimization methods (e.g., evolutionary algorithms) described in
"Multi‑objective optimization of energy systems" (ScienceDirect, 2020).

[scruysberghs]

Good point. For what it’s worth, monthly peak‑power billing benefits the utility. But if the goal is to maximize grid capacity, peak charges should be calculated daily.

Interesting discussion. As we are optimising towards cost we are highly dependent on how the local utility provider and supplier organises this.

Here in Belgium we we have dynamic 15 minute pricing and something called capacity tariff where you pay around 5€ per kW per month for the 15 minute block in that month with the highest usage. So for example average usage 1kW per hour (24kwh a day, 720kwh/month) but one 15 minute block of 12kW and you pay ~60€ extra that month.
The optimal balance for this would be interesting to model. Higher peak means more consumption during the cheapest 15minute blocks. For the optimum you would have to model intraday price spreads and usage paterns at the start of the month for next month.

[matti-oss]

In Finland also 15min pricing and power tariff is applied by some utilities. I have still energy based utility tariff, but I suspect that increasing popularity of EVs will make peak power tariffs increasingly popular. I think EMHASS provides good basis for joint optimization of energy cost and peak power by scheduling deferrable loads and controlling continuous loads (such as many EV chargers).

[davidusb-geek]

Interesting discussion.

Scaling to full multi-objective optimization (Pareto fronts) would significantly increase computation times and I don't think we should go the route of global optimization problem as proposed in the given paper reference. For simplicity we should stick to a MILP formulation.

This does not means that we cannot add more use cases just as this Peak power case.

Maybe we could add a configurable Capacity Cost parameter:

1. If you have a monetary cost for peaks, you enter the price (EUR/kW).
2. If you just want to minimize peaks for technical reasons, you enter a very high virtual price.

We can add this either as an additional term to the main cost function or new constraints. This could allow the solver to balance 'Cost of Energy' vs. 'Cost of Peak' in a single mathematical pass, keeping EMHASS fast.
Open to any point of views...

[scruysberghs]

could allow the solver to balance 'Cost of Energy' vs. 'Cost of Peak' in a single mathematical pass, keeping EMHASS fast

is indeed possible but that would mean the optimal peak power would be calculated for the EMHASS optimisation window only, see my first remark. Is only possible if peak cost is calculated on a daily basis (I agree with @matti-oss that peak charges should be calculated daily but sadly, this isn't the case in most places)

My current plan is to use emhass to build a regressor model to calculate the optimal "max_power_from_grid" at the end of a billing period (month) value and use that value in emhass mpc for the comming month. (influxdb support was a first step towards that)

This is actually about the same discussion as in #630 and #540