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.
Congratulations on expanding the forecast! I think it’s fantastic that you’re tackling this topic. So far, the system is reacting exactly as I’ve long suspected. The accuracy of the price forecast is only of secondary importance. The higher the accuracy, the better, of course, and if the forecast is ever wrong, there will certainly be a lot of criticism. From my perspective, however, the advantages far outweigh the disadvantages. Particularly favorable periods are not only used for one day, but also for the highest prices of the coming days. Stored electricity is used more effectively because it takes anticipated high-price periods into account. Irregular consumption, such as charging a car, doesn’t immediately cause the plan to collapse for two reasons. Because the system considers an extra day, the probability that this consumption will occur during that time and thus be factored in is higher. Secondly, the system seems to take the high-price period for the following day into account and thus incorporates a certain reserve. This also makes the consideration of a specific DESS minimum SoC at least less of an issue. I will continue to follow the development with great interest.
I see you’re still struggling to find a solution for the extra minimum SOC for dess.
Still the best solution for that is that they just implement a extra SOC for dess, i don’t get why they do not have it yet.
They are using the minimum SOC that existed before dess, what had and still has a very different function than a minimum dess SOC. It’s about time they fix this the right way.
Please Victron, add a minimum SOC for dynamic ess, so the system can buy and sell on the minimum dess SOC, and the system can stop using the battery when the (old) normal minimum SOC has been reached.
Don’t you see any improvements from the changes made in the last few days? I think the current approach is much better.
One more small point. Simply defining a DESS Min SoC won’t suffice. Conditions must also be defined under which it can be accessed. And that’s precisely where things get complicated again and require further basic configurations. One user might say it can’t be sold below that level, while another might want it only accessible above a certain price. These are just two conditions that immediately come to mind.
That “problem” has nothing to do with the minimum dess SOC alone, if that is a problem, that will also exist when there isn’t a minimum dess SOC.
Dess is a new function they added, and with that new function comes a new SOC limit, the one that lets the system use the battery to a certain percentage to buy/sell.
That way there is room for the system to make mistakes, for me to use some days way more than other’s, and for the weather to change.
I don’t use the dynamic anymore, mainly because that extra SOC is missing, and forecasts were not great. Maybe the forecasts are now better, but i wait till they implement that missing function before i start trying to use it again.
Ahhh… you don’t use it anymore? Perhaps you should, in order to evaluate it. But well, everyone has to and can decide for themselves. Extending the forecast isn’t a new feature; it only extends the planning period. A DESS Min SoC, however, would be a completely new feature. For you, it would be right and important that no buying or selling occurs below that level. For the next person, it would be for unforeseen consumption, like with an electric car, and should be reserved for that purpose. I certainly understand what this DESS SoC is supposed to do; I’ve spent some time looking into it myself. My concern is simply that the configuration, which many already struggle with today, will become even more complex. Just read a bit in the forum, and then you might understand what I mean. Extending the forecast period won’t solve all the situations for which a separate SoC was often requested, but it significantly reduces the need for it. Test it out.