Why is that, I do not understand how this is profitable in any way? DESS just managed to lose one of the two profitable selling opportunities, and is well on its way to losing the other as well.
I donât know your configurations. Realistic charge and discharge rates play a role. Battery costs, and much more.
1 Like
Half an hour left of the hour, and DESS ran the SOC to zero. Itâs broken for sure. It used to work reasonably well, but maybe the 15 minute changes added some regressions.
@dognose curious if you have thoughts here? My system unexpectedly self consumed down to min SOC as well the other day, under the new reactive strategy (the VRM plan was to consume from grid).
Even for a DIY battery, 0.01âŹ/kWh is not realistic.
If you feed the system nonsensical input, donât complain if it produces nonsensical output.
1000⏠for the cells, ~16kWh and 8000 cycles of life as per the datasheet. Do the math if you wish.
Please also explain how low battery cost has anything to do with this sort of logic failure.
âThatâs not how it worksâ isnât enough explanation I guess?
The importance of a (correct/reasonable) battery cycle cost has been explained countless times already, Iâm not going to repeat it/myself yet again.
Now you disregard the fact that the cost was actually correct?
Furthermore, if the battery cost was zero, the system should actually be more eager to take small wins from buying & selling. And that is not even what happened here. DESS actually correctly planned the trade, but failed to execute its own plan.
1 Like
This is fundamentally it. I donât have a battery cost in my system either. I let the underlying System Efficiency parameter do the work.
1 Like
Assembly time, warranty, approvals, insurance, lifecycle and then some.
All costs that you are actively ignoring.
If you canât or wonât see the entire picture then fine, do whatever you want.
But donât complain either.
Iâm signing out of this non-discussion.
Iâm presuming youâre on the 3.7 beta? Thatâs where the reactive strategy youâre mentioning is from (self consume below tsoc), but best to confirm.
Yeah, currently 3.70~34. Looks like ~40 is out, I suppose I might as well upgrade to that one.
You might consider commenting on the latest beta thread, highlighting your issue with the new reactive strategy.
I previously posted about a similar issue here: Venus OS v3.70~35 available for public testing - #230 by A-P
Hereâs the latest thread: Venus OS v3.70~40 available for public testing
1 Like
Itâs actually quite simple. No matter how realistic the battery costs are, the higher they are, the less the DESS will react to such mini-cycles. If I were you, Iâd experiment a bit here. My realistic costs are somewhere in the range of 1-3 cents. At 1 cent, the system was too reactive for me; at 3 cents, it only used the storage when there were extreme price differences. Iâm now at 2 cents. Something else to plan and implement. Of course, the DESS has a long-term plan. However, itâs constantly being revised. If circumstances change, such as the consumption forecast, or if the solar yield deviates from the calculated one, this will change the plan. A huge advantage of the current DESS. Next point⌠your battery seems small compared to your consumption, so small changes in the forecasts have serious consequences. Finally, the last point: what are your charging and discharging rates based on? The 3.9 kW? They absolutely have to correspond to realistic values ââand not some theoretical maximum output listed in a manual. If thereâs a bottleneck somewhere that prevents the system from achieving this performance, the schedule wonât work and will be constantly revised. The system calculates that it will discharge or charge 3.9 kW within hour X. If this isnât implemented, the plan will fail again and again. I hope Iâve explained how important the configurations are and how fundamental it is to engage with them.
One more thing. I donât know if such a small battery is necessarily suitable for trading mode. Please donât misunderstand me. By small, I mean the ratio of battery capacity to nighttime consumption. If thereâs only a small power window for âtradingâ after subtracting your own needs, small changes in the forecasts make a big difference as to whether I buy or sell the remaining capacity. Please consider whether green mode might be more suitable for you.
Well, thanks for taking the time to reply. You are obviously correct saying that higher battery costs cause DESS to react less to such opportunities. That is part of the reason why (considering my low battery cost) I disagree with the âself consumption below TSOCâ decision DESS made. DESS should have prevented self consumption, idled for a few hours, then sold when it was expensive.
3.9kW is correct for the current limit and fuses my MPII 48/5000 is behind. My system consistently achieves this. Typically DESS works absolutely flawlessly and the battery SOCs it plans are typically spot on, highlighting correct system settings. Yesterday was simply an unexpected quirk, so I reported it.
To be honest, it feels like we are now trying to find what mistake I made instead of focusing on the logic issue. By the way, I charge my car during the night, and I expect DESS to charge then as well if needed or if it provides a future selling opportunity, of course depending on solar and day ahead prices. DESS has rarely tried to cover my nighttime consumption, which is absolutely the correct decision. I doubt green mode would be correct for my use case, since I specifically want the system to trade. My purchase contract is moving to dynamic pricing in 4 wks, which probably adds more trade opportunities.
I didnât mean to blame you or defend DESS or Victron. Iâve been involved with this topic for about two years now and have read about a few problems here and experienced some myself. Therefore, I wanted to point out some of the most basic issues. Nothing more, nothing less. Check whether the actual charging and discharging power really corresponds to the 3.9 kW. I spent some time trying to find realistic values ââin this area.
1 Like
Hi guys, with all due respect, I think we are missing a somewhat subtle but important point here. Let me try to shed some light on this. As an aerospace engineer with a specialty in systems engineering, one of the most complicated skills to develop and practice is the separation of the problem domain and the solution domain. Generally speaking when we are confronted with a problem, our brains are hardwired to jump to conclusions first based on our experience and intuition. This is an extremely valuable capability under almost all circumstances of life, with notable exception being those situations where we need to deal with complicated systems. The way I see this relate to all the ongoing DESS discussions is that these always seem to boil down to two opposing viewpoints with most people firmly convinced that their own viewpoint (either way) is the only correct one, so much so that we could speak of opposing teams or camps even. For a lack of a better way of expressing myself lets call these the âproblemseekersâ and the âsolutionprovidersâ. The way I see this play out in practice whenever a new conversation comes up concerning DESS is that the solutionproviders tend to focus on how to get the best out of DESS by adapting to the system while the problemseekers are focussed on finding the reasons why the system is not functioning the way they expect or need. Often these discussion become much less about DESS, its functioning or malfunctioning and ways of improving upon the current state of affairs, but about âwho is rightâ. The solutionproviders get frustrated that the problemseekers are, well, seeking problems. And the problemseekers are getting frustrated because the solutionproviders are, well, not listening to their problems. Obviously this is simply not going to help much. What I propose is for us all to recognize the value of both ends of that spectrum and try to keep in mind that we can only achieve real progress when engage in a constructive discussion about the technical aspects of DESS and its future development. ANd from above it should be obvious that I believe a good way to do that is by trying to seperate the problem domain from the solution domain. Practically I would suggest we make a distinction between requirements, implementations, issues (preferably prioritized), workarounds and solutions. For example I would catagorize all attempts to make DESS behave more to our requirements by tweaking system setting values (to differ from actual values) as a workaround, not a solution. Nothing wrong with that, as long as we can also discuss why using actual values wonât result in correct behaviour/functionality/performance of the system. Skipping that step only serves to hide root causes (in the problem domain) and in extention thereof, severely limit our ability to help develop better solutions in the future.
Anyway, if you read my wall of words to the end, thank you for your attention, I donât mean to lecture anybody, just trying to help get more and better results out of all the time and effort we all put into helping eachother out.
PS @guystewart @Barbara Could we revisit the idea of making DESS a top level category by itself, with a few sub-categories to reflect differenct aspect of it, such as requirements, implementation, issues, workarounds, solutions, proposals, roadmap etcetera. I believe that would help to bring better focus and more structure to the ongoing discussions that are currently scattered all over forum.
2 Likes