feat: add ProcessScheduler

[victorgarcia98]

Description

Following the code in E-mission, this PR introduces a new scheduler that can schedule flexible loads. The ProcessScheduler implements the logic to schedule three different types of loads. Optionally, the user can specify a series of time restrictions (defined as a start and duration pair) where the load cannot be schedule to, in other words, the load cannot be ON during the course of any the time restriction.

This class handles three type of loads:

• Inflexible: scheduled as soon as possible
• Breakable: can be split into multiple blocks that don't need to be connected.
• Shiftable: can be scheduled at any time within the planned windows, respecting the time restrictions.

Tests

This PR includes tests for the following features:

• The ProcessSchedulerModelSchema in flexmeasures/data/models/planning/tests/test_shiftable_load.py
• The ProcessScheduler in flexmeasures/data/models/planning/tests/test_shiftable_load.py

[nhoening]

Thanks for this!!

I have yet to review the intelligent part, but I already have some comments about the modeling and documentation.

Also, I believe this scheduler deserves a dedicated CLI command.

And I believe we should add one simple integration test in api/v3_0/tests/test_sensor_schedules.py, to see that this scheduler can be used via the API, with the job queue involved.

[nhoening]

In services.scheduling.find_scheduler_class we should look up this class if the asset type is LoadType.

Then, this scheduler doesn't require custom configuration of scheduling like you did in #768:

{"custom-scheduler": {"class": "ShiftableLoadScheduler", "module": "flexmeasures.data.models.planning.shiftable_load"}

This should be one of our batteries-included schedulers which just works.

[nhoening]

In services.scheduling.find_scheduler_class we should look up this class if the asset type is LoadType.

Just a note on this:

While we should do what I said above in this PR, the real solution should be that Asset Types can specify what scheduler class should be used for them. That should be its own PR, probably.

I might start a discussion, as I don't know what I really meant with "logic store" in the code comment, and looking up logic/algorithms might get a new representation after our work on reporters.

[nhoening]

I do have some wishes here but this looks close to ready to me!

[victorgarcia98]

I might start a discussion, as I don't know what I really meant with "logic store" in the code comment, and looking up logic/algorithms might get a new representation after our work on reporters.

Good point!

In the context of DataGenerators (PR #751), the scheduler type would go in the DataSource. I think this is convenient as we can have multiple scheduler for the same asset.

[nhoening]

Moving forward, thanks!

See also my inline comment about doing the feasibility check in another way.

[nhoening]

I found some mentions of consumption-price-sensor which we can do without, or whoch shluld be moved.

[nhoening]

I might start a discussion, as I don't know what I really meant with "logic store" in the code comment, and looking up logic/algorithms might get a new representation after our work on reporters.

Good point!

In the context of DataGenerators (PR #751), the scheduler type would go in the DataSource. I think this is convenient as we can have multiple scheduler for the same asset.

Just as an addendum from our conversation today: Multiple schedulers per asset is not the standard use case. It's an edge case. I'm careful with starting modeling sketches with the edge case, as it's confusing for users/developers.

[nhoening]

I actually have one more renaming request (if you agree), sorry :)

Otherwise this is it IMO

[nhoening]

I approve, with one more tiny wish!