add static grid limit as load management restriction

[ekkea]

Fix #23

• added optional limits for grid import and export to interface
• added optional demand rate parameter for excess power beyond the import limit
• both limits accept violation if there is no physical solution otherwise. See also discussion below.

TO BE DISCUSSED:

• how shall we deal with cases where the import limit gets violated?
  • return infeasible
  • return a specific flag
  • return a time series of the excess power drawn
  • reduce demanded charging first, then one of the above options
• how shall we handle the case that a given export limit gets violated (typically caused by high solar yield)
  • consider that in those cases the solar power is reduced to match the limit. Always return a time series giving the actual solar power produced (ft - p_exp_pen).
  • return infeasible
  • ???

[andig]

how shall we deal with cases where the import limit gets violated

Imho that's infeasible?

how shall we handle the case that a given export limit gets violated (typically caused by high solar yield)
Always return a time series giving the actual solar power produced (ft - p_exp_pen).

Shouldn't we return grid feed-in series then? Or generally (as we already do) just return the grid series? Imho this should not be infeasible but rather best effort.

[ekkea]

how shall we deal with cases where the import limit gets violated?
Imho that's infeasible?

I agree in principle but from the user perspective, wouldn't it be good to get a feedback like "power demand 2.5kW above grid power limit at 12:15" rather than "infeasible"? If yes, we could return a specific status code for this kind of violation and additional data on time step and magnitude.

Shouldn't we return grid feed-in series then? Or generally (as we already do) just return the grid series? Imho this should not be infeasible but rather best effort.

Agree, it should be best effort, not infeasible. We can return whatever you prefer. I was thinking it may be valuable information for the user to see the lost solar potential from such power limits (solar forecast vs. usable solar power). But of course you can still compute that on the evcc end as well, as long as you have the computed grid power time series. You decide.

[andig]

Good point. Add something like "grid limit violated"? We'd still need to make sure that the openapi spec supports that and it's treated as success. Maybe let's add this as result "hints" and keep the CBC optimizer result as-is?

[ekkea]

@andig, please have a look at what I added: the result now has flags whether limits were hit / exceeded and additional time series reporting the overshoot per timestep.

[ekkea]

Note: there is a bit more work to finalise this PR even if we all agree on the features added:

• the option to consider a given demand rate beyond a certain input power will work correctly but the result returned will look like a limit violation.
• the objective value is now loaded with penalties that can influence the value quite a bit if they kick in. If you actually use the value, I'll have to correct it before returning the result.

[ekkea]

I will do more testing, however, I think we are good for a review from evcc side whether the interface (specifically the result reporting) makes sense from the caller's perspective.
Let me know if there is need to improve ;-).

[ekkea]

@andig , I'm done with testing, fixing and cleaning up. Ready for merging from my point of view.

[ekkea]

I'll take care of the changes later tonight

[CiNcH83]

@ekkea
Latest version of evopt prints quite some numbers in the log. Guess it is due to this print statement?

[andig]

Please propose removal

[CiNcH83]

Suggested change

print(clean_objective)

[andig]

Too late to do here. Needs PR!

[CiNcH83]

#39