Another Strange DESS behaviour

We’re getting a bit off topic here, and I actually just wanted to help with a specific problem. I’ve been following the development of DESS more or less actively for two years now. I’ve seen so many supposedly simple solutions that solved a small problem but opened up whole new problem areas. So I doubt it’s going to happen when an entire army of hobby developers is tinkering with the system. Similar failed attempts appear from time to time in the Nodered area. But of course, everyone is free to develop their own software and control solution; why should Victron make what has been achieved so far available for this purpose is beyond me. Incidentally, I’m also following the attempts of other professional manufacturers with some amusement. Their problems remind me a lot of the beginnings and initial problems with DESS. And I don’t want to comment any further on this thread. Nevertheless, an interesting aspect has just been mentioned: forecasts for several days!!! That’s the next step for me. So far, DESS has only considered the period for which prices are actually available. A price forecast for the following days would be one possible solution. In my opinion, it could also be an average price from previous weekdays. The exact price would actually be secondary; the decisive factor would be the timely detection of under- and over-coverages in PV production. However, I can also understand that Victron is currently concentrating solely on times when prices are available and the DESS can be calculated mathematically correctly.

This has been discussed before, and is certainly a promising idea that would help solve one of the most blatant idiosyncrasies of DESS: always targeting minimum SoC at the end of the known price schedule. Which is, in DESS trade at least, a complete disaster because that is as always at midnight of the next day and therewith predictably always wrong.

I’m fully aware of that. There’s a problem, though. These future prices are pure speculation and dependent on many factors, including weather conditions across Europe. The whole thing would be difficult to derive using mathematics or algorithms. As a manager at Victron, I wouldn’t want to step into that snake pit. Any potential loss, no matter how small, would be blamed on this forecast. And please, please don’t tell me that won’t happen; I’ve been in this industry too long and have read too much in this forum.

In pretty much every possible scenario, that is a very unrealistic value that will end up in excessive battery wear.

That’s not true, there are very distinct patterns that, if even rudimentary implemented as a speculative forecast, would instantly provide better scheduling. To name a couple almost to obvious to mention:

  1. the average dayly price of the 1st upcoming day of which prices are not yet known, will be much closer to that of the last known day then that it will be to zero. Same goes for the low/high price deviation from the mean.
  2. the highest price hours of the 1st upcoming day of which prices are not yet known will most likely occur twice dayly, around breakfast and around dinnertime or a little bit later, with lowest price hours of the day in between spread around lunchtime.

These two predictions will be true so many more days of the year than that they will not be, that it just seems silly for DESS to assume there will never be any profitable selling opportunities beyond the (midnight) end of known prices horizon.
Further improvements could be made based on day of the week, holidays, season, whether forecasts, historical yearly patterns and so on and so forth but that will hardly make as much of an impact as implementing the above basic two speculative price estimations (compared to not having any speculative pricing forecast as is currently the case).
I have been tempted to, but never got round to try implementing it, just copy paste 24 hours of the most recently know hourly prices onto the 1st unknown day, as is without any further adjustments.

The fact that there are one or two peaks every day, and a similar delta as long as the sun is halfway shining, says absolutely nothing about the absolute prices. In winter, it’s often the opposite, and the cheapest prices are at night. If it were that simple, you’d be speculating on the stock market and not speculating about the effectiveness of DESS. Then you’d definitely be a millionaire faster. I completely agree with you on one thing: price accuracy isn’t the deciding factor, but rather the extension of the forecast period.

Incidentally, Victron tested this very thing some time ago. I, or rather my system, were part of that test. The statement at the time was very clear. Extending the forecast period does not bring any significant monetary advantage. I also have my doubts about it, but that is my personal opinion and I cannot substantiate it. Another decisive factor is probably how often it has a positive effect. In individual cases, such as changes in the weather, certainly, but how often is that? In individual cases, a malfunction is clearly noticeable, and someone here in the forum is sure to take a few screenshots and post them on the forum. But again… how often does that happen? How big is the real advantage? And/or how many disadvantages arise if a possible price forecast turns out to be wrong. These are again the questions that need to be answered. Obviously, the longer forecast is positive, but how many disadvantages does it cause?

I don’t mean to get argumentative but you are missing the point.
First let me be clear I am always and only discussing a DESS Trade only system with a large capacity battery, no Solar and consumption lower than the efficiency losses of a single buy/sell cycle. This has provided the advantage of lower complexity and noise when monitoring DESS’s behaviour.
The point you are missing is that any prediction is better then no prediction at all because it moves the hard coded minimum SoC target further into the future. There is no need to be very precise, the speculative prices will always be replaced by the actual ones long before it is time to trade on them. Just having a modicum of directional price guidance beyond the known price window is enough to eliminate the very real and pretty much always wrong assumption that the optimal moment to have empty batteries is midnight.

PS, I have heard about this experiment, I asked to be allowed to participate and never heard from it again. The mere fact that this was done behind closed doors is discouraging.

TL;DR: the midnight minimum SoC target IS the distortion, it has no basis in reality.

First of all, you can’t consider the storage control system in isolation. 99.9% of systems are likely to be operated in combination with PV systems, and the PV production forecast must always play a role here. Buying more energy than needed at the most favorable moment, using up battery capacity, and then having a fully used battery the next day will likely result in the most negative outcome in the vast majority of cases. Since the new time interval usually begins 11 hours before the end of the previous time interval, the effect is mitigated. Otherwise, we are in complete agreement. I would fully welcome any kind of price. However, I am also aware of some reactions and outright criticism here in the forum. A while ago, I read some posts here that bordered on personal insults against Victron employees. And it was precisely in this context that I expressed my understanding that Victron is carefully considering the issue. As I already mentioned, I was involved in this test; there were one or two positive situations, but it wasn’t like it was a sweeping revolution or had positive effects on a daily basis. By the way, I also operate a storage system with around 100 kWh for an annual demand of 20,000 kWh, which I consider to be sufficiently large. But that doesn’t apply to the average user. The rule is that storage systems are dimensioned to cover a maximum of one night’s demand. I’m anything but argumentative, but I at least try to understand the arguments of the other side.

If you want to use any kind of price speculatively for the coming time intervals, it must be clearly communicated on what basis it is based. Otherwise, I can promise you, there will be endless discussions. I once participated in a discussion here in the forum about the accuracy of solar forecasts. There were endless calls to switch providers for perhaps even 0.01% better accuracy. I can’t imagine that happening with a price forecast at all. My concrete suggestion would be the average price of the past four weeks for each day of the week. This would ensure a somewhat smooth transition to the seasons. But if there are extreme fluctuations like the power outage in Spain or similar events, I don’t want to take the criticism here in the forum.

Why would that matter, even if true. My reasoning is simply that it is better to first make DESS trade work well before adding complexity to deal with increased uncertainties of solar and irregular peak consumption. Without that foundation chances are we will forever chase marginal improvements while missing obvious design issues hidden in the noise but impacting many.

Anyway, we seem agree on some points and differ on other, that’s fine. I certainly agree on the need to keep the discussions rational and productive. That said, I do not understand why there is no noticeable response from Victron to my requests to give some thought on improving DESS Trade.
A specific pet peeve of mine is the activation of b_goal_SOC / b_goal_hour on VRM DESS as that is proven already to work on Node-RED DESS and a reasonable alternative to extended price forecasting, in relation to the ‘minimum SoC target at midnight’ issue.

Rest assured that many posts will be read and registered, even if not every comment is responded to. It’s also part of Victron’s netiquette not to comment on innovations before the testing phase. I don’t know if you or I can fully assess what has proven successful or what has caused problems elsewhere. I would be a little more reserved at this point, but if you can assess the overall situation, please do. I know of a few projects that currently need to be addressed urgently, but I’m not participating in any speculation. In any case, there will be further developments. For me personally and for my requirements, the DESS isn’t yet perfect, but it functions and performs well in my system. When I ask around in other forums or among friends how things are going with other manufacturers, we should be grateful for the current state of development. Sometimes a little patience and humility help make life easier.

I have dayly monitored and extensively modified our DESS Trade system for half a year now and shared quite a bit of my findings including the actual Node-RED flows that we are developing. Also I actively participated on this forum on both DESS and other topics.

Our systems is working good enough for now (basically a hack to use Node-RED’s DESS b_goal_SOC / b_goal_hour in VRM DESS) but we have hit brick wall moving on from there. And that will stay that way for as long there is no on-topic response from Victron in sight on issues we raised and the solutions we proposed. All the generic responses boil down to one message: we know, we see, we are working on it but we will not say what, when and why.

It is not that I do not understand the ‘develop in silence’ approach in general or not appreciate what is done and shared. But with upcoming 15 minute pricing on the near horizon and the announced plans to phase out Node-RED DESS (not adapting it for 15m pricing), I find it a little frustrating to sit on my hands when there is still a little bit of time to prepare for that.

I completely understand you. I have some work to do, too. We’re getting grid charges differentiated by time of day. This involves 9 cents per kWh, which will make purchased electricity cheaper at certain times. For me, this will be almost the biggest lever for saving energy money. It’s a topic that’s been discussed for some time. News is coming from neighboring countries that they’ve been waiting for an additional variable in the pricing formula for some time. These are quite a few work to do. I could easily name 10 more. It’s the development of a system with so many variables, and on top of that, the framework conditions in different countries. One problem has to be addressed at a time. I’m also very confident that there’s more to come.

Some updates on my part, I would trust my current setup in summer. Using node-red DESS to keep my system in trade mode and force it to green mode when there is no scheduled trading or when the SOC is below my “soft limit” of 30%. Low SOC is set to 20% so I have 10% (3kWh) reserve to get me through the night.
I have not touched any settings for almost a week now but it does need improvements.

The assumption is battery capacity >~ daily solar production and this works as long as either:

  • Daily solar production > daily consumption
  • DESS sees opportunity to trade

I think in winter I might increase the soft-limit to 50 or even 75% since the heatpumps use 20kWh on the worst days. That way I think the system will always charge using the lowest prices, but only sell a little (for profit!) because of the soft limit.

Howto:

  • Calculate your round-trip efficiency based on your charge/discharge power. I used these charts for the MP2 48/5000 and figured to set both the charging and discharging at maximum efficiency. For a 3-phase 48/5000 system this is ~92.8% @ 4.2kW charging (TB) and ~96.2% @ 3.3kW discharging (FB) resulting in ~89% inverter efficiency. Because the inverters are not the only things with losses, I set the efficiency to 87%.
    Fully utilizing the power of the MP2, the efficiency is < 80%.
  • Set battery cycle cost to at least 0.02 (or higher if that is your cycle cost). I set it to 0.03
  • Modify “split schedule 0” with some code from “prepare dess variables” so it uses the previous hour as reference. If the current hour target SOC == previous hour target SOC (no trading this hour): set strategy to 1 (green mode).

Side-effects / gotchas:

  • Loads during charging will be drawn from grid as well, up to TG_max.
  • The discharge power (FB) will be the discharge setpoint for the Multiplus. If your loads exceed this, you will still draw the difference from the grid!
[
    {
        "id": "f679b820a19c896e",
        "type": "inject",
        "z": "2bf3db9bfca4f392",
        "g": "c018435c26989974",
        "name": "",
        "props": [
            {
                "p": "payload"
            },
            {
                "p": "topic",
                "vt": "str"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "87",
        "payloadType": "num",
        "x": 130,
        "y": 320,
        "wires": [
            [
                "ea18743145739b0d"
            ]
        ]
    },
    {
        "id": "ea18743145739b0d",
        "type": "victron-output-custom",
        "z": "2bf3db9bfca4f392",
        "g": "c018435c26989974",
        "service": "com.victronenergy.settings",
        "path": "/Settings/DynamicEss/SystemEfficiency",
        "serviceObj": {
            "service": "com.victronenergy.settings",
            "name": "com.victronenergy.settings"
        },
        "pathObj": {
            "path": "/Settings/DynamicEss/SystemEfficiency",
            "name": "/Settings/DynamicEss/SystemEfficiency",
            "type": "number",
            "value": 90
        },
        "name": "",
        "onlyChanges": false,
        "x": 500,
        "y": 320,
        "wires": []
    },
    {
        "id": "1d6fa900c0666142",
        "type": "function",
        "z": "2bf3db9bfca4f392",
        "g": "dd46443f62f6ce6a",
        "name": "split schedule 0",
        "func": "node.status({ fill: 'green', shape: 'dot', text: new Date(msg.start*1000).toLocaleString() })\n\nlet battery_soc = flow.get(\"battery_soc\");\nlet dess = flow.get('dess');\n\nconst currentDateTime = new Date()\ncurrentDateTime.setMinutes(0, 0, 0)\n\nlet currentHour = currentDateTime.getHours()\nif (currentHour > Object.keys(dess.schedule).length) {\n    currentHour -= 24\n}\nlet previousHour = currentHour - 1\n\nlet currentSOC = Number((dess.output.SOC[currentHour]).toFixed(1));\nlet previousSOC = Number((dess.output.SOC[previousHour]).toFixed(1));\n\nif (previousSOC == currentSOC) {\n    msg.strategy = 1;\n}\n\nif ((battery_soc < 30) && (msg.soc <= battery_soc)) {\n    msg.strategy = 1;\n}\n\nreturn [\n    {\n        path: '/Settings/DynamicEss/Schedule/0/Soc',\n        payload: msg.soc\n    },\n    {\n        path: '/Settings/DynamicEss/Schedule/0/AllowGridFeedIn',\n        payload: msg.feed_in\n    },\n    {\n        path: '/Settings/DynamicEss/Schedule/0/Start',\n        payload: msg.start\n    },\n    {\n        path: '/Settings/DynamicEss/Schedule/0/Duration',\n        payload: msg.duration\n    },\n    {\n        path: '/Settings/DynamicEss/Schedule/0/Restrictions',\n        payload: msg.restrictions\n    },\n    {\n        path: '/Settings/DynamicEss/Schedule/0/Strategy',\n        payload: msg.strategy\n        //payload: 1\n    }\n];",
        "outputs": 6,
        "timeout": "",
        "noerr": 0,
        "initialize": "",
        "finalize": "",
        "libs": [],
        "x": 220,
        "y": 600,
        "wires": [
            [
                "fb20423f20fb8073"
            ],
            [
                "fb20423f20fb8073"
            ],
            [
                "fb20423f20fb8073"
            ],
            [
                "fb20423f20fb8073"
            ],
            [
                "fb20423f20fb8073"
            ],
            [
                "fb20423f20fb8073",
                "7398e7c3a7bd7f45"
            ]
        ]
    },
    {
        "id": "fb20423f20fb8073",
        "type": "victron-output-custom",
        "z": "2bf3db9bfca4f392",
        "g": "dd46443f62f6ce6a",
        "service": "com.victronenergy.settings",
        "path": "/Settings/DynamicEss/Schedule/0/Soc",
        "serviceObj": {
            "service": "com.victronenergy.settings",
            "name": "com.victronenergy.settings"
        },
        "pathObj": {
            "path": "/Settings/DynamicEss/Schedule/0/Soc",
            "name": "/Settings/DynamicEss/Schedule/0/Soc",
            "type": "number",
            "value": 73
        },
        "name": "Schedule 0",
        "onlyChanges": false,
        "x": 490,
        "y": 580,
        "wires": []
    }
]

Today it would do this:

The system is currently discharging and tomorrow morning I will see the horizontal line from the night has become a downward line and it will probably not sell mucht at hour 32.
This is why you need to exaggerate your cycle cost / efficiëncy since energy is lost to green-mode and 10% cannot be sold :wink:
This probably needs tweaking..

I also made some logic to set my multiplusses to “external control, 0W” during green mode + solar overproduction + SOC > 30% so I can feed in all AC-solar (inefficient to convert back to DC again) but still charge using the highly efficiënt MPPT solar so I can use it / sell it later.

Since DESS thinks trading is not an option, the price should be high enough to sell anyway.

I do not think that code is relevant for this issue but I am willing to share.

TL/DR:

  • Forced green mode in trade-mode (instead of forced charge in green-mode) feels like a good trade/green-mode combination. You can use the efficiency and battery cost values to control how much trading should be done.

The > 1kWh cells from China which supposedly do 6000 cycles are < €70. 70/(6000*1) =~€0,01.
It does not consider the wear on the multiplus or other hardware though but €0,02 cycle cost is realistic today.

edit
I assume you buy things and use them untill they break. If you plan to replace the cells sooner, you should of course increase the cost per cycle
/edit

edit2
I do not feel like replying in a new message since I’m not sure this cost per cycle debate helps @marcelmol at all (but do enlighten me if it does!).

All setups are different. New batteries, older models, small batteries, big ones. Some people DIY and others pay premium price to have it done. Some have small solar setups and others hugely oversized or none. But whatever and whoever: I’d say use your batteries as much as possible! Not doing a cycle is worse then doing one with little profit. (Never cycle for loss though..!) There are very few items that become more expensive when kept in mint condition, but battery cells are not one of those.

Yet I do like to calculate the costs, try some scenarios and come to my own conclusions. For this I set the efficiency to 80% and (dis)/charge powers to a little over maximum (13kW)/10kW. Curious to see what DESS would to tomorrow(today..) with different cycle costs.

  1. The cost for my whole system (64kWh storage, 3xmultiplus, cerbo, lynx’s, shunts, cables, mppt’s, some solar panels, energy meters and god knows what else) + working for free boils down to about €180 per kWh storage (cell). (I spent quite some time finding deals, used and b-stock items).
  2. Assuming everything survives 6000 cycles, that makes €0,03/cycle
  3. ..
  4. Setting the cost/cycle to 0,1 DESS will only sell the 3-4kWh excess solar + what is still left from charging from grid 2 days ago (when prices without tax were ~0). Netting me €2,40 and cycling the battery for 0,2
  5. Setting the cost/cycle to 0,05, DESS would do the same but the net profit would be €2,80 (and 0,2 cycles)
  6. Setting it to 0,03, DESS expects €3,60 profit and 0,4 cycles
  7. Setting it to 0,01, DESS also discharges in the morning, expects €5 profit and does 0,6 cycles.

If scenario 4 persists, it will take 100 years before the 6000 cycles are used and 14 years to break even the cost. (probably longer to break even since you cannot expect to have free 10kWh from 2 days ago every day.)
If scenario 7 persists, 6000 cycles will take < 30 years and break even <7 years.

But Marcels’ situation: green mode with a 100% charge once in a while. I think he got his full charge the 29’th. Not sure why it canceled the 27’th charge (maybe he changed settings?) but I saw some weird things that day as well. (selling/not selling/selling/not selling, switching a few times within the hour.)

Maybe Victron secretly accounts for net imbalance?
/edit2

Can somebody explain to me the rationale behind taking anything over 1000 or at most 2000 cycles serious for economic calculations? I mean, it will take 3 or even 6 years of running a full cycle practically every single day of the year. I just can’t see how any battery bought today will not be a complete write-off over such a long timeframe, compared to whatever battery technology will be for sale by then.

Expected lifetime is 10 years.
If you do a full cycle every day, you’ll pull ~56.000 kWh from them.
At €70/cell you do end up with €0.02/kWh cycle cost, but that is pure cell cost only.

You don’t have a case, BMS, cables or any assembly for that price - and I’m specifically ignoring any certification cost because apparently nobody cares about safety or assurance/insurance these days ?
If you ignore all that and you work for free, then you can get that €0.02/kWh cost yes.
A realistic cycle cost will easily be in the €0.05/kWh or more region.

Replacing the battery in 10-15 years will likely cost less than €70 per kWh. I find the recent statements about battery costs rather extreme. Some people would prefer not to add anything at all because the battery is already there, while others want to include every last cent. Why don’t we take a middle ground somewhere… 2-4 cents per kWh, and everyone will be reasonably satisfied.

Exactly and from an economic perspective on the low end even. The big difference is whether an ESS is treated as a hobby or a business, the former not calculating value of time (of the work involved) and opportunity cost of the upfront investment (not investable elsewhere). In a business both are very real very scarce resources that need to be accounted for, there’s a reason why pretty much any capital investment is written off in 3 or at most 5 years or even in personal life a new car looses most of it’s market value in a few years, even if it could drive for decades. Economic write off is simply not linear over decades.

The way I tend to think of batteries is paying for the energy upfront. And in DESS Trade the best strategy seems to be to run the batteries as hard as possible with a target of 10ct margin between buy and sell price, no matter the upfront cost. Basically trying to outrun their limited economic lifespan.