Suggestion for ps-strategy-lowest-price, Schedule not calculated

[CirruZZ]

The document states this regarding Schedule not calculated

If you select a period for example from 10:00 to 02:00, it may not be possible to calculate before the period starts. This is because electricity prices for the next day (in the Nord Pool area) normally are received around 13:00. The node cannot calculate the period until it has price data for the whole period.

I would suggest that it should try to get a schedule based on the precis it receives even if it is commanded to get lowest prices for a temaperiod that isn't complet with price data.

Example
Price data for 00-24 is given
Timeperiod asked for lowest price 18-04
Runtime 10:00

Today it gives Schedule not calculated

Why not just instead give lowest price for just 18-00?

[krispek]

I agree on this, based on a different use case. I would like to charge my EV at night, somewhere between 18:00 and 6:00. This leads to the following config:

fromTime: 18
toTime: 6
hoursOn: "4"
maxPrice: null
doNotSplit: false
sendCurrentValueWhenRescheduling: true
outputIfNoSchedule: false
outputOutsidePeriod: false
outputValueForOn: 0
outputValueForOff: 1
outputValueForOntype: "num"
outputValueForOfftype: "num"
override: "auto"
contextStorage: "file"
hasChanged: true

But this one does not work after midnight, since not all the price data is known.

[ottopaulsen]

@krispek It should work by 18:00 if you receive prices around 13:00, so I cannot see that you actually have a problem there.

@CirruZZ Your suggestion raises some logical challenges.
Let us say you ask for 2 hours on between 10:00 and 02:00. You haven't gotten any prices for next day, but for the current day, the cheapest hours are from 10:00 to 12:00, so you turn them on. Then at 13:00 you get prices for the next day, and from 00:00 to 02:00 it is even cheaper. What should you do then? Turn on another 2 hours? No, that would be wrong. Do not turn on? Then you didn't get the 2 cheapest hours, so that is also wrong. I guess I will meet multiple such dilemmas if I start coding this feature, and of course, they could probably be solved by giving the user even more options to choose from, but then it is starting getting really complex, opening for misuse, misunderstanding and bugs, so no, I am sorry, I will not implement this feature, at least not yet.

[krispek]

I checked my own flow again and found a bug indeed. My mistake. :)

[CirruZZ]

Your suggestion raises some logical challenges. Let us say you ask for 2 hours on between 10:00 and 02:00. You haven't gotten any prices for next day, but for the current day, the cheapest hours are from 10:00 to 12:00, so you turn them on.

This is what I suggest.

Then at 13:00 you get prices for the next day, and from 00:00 to 02:00 it is even cheaper. What should you do then? Turn on another 2 hours? No, that would be wrong. Do not turn on? Then you didn't get the 2 cheapest hours, so that is also wrong.

Nothing should happen, just keep the previous schedule as is. If the user wants a updated schedule the a new request for a schedule should be run when the new prices is available.

I guess I will meet multiple such dilemmas if I start coding this feature, and of course, they could probably be solved by giving the user even more options to choose from, but then it is starting getting really complex, opening for misuse, misunderstanding and bugs, so no, I am sorry, I will not implement this feature, at least not yet.

I see no reason to overcomplicate it, no more logic needed. Just "work with what you have" regarding the prices.

If some other feature, then previous stated, could be considered is some information to the user that the prices given isn't complet for the requested periods, maybe a status message? But this is just a idea, no need realy.

[ottopaulsen]

Your suggestion will break the whole concept with the Lowest Price strategy. If I implement what you suggest, the node will no longer find the lowest price in the selected period.

[CirruZZ]

I do not agree. The node would still work as it should, just that it doesn't have all the priceinformation available, and therefore try to make the best of the situation.

If the user does not provide the node with enough information to solve the task, it should be up to the user to take responsibility for that, and also realize that the node cant guess the future.

That's how I see it ;-)