Hi all,
I’ve been dipping in and out of DESS for several months now, and I can see that Victron are investing a lot of time and effort into this project - for which I am very grateful. Well done to Victron for taking the initiative.
But over the past few month, I have switched on DESS but generally within a few days, switched back to regular ESS - and it’s always because the behaviour of DESS is costing me (a little) money.
Now with the Octopus integration being available I was very hopeful that this would mark a major step forward. But I still finding the results of DESS still very unpredictable and in many ways counter intuitive. The concept of ‘target SOC’ is lost on me.
So, in short, rather than post a lot of data, schedules and graphs, I thought I’d ask a simple question. One that addresses, of course, only the UK market.
“Is anyone successfully using DESS with Octopus GO”? I guess I should qualify what I mean by ‘successfully’. I mean, you are happy that the system is making best use of battery, PV and the Octopus cheap rate electricity and it does not require intervention.
If I can find someone who has cracked it, then I’d like to copy your setup!
Yes it does work but it’s still not plug and play, fit and forget.
I have set restrictions on charging times to keep them within the GO cheap rate.
I am also using the hack version which is much better. DESS as others have said tends to allow the battery SOC to go lower and lower, only charging enough to get to it’s predicted SOC for that hour. If you then get a solar forecast that is low you may not be able to get through the day. Adjusting the battery price does effect if changing takes or not. A thing to play with.
Give it a try you can always switch it off🙂
Thanks for the feedback. I note you mention the ‘hack’ version. To be honest, I don’t want a system that needs that level of intervention. By contrast ESS is truly a brilliant system - works with the minimum of attention and just works as you would expect. I’m sure DESS will get there, but I feel the number of ‘moving parts’ or function points (as we used to call them in the old days!) makes it a far more challenging system to code and debug.
I have switched on DESS several times and switched it off again … always because of unexpected and IMHO odd decisions on when to charge batteries and/or when to consume from the grid. I don’t understand the logic of the system operation, and yet I have the system setup in what must be the simplest operating condition (two rate tariff from Octopus, no feed-in, Green Mode).
You can read about the hack version here. Victron software is open source for the most part.
It’s easy to install and reversible. It suppress or changes most of the odd behaviour that the standard DESS does.up until now I have been using a node red flow that uses weather prediction to decide to charge or not and by how much.
hi, I did read through that thread. It’s a very impressive piece of work.
But, I don’t feed-in. I have set the parameter ‘Can you sell energy back to the grid’ to No. I assume this means that export/feed-in is not part of the DESS schedule calculation. So, even if I wanted to implement the hack, it appears to me that I2 and I3 don’t appear to be relevant to the problems I’m encountering. Or do you see it differently?
My limited experience with the system is that it does not always take the opportunity for cheap rate charging, and certainly puts the achievement of Target SOC above the immediate opportunity to discharge the battery - even if that means consuming peak rate electricity. Attainment of the forecast seems to override what is happening in real-time. It buys expensive electricity now to keep the battery at a SOC level so that it can discharge it later when the electricity is just as expensive. So what’s the point … I don’t get the logic.
The first part may just have mathematical reasons. The system is only charging from grid, if it makes sence. It is not like it’s taking a full-charge on a cheap price, like a human would do. It is - based on the schedule and forecast - very conservatively calculating, that it now has to charge “X% soc” to have sufficent energy to enter the next sunrise at minimum soc. (Or a bit more, if the next day has weak solar forecast)
This also seems to include the battery costs and efficency figure of the system, which means that even if the price is “higher” from 0 - 6 am, it could conclude that it’s overall more cost efficent to pull from grid during that time over charging enough energy earlier the day for a cheaper price.
For example, takt his graph and assume a empty battery:
Charging at (1) would only make sence, if the price at (2) is higher than (1) + battery costs + 2x conversion-losses.
Mind, that every kWh the system would consume at (2) from the battery would be penalized with two times conversion losses, so needs a charge of roughly 1.3 kWh at (1):
So it would probably only charge to cover the orange area and decide to pull from grid at (2) with no conversion losses and battery costs:
I would tend to say, that this calculation is more precice than our expectation, but feels wrong for mainly two reasons:
having a grid pull on low soc just seems like the schedule was inappropriate and it ran out of battery.
Not charging much on low prices doesn’t line up with our (trained) behaviour to buy “extra” when it’s cheap, no matter if actually needed
For the second issue, yes, the original implementation has some flaws on supporting loads during scheduled charge or idle phases. My hack has a tiny improvement there:
Whenever a solar shortage is detected, during scheduled charge-phases, but the SoC is AHEAD of plan, it will accept to discharge to consumers until it falls down to targetSoc (again).
Hi, thanks for the feedback. Some interesting insights there. You mention ‘scheduled charge’ - I thought this ESS feature is disabled by DESS?
Your other points are clear to me - interesting you use the word ‘precise’. I’m not contesting the mathematics - no doubt very precise. But how accurate?
I’m wondering if the root problem is the forecast. Consumption is driven by humans and somewhat unpredictable. If I’m on holiday, then the house consumption would be predictable. But when I’m at home … anything could happen! If I decide I’m going to cook dinner in the oven rather than warm up some baked beans on a gas hob like I normally do, then I’m going to throw the forecast … (just an illustration, I don’t like beans).
My point being that the two drivers of the ‘plan’ are consumption (at best a guess) and the weather (a more educated guess). So, there’s a lot of uncertainty in the forecast. As you say, the system doesn’t have a trained ‘human’ behaviour to buy “extra” when it’s cheap - but why not? Why doesn’t the forecast buy as much as it can when the electricity is cheap? It doesn’t do so by design, not because it’s not possible. The uncertainty of the forecast is not recognised.
IMHO the correct behaviour, driven by uncertainty, would be to buy it cheap now and store it, even though I might not need it tomorrow, but who knows what the next day will bring. In effect, that’s what (I guess) most of us do with ESS and charging schedules.
It’s like it needs a “If the price is less than x p/kWh then buy as much as you can’” option …
This may not be of interest to all, but I’m in the UK on the Octopus Agile tariff. They publish unit prices once a day for 48 x half hour periods through the day, half a day in advance. This data is published on their API and it’s possible (if you’re so inclined) to read this data in Node-Red and determine when the price is worth importing from the grid. As I say, not everyone will want this level of involvement but it does give you precise control over how your system works, if you want it. For me it’s useful as I can top up my batteries at the cheapest possible rate when I need to. I’m not set up for export to the grid so DESS doesn’t work for me.
First of all, DESS is not just about exporting to the power grid. I don’t export anything and I use DESS intensively. There is often discussion here about whether DESS should buy more electricity at the cheapest times. That alone wouldn’t help anyone. DESS in its current configuration would then immediately use the surplus electricity to cover all times. But that doesn’t make sense when the price differences are small. That’s why the approach today is to buy exactly enough electricity to cover the most expensive times and distribute the electricity over the most expensive times. Buying electricity in advance to store it for the future would mean I would have to assign a price to this stored electricity and always check in the future whether the current electricity price is more expensive than what was stored. In my view, that would be a completely new approach that also has two risks. What if electricity becomes cheaper in the future? Will the stored electricity then stay in storage? When is the point of wasting it to buy even cheaper electricity? Second problem that will not occur now in winter but will again soon in the transition months. What if the DESS buys more cheap electricity than the forecast consumption? Then storage capacity would be tied up that could be charged with even cheaper PV energy. The system avoids both problem areas in its current configuration because it always works on the forecast consumption within the time for which it has prices and PV data. Please don’t misunderstand me. I understand and share your approach but I also see the dangers.
Thanks for the detailed explanation. I was really just thinking short term about how to ensure I can deal with extended periods without sunshine (as has just been the case with a week of fog). Normally (except in the heart of winter near the solstice) I can manage with PV power but I need to be able to top up when I am running low. The complexity of balancing purchase price with usage is a much harder problem to solve as you say.
hi, I used Agile for two years before switching to Go - purely because I couldn’t see any financial advantage with Agile any longer. This was before DESS existed, so it required a lot of manual intervention to get best advantage of the cheaper rates in Agile.
DESS (and ESS) are fantastic innovations from Victron. And all my comments are intended to reflect positively on their investment into these products. After all, this is what holds the attention of us geeks and keeps us coming back for more!
I posted my original question regarding Go - a simple two price tariff from Octopus. No export. Simples. I thought that DESS would manage this scenario easily - but it doesn’t. Or at least doesn’t do it any more effectively than I can manually (although ESS and very occasional manual intervention does a very good job).
The issue I see is the narrow adherence to ‘forecast’. There’s no wiggle in the tolerance of forecast accuracy - on either my consumption or someone’s view of the weather. Neither are likely to be very accurate. So, if the import from grid/battery usage is tied to forecasts that prove to be inaccurate, then the electricity usage will be inaccurate. To me, that inaccuracy usually translates into avoidable cost.
So, although I’ve tried DESS several times over the summer and into the winter, I just couldn’t find any time when it did what I expected. And always the explanation was in the forecast. So maybe build in some tolerance on the forecast - a customer selectable range for instance?
I get with a 30 minute spot price tariff with export that there are far more variables and it might look different in that scenario, so my perspective is very narrow. But, surely if a simple two price tariff seems to be a challenge, then the same will be true for more complex tariffs - just not so easy to see?
As yet, no one has yet replied ‘yes’ to my original post question ‘anyone using DESS and Octopus Go’.
I have developed a small strategy over the last few months that is very helpful but manual. On extremely cheap days I increase the Min Soc. For example, in November we had a few Sundays with extremely cheap prices, then I set the Min Soc to 70-80%. DESS charged the 75% plus what it needed for expensive phases until Monday evening. When I received the prices for Tuesday on Monday, I lowered the Min Soc to 50-60% soc if necessary and DESS then served the most expensive times. All of this throughout the week. But this is all due to my personal speculation and my manual tinkering and has little to do with calculations.
John you’ve hit the nail on the head there. Reliance on imperfect predictions will always be sub-optimal and without a forecast error margin it’s difficult to cope with that variability.
It seems to me that a tailored approach is needed for an individual’s situation if the automation is to be optimised.
