article

Dear Victron,

Im very happy with the new DESS. Running is for some days now i noticed that there keeps beeing injected excess solar power to the grid. I know that the current algorithm is a predictive analyses one and that the prediction part has limits and works in the long run and can be off now and then. That explains why that happends. But maybe you can add an option in the future that tries to keep all the solar in the battery (non predictive) like the ESS option does. This option could increase the businesscase for DESS depending on the Solar costs. This is also better for the lithium battery’s because the battery’s will get more to 100% and ballance more often. This reduces the risk of unbalanced battery’s because the “with battery protection” option is not a very good combination (financialy/pratical) with DESS.

Greetings

Hello.
It is clear to me that smart forecast-based planning is difficult, especially because of the unpredictability of production as well as consumption.
The result, for me, is almost always wrong. For me, it would be quite sufficient to control the ESS charging mode, ESS discharging mode and SoC settings. So - if the price is below X charge the ESS, if the EV is pinned start charging, if the price is above X use only the battery, if you reach SoC XX then switch to the grid. I'd like to get notifications about everything. Even advance notice - there will be a low price, if you can, plug in the EV. Buying surplus for me only from PV if the above is met.
That said, a scheduler based on SPOT prices is fine for me.

Thanks for the great work! I tried to find the setting for Germany that prohibits discharging the battery to the network, unfortunately it was not possible? I have the latest 3.11 version and also updated in Node-Red and use beta-VRM? Or does the disabling of the discharge of the battery happen automatically? Because then it does not work. Today the DESS wanted to load battery power into the grid again. Although only an extremely small solar forecast exists and also the solar remuneration is very minimal compared to the purchase price for electricity.

Hi Dirk-Jan,

My DESS give a alarm. Dynamic ESS battery level unknown

In VRM the battery level is shown. So maybe it’s a fault in Dynamic ESS software.

It may be just me interpreting things incorrectly but it seems DESS is handling AC PV the same as it does DC PV. Whereas AC PV for me has about 8% efficiency loss going in and out but DC PV only has 8% loss going out and negligible chemical losses going in.

I tried using battery costs to incorporate efficiency losses but these numbers will be different for AC PV and DC PV.

Can we try and distinguish between the two please ? At this very day with a low of 28cents and a high of 35cents just storing AC PV in the battery will cost 31 cents without battery cycle costs (and 33 cents including one-way battery cycle costs). Getting it out of the battery will cost another 3 cents making it 34 cents without having calculated battery cycle costs So kind of pointless. But storing DC PV is actually what the system was designed for and only costs 3 cents making it 31 cents.

For those that do calculate their battery cycle costs, storing energy in NL on days like this is rather pointless with a 10cent total cost :-)

@Dirk-Jan Faber thanks again for that tremendously fine piece of work!

Please note: "Add a setting to disable selling from battery to the grid for your installation; as required for Germany as well as other areas." is only one half of the story. It depends on the type of metering installation ... in my case I am allowed to feed-in/back from batttery to the grid but not allowed to charge the battery from the grid.

hence such a switch in the setting should cater for both variants!

@Dirk-Jan Faber thanks for your effort.
"Removed the separate Dynamic ESS SOC" - Can this feature still somehow be used with the Node-RED implementation?

Considering the enormous amount of kWhs going into an EV even in relation to my rather power-hungry house, I for one decided to not charge batteries from batteries unless I really have to.

Not so much because it's a bad idea, but because it's human planning/logic that is too hard to automate. Too many variables. As there is no right or wrong here, would it be possible (or already the case?) for the forecast calculations to not incorporate consumption data generated whilst DESS was in "Off" state. That way some of us may be able to "skip" the excessive consumption windows by switching from auto to off and back for EV charging.

And for home automation enthusiastics out there, can we make the switch available using modbus please so I can trigger auto/off and back if a charger is in use ?

I realise this will not cover all use-cases. But I do hope for some it improves the daily use of the new DESS product and it may provide Victron with better statistics pending the silver bullet for EV charging forecast.

> This can be less ideal, but it is an issue of the forecasts being inaccurate, nothing that the Dynamic ESS decided

I agree, but for Dynamic ESS to be truly dynamic it needs to also deal with the situation where the forecast is not accurate. The current algorithm is great, but there needs to be a second algorithm that is used within the 1hr slots that deal with.

- Lower than forecast average/instantaneous PV production (due to clouds for example)
- Higher than forecast average/instantaneous consumption (due to cleaning/cooking etc.)

It's a shame that there is nothing in your post-release roadmap currently to address this, as a lot of people (like myself) will avoid using Dynamic ESS when they see it i) importing at expensive times when the battery is nowhere near empty, ii) exporting at very cheap times when the battery is nowhere near full, just because it's following target SoC blindly without accounting for actual PV/consumption.

> Allow to specify a feed-in time range to allow for selling from the battery to the grid at set times

Will you also add a time range to allow import? Providing time ranges to allow import and export could be a way of manually addressing the concerns above, especially for people on fixed rates with a cheap rate overnight who don't want to ever import during the day, even if PV/consumption doesn't match the forecast. Ideally separate configuration of this shouldn't be needed if the tariff has already been defined though.

I still think there must be some way to combine Dynamic ESS for the day planning with ESS (with specific min/max setpoint and SoC parameters) for the instantaneous management of import/export. Has the team given this any thought?

Does anyone else have issues with the new charts ? For me they work some of the time but since this morning I have no SOC forecast in the system overview section, no numbers in the costs and earnings (it does show the graph) and no energy overview.

Happened yesterday as well but seems to have resolved itself until this morning.

Hi Team, Editor,

Can you please replace the Energy Graph with the correct one? If I look at every chart: price, battery, grid, etc. the energy one doesn’t make any sense, it shows a different day and/or different site. It’s wrong in the manual and in the Node-RED page as well. Please add charts that belong together.

Thank you

Miklos

As every house(hold) is different, making this fully customisable would defeat the purpose of a consumer grade / fully automated portal. But.... if we simply trust the Installers to have done their calculation well, we already have the number we are looking for: the capacity of the heat pump.

Can I suggest to allow the configuration to request the capacity of a heat pump if any so outside temperature and solar forecast can be included in the algorithm ? In my case the last days have been cold by average but we had loads of sunshine. So the heat pump worked hard a night and was not needed during the day and evening.

Couldn’t find the answer on my question below:

1. When running in DESS. Will the system switch to ESS during grid outage? (Disconnect AC in)

In DESS mode the system give overload warning on L1 L2 and L3. Is it a glitch in DESS software? or can I prevent it by throttle down the “maximum discharge power” in DESS settings?

Currently running 12kw maximum discharge power with 3phase multi 48/5000 environment temp is 23.5 degrees Celsius

I have defined no different prices on weekdays and weekends:

But the summary shows the opposite:

I just activated DESS last night. Shouldn't the target SOC also be shown in the forecast in today's system overview? However, target SOC is actually missing:

At What is Dynamic ESS? | Dynamic ESS Overview the example image looks like this:

Why isn't it shown on my installation?

Great work! Just enabled DESS also on my Installation for testing.

I think somewhere on the Webinar I've heared that BatteryLife should be disabled when using DESS. I was wondering how i can keep my battery in a good charging state then?

Hi Dirk, will this dynamic ESS allow us to also ignore ac input for those of us who don’t live where export to grid is allowed , so we can also enjoy ESS features without export?

Thanks for the great work! Really looking forward to this. Everything works fine for 2 days now accept the dynamic ess dashboards. The cost view stays blank, the energy view stays blank and the planning view only shows the history and not the forecast. How do i get te dashboards working?

Greatings

Think I said somewhere this week calculations were pretty good. Right after posting that the decision making process was less successful.

Seems that the battery costs now match the documentation. Instead of the costs being calculated twice for ingress and egress they are now calculated as a cycle as mentioned in all the documentation. Description of the setting has been changed accordingly. Would have been nice to get a small heads-up as that influences the decision making.

After correcting the battery cost setting I still have moments in which energy is bought from grid only hours before it will be a lot cheaper and vice versa. It's mostly smaller amounts so I am happy leave it alone for now. Last but not least, the graphs are still odd. After midnight nothing shows and scale changes from 1h to 30mins. And as mentioned elsewhere in this thread, calculations and energy often simply do not show.

Switched to buy last night and this morning with batteries at 100% DC PV was holding back / not producing. Switched back to auto and all is good. Feed to grid for DC is enabled. Is this works as designed?

As has been mentioned by other commenters, Octopus Energy in the UK is the key supplier for many, if not most, of the energy savvy users in the UK. They are quite innovative in their tariff offerings. In particular, the Intelligent Octopus Go tariff has seen a growing uptake of late. This provides a fixed 6 hour window of cheap rate electricity, coupled with dynamic slots outside this window where your EV will also be charged. These slots are determined by Octopus at the point you plug the charger into your EV. Octopus then commands your charger (Ohme/Zappi only at the moment), or your EV (several manufacturers supported) to charge during these periods. The key consideration is that your entire energy supply becomes cheap rate during these periods. This approach however has implications for your battery - if you do not manually intervene to put your battery into charge mode, then your battery will drain to supply the EV rather than using the mains!

DESS looks like it could (eventually) provide a basis for automation of this functionality, which would be a very welcome development for UK Victron users. I understand that this may not be a priority for Victron initially, but I want to at least get it on the radar along with some basic background info.

Support for half hour scheduling slots is a key prerequisite for *any* UK tariff support - even for fixed schedules, so hopefully that will be implemented sooner rather than later.

Home Assistant already has multiple plug-in support for determining these dynamically allocated EV charging slots, so perhaps there is a halfway house solution? Is there a way (DESS or otherwise) for Home Assistant to either put the Inverter in and out of "Keep Batteries Charged" mode, or to add charge slots into the ESS schedule, via Modbus or MQTT?

https://octopus.energy/blog/agile-smart-home-diy/

https://developer.octopus.energy/docs/api/

https://www.guylipman.com/octopus/api_guide.html

https://github.com/BottlecapDave/HomeAssistant-OctopusEnergy/blob/develop/_docs/entities/intelligent.md

There are also (for some UK regions) Octopus "Power-Ups" which are slots with completely free electricity, when green generation is exceeds demand locally - that also would be good to recognize and automatically schedule battery charging for.

my PV system is AC connected. compared to the PV system, the battery is small.

PV: 47,5kWpeak, Batterie 4,8k Wh (no connection from victron to the PV inverter)

Observation after setting up the dynamic EES:

- No value display in the trend energy (Loading...)

- Consumption from the storage <50% a day (Before mostly 1 cycle a day).

- Display expected PV generation is missing (prediction for power / m² is present in the extended trend) [Should be calculated in this setup via a parameter (is there any existing parameter?) or via a model derived from the electricity export].

- Target SOC often too low in high price periods.

Settings:

- No grid feed

- Optimized without battery life

- Dynamic ESS Auto

Is there another setting I need to check? With the option I had the hope to increase my battery usage in the expensive periods. Currently, despite Dynnamic EES here, I still have high power draw and battery usage has dropped to half a battery cycle. On bad weather days I also lack the discharge during the day when dei PV generation is not sufficient and with the expected PV yield the battery can probably be charged again.

energy.pngprice.pngtrend.pngTrend_october.pngEES.png

@Dirk-Jan Faber can you please help me understand the import / export power settings ? Documentation says to set import export to grid max or system max which ever is lower. It also says this is only used for calculations not for imposing system limits.

In my use-case this means the charging forecast during cheap rates is limited by the consumption forecast. In other words, it's subtracting consumption from grid limit so it can charge what little remains.

I have a 3 fase MultiPlusII setup and the system efficiency is better if not running at full power. I have therefore configured grid in to 3.75kW (75A) and export to 4,5kW (90A). Combined with heatpumps and/or EV charge forecast this results in DESS not charging at cheap rates as consumption is higher than grid import export settings. Whereas like you, we have 3x25A = 17kW grid connection.

I can follow documentation and set grid to system capability (import 5.250 export 7.200 or something like that) but even 5,2kW import with a big heat pump, or worse, BEVs will still prevent the system from charging. Unless of course, I simply enter 17kW but that would break import export calculations.

So basically my question is; How can I ensure DESS calculations to charge are still OK whilst not being limited by the grid import setting. Can I separate settings for calculations and actual grid connection to prevent consumption forecast from outweighing charge.

Hello Dirk-Jan,

thanks for implementing the restrictions for Germany. I activated "Disable discharging to grid" and started a new try with DESS. The new settings do what they should do but I have another thing to complain.

This is todays result: (min SoC is set to 30%)

I was surprised that the system started to feed in after reaching merely 60% SoC. There would have been enough solar today to easily reach 100% SoC.

The price structure here is a rather high dynamic buy price p+0.22 and a low constant sell price 0.07. So for my understanding it should be never a good idea to feed in exept the battery is at 100%. It should be the target for DESS to avoid buying from grid as much as possible. If buying from grid is not avoidable because of bad weather or a too small battery the DESS should try to buy in the low price hours.

Can DESS achieve this with appropriate settings? What should they be like?

Hello.

I have tested the functionality under different situation and there is something strange to me (Venus 3.12 / Dynamic buy prices): It feeds energy into the grid once there is solar power available. My VRM ID is: b827eb9face6

Did I miss to configure parameters correctly? I would assume that the solar energy is to be stored into my battery. Especially because the forecast says that I will run in batteries later on today:

Minimal SoC is 35%.

Thx, Holger

Hello, is it possible to implement a dynamic Tarif for Austria —> EPEX AT, awattar, smartcontrol, spotty (all the same)

How long could it take to get dynamic hourly prices implemented?

thank you.

Is anyone else having a problem logging into, and using betavrm. on Android devices now? I've tried different phones and tablets and both Chrome and androids native browsers. Normal vrm. works fine on all my Android devices, it's just the beta vrm.

/login reports invalid credentials even though they're not and the bookmarked dashboard page loads only the header and transport buttons but no ccontent. The problem started about a week or two ago, possibly at the same time I upgraded my Cerbo GX to the latest version.

Hi,

as I'm currently experimenting with different approaches, to charge with cheap grid prices and top up with solar, I know how difficult this whole topic is and also that it is not easy to make it right for everyone.

As it doesn't make much sense, to implement this myself, if it is already in progress of being added here, I'll try to help out as much as possible instead, so I can just use the provided functionality here and save time.

I tested this a bit and as it is highly dependent on the predicted forecast (both consumption and PV), so far this does not really work out well for me.

I charge my EV during times, when the price is very cheap. That randomly happens and is not really predictable. So the problem with that is, that the consumption prediction is totally off as can be seen in this screenshot:

The day consumption for today is way too high, i don't consume that much during the day normally. Also the nightly consumption has an average of 2kWh per hour with peaks up to 6kW. As can be seen in the first few consumption bars, my nightly consumption normally is around 300-400W.

As I still want to charge my car, I need a way, to tell the Victron system, that it should ignore a certain amount of energy, which I can provide to the system easily via node-red or any other means.

The thing is I have two EVs and I don't want to charge them from the battery anyways, so they should be completely ignoerd by the system. Would be nice though, to still see them in the dashboard, but they should be ignored for dynamic ESS.

So I see these options as a feasible solution to the problem:
- provide an API or something within Venus OS, to let the system know, the car is charging and with how much energy
- provide an API or something within Venus OS, to upload time scheduls, where the car charged, so the forecast can be re-trained

Either way this has to be implemented, as these kind of consumptions are just not predictable, especially if people have the possibility to wait for cheap prices, which normally happens once a weak or so.

@Dirk-Jan Faber is there maybe a way, to already let Dynamic ESS ignore the EV power consumption via node-red somewhow? It's also possible for me, to write a script, which emulates my charger as a Victron charger internally, if that helps.

Keep up the good work and let me know, if I can help out somehow, to test with EVs.

Dynamic ESS does not take into account the generation of AC-coupled PV for the export limits. I have a 6kW (3ph) Fronius and have limitted the Dynamic ESS feed in to 12kW. There is also 6kW of DC coupled PC. If I set Dynamic ESS to "Sell" it dumps 16kW into the grid - 12kW from Multis (batt plus DC coupled PV), 6kW from the Fronius, less 2kW going to loads.

To me it looks like the recalculation (that in node-red happened every 20mins) doies not seem to have any effect, when there is actually a change. For example tonight there was a foreast of a 3kWh consumption, so the system added a schedule to not discharge after that for 3h. However that forecast was wrong, so the battery had much more left, than forecasted, so my assumption would have been, that the schdules update and the battery actually discharges. But it still paused for 3h, after the forecasted consumption, although the battery level was really high:

The initial forecast showed a drop of 20% or so, but as you can see the actual consumption was way less, so there was no big drop.

I'm experiencing about 80-100W continues battery discharge when the system is forecasted to be idle. Target SOC is the same for the foreseeable future and no DC PV at that time.

This behaviour causes the battery soc to drop around 2% in a full night which is OK I guess as energy is inverted to consumption. But knowing the 3 multi's are not very efficient if jointly managing 100W "battery drain" I was kind of wondering why this is happening. Why not save energy so it can be inverted when rates are higher.

If I set min soc to the current value the system comes to a full stop. Battery 0W idle and the Multi's stating that they are using about 11W. The same as you'd see if you let DESS discharge the battery on days where buy and sell are not within a profitable range.

If you sell and end up with a soc that is lower than originally forecasted, DESS will immediately start charging to forecasted soc for that hour if changing back from sell to auto. In this example the sell ended with 41% a few mins past the hour whereas the forecast said 42%.

Suggestion to recalculate the next 4 hours for this use-case?

I'm lost.

I've setup the system like so (see image), but for some reason it is still giving back to the grid.
Should it not put this back into my battery's 1st until the battery's are full?

My setup is as follows.

3 phase going into the house (3x25A) <> Energy Meter ET340 L1, L2, L3.

My Victron setup consists besides of a Cerbo GX, one (1) MultiPlus-II 48/5000/70-48, an array of 28 PV's connected to a SolarEdge, and two (2) 10kWh battery's.

The "weakest link" in the setup is the MultiPlus-II as it can only charge / discharge the battery's with a max of 65 amps (3.5kW) . (note that the the battery's itself can handle 200 amps)

What I do not understand is why the setup decides to give back to the grid, and not put it into the battery!
I would have thought that this 545 watt's would 1st go into the battery's reason being that the 3.5 kW charging is not reached, AND that I have told it NOT to "sell back to the grid"!

Did I make a misstake in my setup configuration, or is this a normal thing?

Any help appreciated!

Hallo @Dirk-Jan Faber ,

Is that just my impression or will it no longer be possible to follow these long threads in a meaningful way at some point? It feels like new posts appear everywhere in the thread but you have to find them by chance. Or do I not know the right trick?

Apart from that you are doing a really cool job with VRM and also DESS. Even though I am a strong critic of the Target SoC method, I think in the end you will offer something that will help (almost) everyone. Keep it up and thank you very much!

Best regards

Olaf

I noticed two things when entering the details for a fixed contract with different buy and sell prices for weekdays en weekend. I entered 'yes' for the buy prices, but the summary shows 'no' while the schedules still show the different prices. For the sell price it is the other way around.

The consumption prediction really is ridiculous:

I charged my car again tonight, and suddenly it estimates a consumption of 10kWh for each hour of the rest of the day.

I managed to add my EV charger to VRM:

As you can see the consumption is known from the charger around the night time.

@Dirk-Jan Faber wouldn't it be an easy first workaround for the users with EVs, that you can enable ignoring EV consumption? That would probably really help those people. It's really useless for me right now...

In DESS, you have to enter the Maximum Charge Power. That is usually the max charge power of the Multuplus configuration. That works well with AC solar inverters and grid connection. But what if I have a SmartSolar, which does not need the charge power of the Multiplus? It is additional charge power, but it is only available when the sun shines. And I want to use this SmartSolar power to charge more energy in less time, when the prices are low. How does DESS deal with this? Will DESS limit the grid power when SmartSolar kicks in, or is it indeed additional to the charge power as entered in the settings?

I haven't been able to find anyone addressing this in the comments. I've been testing the DESS since the beginning of the month and I've noticed peculiar behavior when there's no planned battery discharge for consumption. The sensor on the multiplus appears to be 'idle,' but the smartshunt keeps showing consumption. In my case, it's around 1% over 5 hours (360w). It's not much, but it seems unnecessary to me. When the battery percentage reaches the set minimum, it stays 'idle' reliably and doesn't discharge at all.

The second issue pertains to charge scheduling. I've set 'max import' to 15kW, 'max charging' to 10kW, but in the plan, I see it wants to charge, for example, 25kWh within a single hour. When it fails to do so, it continues charging in the following hours. That wouldn't be an issue if the first hour didn't start just as the price per kWh begins to rise slowly, resulting in unnecessary charging at a higher cost.

Hello!

How can i add flexible grid fees to electricity price? I have 0,07 eur grid fee for daytime and 0,04 eur grid fee at night.

Hi,

which electricity price stock exchange index is used by DESS in the price formula for "p"?

The Austrian provider aWATTar uses the index “EPEX Spot AT”:

(https://www.awattar.at/tariffs/hourly)

The formula then reads as follows: (p + |p| * 0.03 + 0.015) * 1,20

I entered it like this because there is no possibility to use the absolute value of p in the formula, so the buy-price will be calculated wrong if p < 0:

So there are two questions:

1. Does DESS actually use the index “EPEX Spot AT” for “p” if Austria is specified as country or what other index?
   
   
2. "p" is actually sometimes negative. However, the 3% fee is always calculated fom the absolute value of p, i.e. |p| or ABS(p). Unfortunately, it is currently not possible to specify the absolute value of p in the formula. Can this be added?

In Australia, we have an option of dynamic 5 minute pricing for import and export. I plan to try setting up fixed hourly prices using historical monthly averages and experimenting a little.

I don't see any comments about handling of negative feed-in prices. Is it fair to assume that the model supports negative prices?

If so, does it curtail export by disabling solar controller export and limiting feed-in to zero, as per Fronius zero feed-in option ?

If not, is it possible to turn off Dynamic ESS during periods of negative feed-in price by mqtt or modbus, allowing normal ESS to manage battery charge, and then reactivate once prices have returned to positive, allowing Dynamic ESS to recalculate a new plan for the next 4 hours?

Regards

My DESS give a alarm. Dynamic ESS no matching schedule IMG_5456.png

When entering time schedules how do you enter for example 23:30 - I cannot get it to accept any input ?

I would suggest to add an extra button in dashboard control section, additional to Auto, Buy, Sell, Off.

Lets call it: Standby

In Standby-Mode I would like to see all the different graphs and simulation for the DESS in the dashboard. Calculations should be made according to your algorithm and time schedule but:

Leave all the parameters for SOC, Charge or feed-in the live-system like in OFF Mode.

So I can check the DESS-System and can change some parameters to see how it would change the resulting planning/doing of the DESS without immediately resulting in real live changes on my system.

Yes there would be some deviations compared to the live Auto-System running.

But for checking and testing before switching to Auto-Mode (for me) it would be interesting/helpful.

Best regards

It would be great if DESS would record grid buy price even if it's set to off.

This would help me to calculate if DESS could be a profitable feature for me.

At the moment, prices in Germany seem to be developing in such a way that a fixed annual tariff could be cheaper than a dynamic tariff. If the PV is large enough, you only need it when the weather is bad and that's exactly when even the lowest price per day is almost as high as a fixed price. Unfortunately, with a few% losses, DESS would often be useless here.

Using Nod-Red DESS and it looks very promising. The only thing that completely ruins the behaviour/prediction is when I charge my car. The amount of energy compared to the usage of the house is way higher. My normal way of charging the car is schedule it to charge on times when the energy price is low directly from the grid. I made a small Node-Red flow to make sure that the energy is taken from the grid when I use scheduled charging (with a Victron EVCS). See attached file.

My suggestion, as a first step, would be that when scheduled charging is used then do not take this amount of energy into the prediction calculation of DESS. The best would be if we could indicate in Venus that we want scheduled charging from the grid (and not from the battery) then this would make a (part of) the solution how to handle the energy taken by the car in a DESS situation.

EVCSfromGrid.txt rename .txt into .vcsf or paste content directly into Node-Red input.