For several weeks now, I’ve observed that the VRM displays prices beyond the period of published real-world prices. I consider it a kind of price forecast based on historical data. Even though my observations suggest this is due to some issues with price transmission, I find the approach quite interesting and hope the development team continues to pursue it. I’m currently observing today, Sunday, November 9th, at 8:00 AM, how the system is charging for power it intends to use on Monday, even though no prices can be published for Monday yet. This behavior, by the way, I consider perfectly reasonable, because barring any significant weather changes, prices will be higher on Monday. Unfortunately, this little gimmick always ends on Monday evening. In the past, I’ve set the minimum state of charge (SoC) higher on Sunday and then lowered it again later when prices are available. I would personally very much welcome Victron continuing to explore this topic. I’m fully aware that this is a double-edged sword, because if the forecast is fundamentally inaccurate, the consequences can be very negative. Therefore, I’ve previously suggested adding a button to the basic configurations to indicate whether the user wants to use this function. I also imagine that this would secondarily resolve another issue. Here in the forum, there have often been discussions about a “DESS Min SoC” or “a special DESS consumption reserve” to cover unforeseen consumption. In my view, extending the forecast period—which is essentially what price forecasting is—would also mitigate this problem. Perhaps the collective wisdom of this forum has some insights on this as well.
I’ve also been watching this too for a while and given the fact that weekend prices are usually a lot lower it’s ok for me to have it active on weekends only because it usually will store as much cheap energy as possible until Monday leading to better overall efficiency for me.
And (see e.g. DESS next-day schedule based on simple price prediction) I would keep this very simple, with lookup tables being my favorite. E.g. the cheapest reasonable forecast for the next Monday would be the prices from last Monday. Can be made more fancy (with seasonal averaging, etc), sure, but I think it’s not worth the effort and there will always be complaints.
And for the matter of SoC reserve - I’d like to have 2 reserves: a min SoC reserve for cases of higher than expected consumption during high price periods (that’s something I have already covered with a homeassistant automation) - as well as a max SoC reserve for cases where there is more sun and/or less consumption to prevent unnecessary grid feed-in. But this greatly depends on the current season and specific installation parameters (battery size vs. PV peak power vs. daily average consumption) and for the generic user this would make DESS too complex, so this should be hidden behind kind of “advanced settings, don’t mess with them and then complain, you have been warned”.
Three thoughts on what you wrote. On Tuesdays, prices are usually similar to Mondays. So why not include an extra day? If, for whatever reason, prices are low on Monday, why not extend the electricity usage until Tuesday? It should be a smooth transition, similar to how it already works for Mondays. The forecast is currently expanding hour by hour. How far into the future should we test? We can certainly discuss 36, 48, or 60 hours. But I think it’s a shame to end it on Monday evening. Second thought… Since even with future forecasted prices, there will be very expensive periods, I could imagine the system automatically holding reserves for these times. Third thought… I would broaden the forecast and weight the data. I think we’ve already discussed this: 50% of the price for the previous week’s period, 25% of the price for the week before that. 12% of the previous week and perhaps 25% of the same period last year.
I utilize a nordpool electricity market price estimator Nordpool FI forecast and its Home Assistant integration for planning nightly target charge levels for our EV. I would love to be able to proxy the estimate data to DESS as well.