But it seems that local venus does not start battery to grid for some reason, even VRM DESS shows that it should. (I think this is HACK that is preventing it :)) )
– edit next day —
It seems that HACK also prevented that night 04:00 bat2grid sell.
But I now have a question what happens tonight evening.
Right now it has 4h of bat2grid sell planning (and that I think it actually needs to fit next day PV)
– edit evening –
Yes, can confirm that with the HACK enabled selling from bat2grid is not happening event it is scheduled by DESS. Target strategy in: Target SOC, but final strategy is:SELFCONSUME_ACCEPT_DISCHARGE
So it seems I have to schedule selling to grid myself because otherwise tomorrows PV will not fit. And I can load to EV at night about 15kwh also
Yes, that is whats happening. As soon as the consumption / solar / price prediction for the day after tomorrow is available (which by then will be “tomorrow”, usually happens at ~ 13 daily at least for the prices) DESS should re-schedule with a end-of-day-soc matching your required consumption throughout the night.
But do I get it right, that with the HACK installed, there will never be bat2grid flow, even when vrm dess will write it to my venus schedule?
How about with the new beta where hack functions are implemented?
I would like to use DESS in green mode, but I want it to only sell the amount that next days PV production will fit to the battery. And I want DESS to sell it in the best price possible.
And in the september and october where there will be less PV it should buy from grid. When I tested it in january then DESS liked to keep battery at minimum. Did not buy to full at night when there was cheapest hours.
And that, in my opinion, is one of the biggest weaknesses of DESS at the moment. I’ve mentioned this several times here in the forum. In my opinion, a solution would be to use a hypothetical price for a few days over the period for which there are prices. Perhaps an average price from the past 2-3 weeks. This would allow for a rough calculation for the coming days. The absolute price wouldn’t even be the decisive factor. Much more important would be PV under- or over-coverage beyond the next 24-36 hours. At the moment, I’m observing a restriction of the forecast period, at least for me. However, I’m not entirely sure whether this is due to Victron, my load management, or my relatively new storage expansion.
The new beta client is ready to also support bat2grid while still using all the improvements.
In the “hack”, discharge2grid was absent, because the “old/current” communication model didn’t allow to distinguish, if a chargerate was picked to low, cause understimated forecasts OR if feedin is desired due to prices.
So, i opted for the greener assumption, assuming it’s just underestimation of solar.
The new beta has received a updated communication protocol that now allows to distinguish both situations - and act as desired, without guessing the intention of the plan.
(All that applies inverterted for discharge cases and the question if it’s intendet discharge2grid or just overestimated consumption)
We are continiously working on that. The main problem is, that the further you look into the future, the more imprecise everything will get, because every hourly “error” stockpiles up to a point, where it is almost impossible to have reasonable values.
Solutions that looked promising for 4 days, suddenly lead to an all irrational behaviour on the 5th day and so on.
Keep in mind that releasing something will affect thausands of systems, so should be quite well tested and validated, which - by the nature of observing days of data - is time consuming
I fully understand the problems, especially when it comes to the use and impact of natural resources. I’m a qualified agricultural engineer . Two or three days into the future would be something.
But can you explain why it wants to sell tonight when it esimates my consumtion be high?
As You can see in the VRM graph, it wants to be at the bottom of the SOC.
In green mode there is no reason to sell in my case, because PV will fit without selling also.
In my optinion it treats all the system the same (assumes that it must sell because otherwise PV will not fit). But it should account my battery size also in the equation
I understand that systems with 25kwh of battery and 50kwh of PV production in a day must act like this. But systems that have more battery than PV production in a day should be treated differently.
In my case it should not be under 30% in the morning.
Well, when you look it at the overall schedule of the SoC you shared: It kinda exactly calculated the energy needed through the night, hitting “MinSoc” in the morning, when solar kicks in.
So, the amount beeing sold at “best prices” is basically the amount of energy that would otherwise sit in your battery in the morning, when solar kicks in.
However, looking at a more distant future (End of next day), a human can conclude that it may be better to keep the energy as that day is not very sunny. Unfortunately everything beyond that day is “out of awareness” at the current time, which is the Issue @Sarowe1990 also mentioned.
At the current “now”, there is no way to say how much SoC would be required at 23:00 of the 24th, so the scheduler assumes “MinSoc” to be fine and most cost-efficient, hence energy that COULD be sold will be sold in the most expensive hours known in the next ~36h.
Overall, you have to select one of two tradeoffs here:
Either allow selling to grid, accept that this happens with a <48h-scope in mind and therefore sometimes sells not ideal.
Restrict Bat2Grid, therefore maximizing self-consumption-capacity and accept you’ll end up with some kWh sitting in the battery with no where to go.
Correct. The system calculates the energy required for the period according to the consumption forecast. Anything exceeding this is sold as optimally as possible. The purchase mode works the same way in winter; it always considers the period for which prices are available. The system can only calculate for this period because only for this period are all the facts/parameters available. Everything else is speculation about the future. Just as an example: the next day the prices could be much lower. I fully understand that Victron does not rely on a system that works with a speculative price beyond any facts. If this forecast goes wrong, all hell breaks loose in the forum and everyone complains. I’m not a developer, but then a serious algorithm would have to be found that takes future prices into account. Another model could be a third mode, based on the maximum Soc. This would require the system to only sell as much energy as the upcoming production fits into the storage. But even that would not solve the fundamental problem; it would shift it to a different situation. Then the problem would be with purchasing. Then the question would be why the system buys more energy than it predicts. Or with selling, why doesn’t the system sell more electricity because I, as the user, expect falling prices. The way the system is currently designed, it optimizes for the period in which all parameters are available.
The next interesting point, and one that I think often leads to misunderstandings, is that as soon as the system receives new parameters, it changes its plan. These are the prices around midday for the next time interval, but this could also be due to a correction in the weather forecast or unexpected consumption. If the weather forecast changes, a completely new situation arises. A sale or purchase, however correct it was in the past, can turn out to be wrong in retrospect if the parameters have changed in the meantime. But isn’t it the same with human decisions? Unexpected consumption triggers the same thing. In the morning, the system assumes it can sell electricity, but then unexpected consumption occurs, and the energy it sold in the morning has to be purchased again. But this can also happen the other way around. The system calculates high consumption and skips a time with lucrative prices. This consumption does not occur now, and the system sells at a later, less lucrative time.
There is still one thing what I do not understand.
System knows everything 36 hours ahead at mid day when there are next day prices.
Even it knows that next day PV forecast is low (actually that does not even matter because in my case max PV is 65kwh but my battery is 80kwh) it still goes for MinSOC.
I changed max battery discharge from 6kw to 10 kw and it produced different graphs, but both tired to achive min soc in the morning.
Next day prices are actually irrelevant, because in my case starting of May I produce more than I consume in average. Just it disturbs me that it tries to go to min soc because it is not nessesary.
therefore have you thought of introducing a new parameter called DESS minSoc. So everyone can configure their system accoringly?
And who then defines how and under what conditions this energy should be used between the Min Soc and Dess Min Soc? That would then lead to the next logic. If it’s just about raising the Min Soc, it could also be set above the normal Soc. Do you understand what I mean?
Do not understand your dilemma
Dess min soc is used by DESS
reqular min soc is used by ESS
These people who do not want to do this can set DESS min soc the same as regular min soc.
But answer to your question. DESS will “sell” only to “dess min soc” after that system will use ESS and use battery as self consumption until min soc is reached. (the reqular behavior when dess is disabled).
If you ask about winter when there is no PV then DESS is operating between “dess min soc” and 100%. so basically DESS is trying to keep soc over “dess min soc”.
Yes I understand that then some of the battery capacity is not used, but you do not have to use higher “dess min soc” if you do not want. So in that everybody wins, me who wants to use higher min soc for DESS and other people who do not want.
And for clearification we are talkin “Green mode” only.
Why I’m talking about this is that right now VRM is keeping the battery empty most of the time. But people who are living where there are lot of interuptions, they want that battery is most charged.
So they want that system will only sell these amount of battery that is needed to fit next day forecast solar not to min soc every morning
Yes, we’re talking about green mode. The use of SOCs below the set min-SOC is actually clearly regulated; it’s specifically for use in the event of a grid failure. But if you’re talking about a special DESS min-SOC, then I assume it’s supposed to be higher than the regular min-SOC, as a reserve for days with low PV production, so to speak. Under what conditions should the DESS draw on this reserve? From a certain shortfall? From a certain purchase price? On the first day of the shortfall, or when? That would require a completely new logic. Just to be clear. I’m just a user, but I’m dealing with exactly the same problems as you.
I’m trying to solve my own problem Will paste here my this month stats and as you can see I’m producing a little bit more than I’m using. I needed from grid on first of may around 42kwh other is just ESS holding gridsetpoint on 30W
What I want is that DESS is selling only that amount of energy from battery in the highest price hours that next day PV forecast will fit to battery, like it was yesterday (manual sold by me).
DESS does predict usage this night but still sells to 15% in the morning (my min soc), and actually I can use my battery to 7% due some limitation (so around 7kwh in emergency).
I want that DESS will do this instead (sell only needed amount not all)
I has all the information to do that, but it is programmed to sold to minSoc at all cost. And what I’m succesting is that if I can not tell it to sold only surplus (next day pv forecast) at highest price, it would allow me to specify DESS min soc insted.
Yeah I know that can bring other shortcomings but like it is right now is not usable by me, because if there is not enought sun next day (lets say 10kwh but i will still use 30kwh) it will still sell to 15% and then it will buy it from grid during the day. I’m not talking that it will cost me more, I just do not want to use grid when I have enought my own energy and have battery capacity to store it.
And I’ve tried to explain to you why it does this. The logic behind it. If it were only based on what I want and what makes sense for me, I would do some things differently. But I’m trying to understand why the system does certain things and not others. And thus also recognize the disadvantages that changes to one or another logic, however desirable, can bring in other areas.
Their logic is not right for all the installations. It is right for these who have less or equal battery than day PV solar production.
I lied to DESS and told that my battery is 180kwh and allowed it to sell from battery 10kw power.
And it made a plan that in tomorrow evening battery is 23%.
I understand that for DESS it is easyer to keep battery SOC at the bottom so there is always chance to buy/produce cheap energy and store it for future. Then none will complain
This was also in january when I tested it (there was no PV production then) when it wanted to keep battery SOC at lowest end.
I saw, that often people complaining about not having enough headroom for solar surplus or mostly complaining about not having enough energy stored in battery to get to the next morning, if unexpectet loads happend during night time.
An easy workarround could be to add an extra threashold for min and max SOC for DESS.
For example:
MIN SOC general set in ESS: 15%
SOC for min DESS calculation should be 15% + 15%
So DESS tries to reach 30% in the morning but has 15% left for unexpectet loads.
MAX SOC general set in DESS: 100%
SOC for max DESS calculation shoul be 100% - 15%
So DESS tries to stopp charging from Grid at 85% and has left 15% for aditional solar surplus.
If both threasholds can be adjusted by user, it could be easily adjusted to different needs. And switched off by setting to 0%.
If you don’t “need more” than minSoc in the morning, then squeeze out additional energy to best prices possible to have the battery ready to eventually take as much solar as there eventually might be. (or react to super-cheap grid prices coming up)
But you could easily place a bat2grid restriction from 15 to 5am if you wish. Then there wont be selling scheduled in that hours. You ofc. have to adjust that with your usual sell-prices, else DESS may consider selling at 14 already
. Two or three days into the future would be something.
