Hi FilipAngwald,
The standard way to model something like this would be to attribute the cost of the peak load to an investment into the capacity of the Glow leaving the Source (see https://oemof.readthedocs.io/en/features-add_nonconvexinvestmentflow/api/oemof.solph.html#oemof.solph.blocks.InvestmentFlow). However, it just minimizes the highest peak(s). So, let’s say, if the peak load in February might be reduced further then the one in January, this would not be done using the standard demand rate implementation.
If you just want to use components that are around at the moment, this would mean
a) you can run one optimization per month, or
b) add one source for every month.
The second option has the clear advantage, that it does not “forget” the status of the storage between the months, but if you have a lot of cycles, the error made in a) might not justify the effort of b).
A third option would be to add a custom component that lets you price the peak in a given time frame that is smaller than the total simulated time.