SumConsumer planning (heater with wire-control) is not coherent with user requests

[Jaxom99]

I fear this issue is dependent on #4 being completed. The problem here is : heaters are not heating as much as requested by the user.

In ELFE, a wire-controlled heater (with eco and comfort modes) is designed to be set up with a "forced eco mode ratio". This ratio is defined in EMS docs as "temps confort sur période de chauffe souhaitée.". But it has been set up in other tools (front-ends...) as "Pourcentage de mise en mode éco forcée".
So we must first clarify: which one is it ? how is the value taken into account by the EMS ?

But the real issue is : independant from the ratio asked, the heater is cut for a longer time than authorized.
The initial demand is that for each consecutive 60min, the ratio is verified. So for a 25% eco-mode ratio, over 120 min you may have :

• 1 1 1 0 1 1 1 0
• 1 1 0 1 1 1 0 1
• but not 1 1 1 0 0 1 1 1

Here is an example from last run :

• heater confort period is 08:00 to 18:00
• ratio is 25%
• at 7:45, the heater constraints are built by the EMS as follows :
  SumConsumer(id=515, conso_low=800, conso_high=1000, sum_periods=[SumPeriod(beginning=1705474800, end=1705478400, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705475700, end=1705479300, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705476600, end=1705480200, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705477500, end=1705481100, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705478400, end=1705482000, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705479300, end=1705482900, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705480200, end=1705483800, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705481100, end=1705484700, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705482000, end=1705485600, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705482900, end=1705486500, expected_sum_min=3, expected_sum_max=4), SumPeriod(beginning=1705474800, end=1705510800, expected_sum_min=30, expected_sum_max=40)])

=> We see constraints for 7 following periods of 60min, and for the total heating period, but it lacks many ! After 10:15 to 11:15, no more constraints are edited by the EMS. How come ?

As a result, the output planning of the solver is : 352666 2024-01-17 08:00:00 515 1 151 1 1 1 1 1 1 1 0 1 1 1 0 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

So we see a 2 hours eco period in the middle of the day, that is not coherent with the user settings 😿

[laenNoCode]

will investigate ASAP. Does it appear after several scheduling and starting to consume or not ? It may be an error I made when accounting for the allready scheduled consumption

[Jaxom99]

No, it does happen even on the first cycle, on the first day of "controlling" from ELFE.

For example, the request was 8-10am as confort, with 25% flex ratio : we can see the 2 consecutives "decisions0 = 0" over the period :

308870	2024-01-04 08:00:00	421	1	151	1	0	1	1	1	0	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
308907	2024-01-04 08:15:00	421	1	151	0	1	1	1	0	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0
308944	2024-01-04 08:30:00	421	1	151	0	1	1	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	0
308981	2024-01-04 08:45:00	421	1	151	1	1	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	1	0
309018	2024-01-04 09:00:00	421	1	151	1	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	1	0
309055	2024-01-04 09:15:00	421	1	151	1	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	1	1	0
309092	2024-01-04 09:30:00	421	1	151	1	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	1	1	1	0
309129	2024-01-04 09:45:00	421	1	151	1	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	0	1	1	1	1	0	0	0

[Jaxom99]

I tried to look at the code in ELFE_data_gatherer.py, it seems to create all periods with constraints (when ratio = 0,25, 1h periods with min=3 max=4)

So I guess the error (setting a SumPeriod inferior to min_sum) is in the problem-builder ?

[laenNoCode]

I think the error is inside the handling of past data, so the first run should provide a fitting schedule but the next seems not to take the past into account. Having most period constraints min = 3 max = 4 is completely normal as they are meant to ensure that the heater is not off for too long

[Jaxom99]

Any news on this bug ? 😺
I'm available to help with debugging...