DESS: Consumption forecast far too low

[dognose]

The overall result of DESS mainly depends on forecast accuracy, that is an open secret, I assume.

And one of the core issues seems to be unrealistic consumption / solar forecast, that leads to unexpected behaviour. While there is just a topic from today stating that the consumption forecast is “to high” - i’m having the opposite issue: Consumption Forecast is far to low.

My home is running 24/7 with a minimum consumption of 650 Watts. It won’t go bellow that, if every optional consumer is turned off. (There are servers, switches, infra stuff - the basic socket amount is 650 Watts)

However, DESS is predicting consumption values of down to 200 watts during night - There shouldn’t be any data of the past 3 months backing such a low consumption, wonder how the forecast is making this decission?

Heres the forecast of “today”, snapshoted yesterday, from 0 - 6 DESS is assuming a per-hour consumption of 200-300 Watts only - 50% of what WILL be used for sure:

The result of this is, that the system will not hit the morning with it’s predicted SOC of 30%, but in fact run empty (20% minimum soc) and then HAS to pull from grid:

finally, this is happening with a bad timing, DESS seems to believe till the end that there is no Battery-Charge required. If it would have noted earlier, that it will run out of Battery, it COULD have charged from the grid for 28 cents, rather than beeing FORCED to pull from grid in the expensive morning hours. This morning not much of a difference, tho.

A Second thing I noted and which I don’t understand:
The schedule seems to ALWAYS target for a 20% at the End of the day:

There is grid2bat scheduled for the cheapest hour today, that is fine - but Why 20% at the end of the day? That means basically “minimum soc reached” when the next day starts.

This may adjust as tomorrows prices will be coming in during noon - however then there is only “half a day” to compensate for any required offset. Wouldn’t it be more reasonable to pick some “Safety distance” towards the minimum soc during scheduling until tomorrows prices are known?

I mean now, the whole schedule for today is targeting a “empty battery” situation at 0 o clock tomorrow. So, the schedule has to be changed and some additional 8-10 kWh would need to be gathered from “somewhere”?

Additionally, the system is still expecting some 20 kWh solar today (forecast yesterday: 35) - which is not going to happen with a very high certainity.

So, beside wrong consumption / Soc, DESS also has to deal with a solar prediction of 35, of which we have gathered a stunning 3.1 kWh so far (13 pm)

[dognose]

Tomorrows prices just arrived.

• EOD soc has been rescheduled to 33%, but again based on very low consumption forecast from 0-6 tomorrow:

So, DESS is now targeting a 20% at 8am, based on ~300 Wh figures during night - so it will again run out of battery in the early, expensive morning hours, probably 3 hours before schedule.:

[Sarowe1990]

I don’t know if you meant me with the consumption forecast being too high. A high consumption forecast was never my problem. The consumption forecast reacting too strongly to high or below-average loads was my problem and that has gotten much better. I have also read some comments in the last few days about PV forecasts being too high, but I cannot confirm that at all. I have also looked at the PV forecasts a few times with surprise, but at the end of the day they were usually very accurate. However, I think the idea of ​​a configurable consumption forecast makes sense. A few days ago I also raised the idea of ​​special loads at extremely low prices. However, I think these should be functions for the future. I think it is important for all of us that the core DESS runs well. This primarily includes the forecasts, I completely agree with you there.

[Barbara (Barbara (Victron Energy))]

Hi @dognose,

Thank you for your feedback. Are you sure your consumption forecast is too low? By the looks of your site and its forecast, it is too high.

We implemented a new model end of last week, so I expect this model to pick up your average consumption and improve based on that in the future.

I can see that now the prices came in, DESS charges your battery at the lowest price for the rest of the day.

[dognose]

@Barbara

Thank you for your feedback. Are you sure your consumption forecast is too low? By the looks of your site and its forecast, it is too high.

It is a mix - Forecast values from 8 - 18 are currently too high. This is, because in the past 3 months (Summer) I have a total of upto 9 kW-Consumers which are enabled / disabled based on available solar. That means: Much solar → Additional 9 kW consumption.

And now - less solar - they are not enabled → less consumption.

DESS is catching up on this part of the forecast every day, that should be resolved in a couple of days/weeks I assume. - But I know that these kind of consumers are not predictable, so nothing to complain there from my side

Consumption Forecases form 0-6 are generally to low:

• Forecasts in that time are about 200 - 300 Wh,
• Real consumption in that time is a minimum of 500-550 Watts. (600/650 is the value in my head, cause that’s the DC-reading)

Example, 200 Wh at 3 am:

While reality is - every day minimum 500 Wh:

So these “magical” 6 hours will always cause DESS running short by about 2-3 kWh battery capactity in the morning, when it schedules for a “20% soc” to start the day (~8am target).

[dognose]

@Barbara

I can see that now the prices came in, DESS charges your battery at the lowest price for the rest of the day.

Unfortunately not. After charging 7 kWh from Grid, it has now decided to Feedin 700 Watts to the grid again and therefore draining the battery

Target Soc in DESS is now set to 46%, so it tries to get rid of that additional 2%?

1200 Feedin now…

Doesn’t seem all to economically for me - but will let you know, if it stops at 46%

[dognose]

@Barbara

Yes, spot on with 46% reported by the BMS, it stopped to feed in, starting to pull from grid again…

Now there is a little more solar - but instead charging, it sticks to 46%, feeding in…

So:

• We’ve pulled 8 kWh from Grid
• Just to feedin excess 2% right after pulling.
• And now stick to 46%, feeding in excess PV with 54% of space in the batteries.

I’ll leave it running like that for the day, in case you want to review something - but tomorrow probably disable DESS again… Maybe i’ll retry next year

Update: TargetSoc now 44%,

So, urgent discharge required, can’t tollerate that 46% battery soc…

(btw, the Option that “discharge to grid” is prohibited is also kindly ignored here)

---

I’ve now disabled DESS, as we currently have a bit of more sun, but socs of 42 and even 41% are “scheduled” that would cause further feedin / discharge for no reason.

Outcome so far is, that we have pulled 12.3 kWh from grid, and feed back 3.5 kWh while battery is at 44% now.:

Despite any imprecissions caused by forecasts, and the eventually understandable behaviour that underfullfillment of the soc-target may cause unoptimized hourly grid-pull - having the system feed-in excess solar and/or discharging the battery to reach a hourly soc-target is just … a bug. Why would one ever want this behaviour?

[dognose]

One note on the original Question / Issue as well (before DESS gone crazy):

Prediction 0-6 hit a new low with 80 Wh, while it will be ~ 600 in Reality.

It seems like the forecast is somehow concluding, that if consumption during the day goes down by X%, every other hour has to drop as well.

[dognose]

@dognose

Despite any imprecissions caused by forecasts, and the eventually understandable behaviour that underfullfillment of the soc-target may cause unoptimized hourly grid-pull - having the system feed-in excess solar and/or discharging the battery to reach a hourly soc-target is just … a bug. Why would one ever want this behaviour?

I’ve now modified victrons internal DESS-Delegate (/opt/victronenergy/dbus-systemcalc-py/delegates/dynamicess.py) on my cerbo, so these kind of decisions are overwritten and handled in a more logical way.

I will test this some weeks, before I suggest any changes here. I Especially have to see, how this impacts schedules created by VRM, when the local system basically decides to “reject” the VRM roadmap for a few hours and behaves different than what the schedule expects it to do. (I don’t think it will be an big Issue, VRM needs to always adapt to “out-of-plan” situations due to unforseen solar production and/or consumption)

I Will let you know, if the changes successfully surpress that behaviour. (Well, they will for sure, but maybe there are undesired side-effects)

[dfeist (Dan Feist)]

There are multuple scenarios where dynamicess.py doesn’t do a good job at handling actual consumption or pv output from my experience. I’m also currently experimenting with some changes here too.

One interesting thing I noticed is that, as there is no minSetpoint or maxSetpoint functionality available (AFAIK anyway), dynamicess.py is using very large negative setpoint and a MaxDischargePower override. The problem with this is that this is only updated every 4s so reacts quite slowly compared to a setpoint.