**Describe the bug**
When scheduling my dishwasher I reduce the `def_total_hour…s` by runtime. I reduce it every 0.5 hours (-1 timestep). I set `def_end_timestep` = `def_total_hours * 2`. I expect that the result schedules the deferrable load one by one for 6 timesteps (3h to run). Each 30m the hours will be reduced by 0.5 and the timesteps will be reduced by 1. Nevertheless there are gaps in some of the calculations. The gaps do not happen when `def_end_timestep` is not set OR when its set to a higher value e.g. 12.
Long story short: I like to make EMHASS know that the dishwasher is running and that the energy is needed, therefore I need to use `def_end_timestep` to force it to this given timeframe otherwise it will schedule the "hours to run" somewhen later which makes no sense in this case.
**To Reproduce**
1. iteration def_total_hours = 3, def_end_timestep = 6
```
curl -i -H "Content-Type: application/json" -X POST -d '{
"load_cost_forecast": [0.2554, 0.2536, 0.2536, 0.2484, 0.2484, 0.2459, 0.2459, 0.2452, 0.2452, 0.2442, 0.2442, 0.2435, 0.2435, 0.2462, 0.2462, 0.2511, 0.2511, 0.2584, 0.2584, 0.2695, 0.2695, 0.2708, 0.2708, 0.2662, 0.2662, 0.2607, 0.2607, 0.2557, 0.2557, 0.2517, 0.2517, 0.2512, 0.2512, 0.2556, 0.2556, 0.2618, 0.2618, 0.2665, 0.2665, 0.276, 0.276, 0.2759, 0.2759, 0.2624, 0.2624, 0.2563, 0.2563, 0.2474],
"prediction_horizon": 36,
"pv_power_forecast": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 408, 798, 1200, 1608, 2330, 4349, 5582, 5938, 5293, 4092, 3819, 3779, 3645, 3471, 3129, 3126, 2708, 1445, 758, 274, 0, 0, 0, 0, 0, 0, 0],
"alpha": 0.75,
"beta": 0.25,
"num_def_loads": 3,
"def_total_hours": [
0,
3,
0
],
"P_deferrable_nom": [
2750,
2000,
2200
],
"treat_def_as_semi_cont": [true, true, true],
"set_def_constant": [true, true, true],
"def_start_timestep": [
0,
0,
0
],
"def_end_timestep": [
0,
6,
0
]
}' http://localhost:5000/action/naive-mpc-optim
```
now reduce the `def_total_hours` and `def_end_timestep` each 30 minutes:
2. iteration: 2.5 / 5
3. iteration: 2 / 4
4. iteration: 1.5 / 3
5. iteration: 1 / 2
6. iteration: 0.5 / 1
**Expected behavior**
In each iteration the loads should be scheduled without any gap!
**Screenshots**
## 1. iteration (`def_total_hours`=3, `def_end_timestep`=6)
=> Not ok, gap between timestep 1 and 3, last timestep is doubled up (4000 W instead of 2000 W)
## 2. iteration (`def_total_hours`=2.5, `def_end_timestep`=5)
=> Not ok, gap and double watts
## 3. iteration (`def_total_hours`=2, `def_end_timestep`=4)
=> Ok
## 4. iteration (`def_total_hours`=1.5, `def_end_timestep`=3)
=> Ok
## 5. iteration (`def_total_hours`=1, `def_end_timestep`=2)
=> Not ok, second timestep is scheduled to the very last element (+18h)
## 5. iteration (`def_total_hours`=0.5, `def_end_timestep`=1)
=> Ok
**Home Assistant installation type**
- Home Assistant OS
**Your hardware**
- OS: HA OS
- Architecture: amd64
**EMHASS installation type**
- Add-on
**Additional context**
When not using `def_end_timestep` the calculation is done like expected in "one go":
3 hours:
2.5 hours:
1 hour:
When using a greater `def_end_timestep` it works like expected, too:
2.5 hours, def_end_timestep = 12:
1 hour, def_end_timestep = 12:
