duration parameter is buggy.

[seniskenis]

In documentation: "duration can be in the range of 1 to 5 and specifies how large window of consecutive hours to slide forward in search for a minimum average price."

in my case I don't need hours to be consecutive, it can be 02:00, 04:00, 05:00... etc.
so "duration = 1" would be good for me, but when is set to one, the sensor is always ON.

in case:

and duration set to 2 sensor starts at 02:00, but the good price is also at 00:00 so one hour remains unused.

can "duration = 1" bug be fixed or I'm doing something wrong, because it always on for me.

edit: after midnight strategy changed and with "duration=2" all consecutive hours from 00:00 to 07:00 were used, so this time it worked ok. but another problem happened in post bellow.

[seniskenis]

And totally wrong behavior on this set of data:
duration: 2
moving:
search_length: 24

[dala318]

Thanks for sharing, I have not been able to test this very much since it requires you to debug during specific hours of the day unless running it in a simulated environment which I have not found time to create.
As for my own use I'm not using this very much at the moment as boiler-room is under renovation and no wifi access to heat-pump at the moment, hence I have not been checking the result very much lately.

For the but I could imagine it could miss to check current_hour, hence duration=1 would give only one possible slot. Could also be related to #12 where it's off-by-one.

Cannot make any promises to investigate this now as I'm busy with the renovation but will keep in mind as soon as done.

[dala318]

Please check if release 0.2.3 fixes the issue with duration = 1

[CommanderROR9]

This appears to still be an issue even today...

[dala318]

From the last plot above I would say the following:
00:00-01:00 On -> Correct as the average price 00:00-02:00 likely the lowest
01:00-05:00 Off -> Correct as the average 05:00-07:00 lowest ahead
05:00-08:00 On -> Correct as price is continuously increasing and hence no cheaper average can be found in the future (the moving window does not look in the past)
08:00-09:00 On -> Questionable as visually I would say the average 22:00-24:00 look to be lower

[dala318]

With release of version 2 #45 I'm closing this as the code is completely rewritten. But feel free to reopen or create new issue if similar problem is still seen.