I recognize the phenomenom. It’s somewhat related to the cold winter days here in the North where we could have cheaper hours coming in the evening but to prevent too big cooling, we need to allow some heating during the day. And when this is needed, it makes sense to find the local minimum from the daytime.
So this comes back to the fact that the optimization problem has multiple objectives: comfort and price optimization.
Coming back to the concrete topics and questions.
We know as a fact that Nordpool publishes the day-ahead prices at 12.45 CET/CEST. We also know that the data is usually available at API endpoints like Entso-E at 13.15 CET/CEST. Thus, the price fetching is typically scheduled to occur in the afternoon. The calculations can conceptually be modified somewhat trivially so that it does the optimizations from “now” until the end of the price window.
For the “prevent too much cooling” dilemma, this can be addressed in different ways.
One is of course to use a less intrusive control strategy where the device can work with its own internal logic which is usually based on feedback loop from temperature sensors. This optimizes the comfort in favor of price.
A second approach could be to define a number which defines the max not-allowed heating period and then find local minimums from prices.
A third one is almost the same i.e. the slicing concept of my solution that we have discussed already many times in this thread.
I’m sure combinations of these exist. If for example we can make a safe assumption that we have reliable indoor temperature measurements, then this “let’s kick in the prevention of too much cooling” logic could be wired to the current indoor temperature, current outdoor temperature, weather forecast (temperature and cloudiness being significant factors, wind speed to some extent) and spot prices. It’s a balance between complexity and the optimization objectives.