Replies: 1 comment 1 reply
-
Hello. This is by design. The main reason is because the number of hours is how many they request. If someone wants 3 hours and the sensor gives them 2, then they'd consider this a bug. The other is if all rate info is not available (e.g. agile is only available after 4pm up to 11pm CET for the next day), then when it becomes available this can cause a different set of rates to be picked. This can potentially cause the sensor to come on for longer than requested. For example if your sensor is set to look at 4pm to 4pm with a max rate of 13p and you have the following data. ... If agile data doesn't provide the following data until after 20:00 (e.g. data is running late, there's an issue with the API or some other issue that causes a delay in retrieving information) 23:00-03:00 = 10p In this scenario, the sensor will turn on during 19:00-20:00 and then again between 23:00-02:00 as the sensor will recalculate this to be the best times. This can cause confusion when looking at the history as the sensor will come on too much. If it only recalculates for the missing hours, then this too will look bad in the history as it will look like it didn't pick the best times. I've raised #895 as you're not the first person to request partial matches, so upvote that please :) |
Beta Was this translation helpful? Give feedback.
-
I have sensor set up to choose the cheapest Agile slots for a 2 hours intermittent charge over night. Works great. If I specify a max rate of say 13p per unit it will continue to work providing there are sufficient (4) slots below 13p. However, if it find for example, only 1 slot below 13p it won't trigger at all. I'd prefer to use that one slot if it's below the max rather than none at all. Is there any way to achieve this or could it be added as an option? Thanks
Beta Was this translation helpful? Give feedback.
All reactions