Fallback schedule with all 0 values instead of best effort to reach impossible target

[ArdJonker]

Context:
Request a schedule with current SoC: 36% (of 59 kWh)
Target (calendar item) 80% within two hours (unreachable).

Result:
Fallback schedule with all 0 values.

Expected result:
Schedule that starts charging with maximum power to get as close as possible to the unreachable target.

---

Schedule id: f2bebb17-b17b-4605-aaba-1d1c02aea8cf

Trigger message:
2024-03-05 15:12:59.717814 INFO flexmeasures-client: Trigger_schedule on url 'https://seita.energy/api/v3_0/sensors/99/schedules/trigger', with message: '{'start': '2024-03-05T15:15:00+01:00', 'flex-model': {'soc-at-start': 21.24, 'soc-unit': 'kWh', 'soc-min': 10.62, 'soc-max': 59, 'soc-minima': [{'value': 47.2, 'datetime': '2024-03-05T16:00:00+01:00'}], 'soc-maxima': [{'value': 47.2, 'datetime': '2024-03-05T15:15:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:20:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:25:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:30:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:35:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:40:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:45:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:50:00+01:00'}, {'value': 47.2, 'datetime': '2024-03-05T15:55:00+01:00'}], 'roundtrip-efficiency': 0.85, 'power-capacity': '5750W'}, 'flex-context': {'consumption-price-sensor': 90, 'production-price-sensor': 91}}'.

[Flix6x]

Thanks for reporting this with the flex-model attached.

Our fallback policy is implemented here. It prioritizes getting as close as possible to the first equality target. If there are no such targets, it checks whether the current SoC exceeds the first maximum (if so, it discharges down to this maximum), and if that is not the case, it checks whether the current SoC is under the first minimum (if so, it charges up to this minimum).

Your app used to create soc-targets from calendar items, but has since some time switched to using soc-minima.

What I think happens is that the fallback policy first sees no equality target in the device constraints, then picks out the first maximum (that is, 47.2 kWh, from your soc-maxima) and sees that the current SoC is already below it, then picks out the first minimum (that is, 10.62 kWh, from your soc-min) and sees that the current SoC is already above it, and therefore it stands idle.

For a quick workaround, revert to using soc-targets instead of soc-minima, so the fallback policy picks up on the target that is set in the calendar item.

Follow-up: the fallback policy should look further for the first SoC min/max that can't be reached in time, taking into account the power capacity, the conversion efficiency and storage efficiency. The integrate_time_series method in this module should be used for this.

[nhoening]

Would this issue be resolved by #932 , @Flix6x ?

[Flix6x]

Yes, relaxing the storage constraints, particularly the soc-minima, should also resolve this issue.