Dirk-Jan Faber (Victron Energy) avatar image
Dirk-Jan Faber (Victron Energy) posted

CLOSED - Dynamic ESS on Beta VRM (use new topic please)

There is an updated post on this subject: Dynamic ESS on Beta VRM - part 2
Please comment below that post in case you have questions and/or need assistance.

I am happy to announce that Dynamic ESS is now live on beta VRM, which is highly interesting for everyone that has a ESS system in combination with a dynamic energy contract (with day ahead prices).

Dynamic ESS is an algorithm that aims to minimise the costs made on the grid and battery:

  • By scheduling charge/discharge cycles of the battery,
  • While taking grid limitations, battery specifications and day ahead energy prices into account,
  • When it can, it also considers the consumption and solar yield forecasts when scheduling.

This has been running for a while now on Node-RED where we got the first child diseases out. It is now time to increase the audience, so hence the roll-out on beta VRM.

You can get started with it on beta-VRM via Settings → Dynamic ESS.

There is a (work-in-progress) manual and this article will be updated too the coming days. All feedback can be provided below.

Note that Dynamic ESS applies mostly to countries in Europe that work with so-called “day ahead pricing”. For fixed priced contracts, the VRM version can also be used outside these countries.

For those of you who aren’t familiar with beta VRM, you can log in through this link with your normal credentials.

A webinar about this subject has been held on the 26th of September. The recording of the webinar can be found on our YouTube tech channel:

Note that there is no need to tag me in posts. I do read and see all messages if you don't tag me as well.

ESSdynamic essbeta
2 |3000

Up to 8 attachments (including images) can be used with a maximum of 190.8 MiB each and 286.6 MiB total.

energymonkey avatar image energymonkey commented ·


Great work, real game changer!!!

The UK is not in the drop down list for Dynamic ESS - we have Octopus Agile which I believe this would work for this tariff allows you to buy when cheap at specific times and also sell back.

Economy 7 is a different tariff that has a fixed time for cheao electric - better for the fixed setting.

Is this a Beta bug or is this something to do with another reason.

Please can this be added...

Regards Paul.

6 Likes 6 ·
Peter avatar image Peter energymonkey commented ·

Try It supports UK tariffs.

0 Likes 0 ·
Christian Butterweck avatar image Christian Butterweck energymonkey commented ·

You can also try with the Entso-E API. It supports whole europe, runs at the background on Victron Venus OS or other Unix / Linux & Windows systems, takes solar yield, charging losses and battery lifecycle-costs into account and additionally supports switchable sockets. For german users, the aWATTar and Tibber APIs are integrated too.

0 Likes 0 ·
peregrines avatar image peregrines commented ·

Wow! Thank You for your fantastic work!
I have been dreaming of something like this in VRM!

Now I just need to figure out how to implement my "Awattar" hourly rates (Austria) into VRM ;)

Edit: I just tried it and it immediately started to charge from grid (but my 57kw batteries are have full and grid prices are very high right now). So I must have done something wrong :(

1 Like 1 ·
dirk-s avatar image dirk-s peregrines commented ·

The same here on my installation. It charges from grid also in case of much solar forecast and 50% SOC.

Currently it use power from grid for my consumption and SOC is 70%.

Either there is an error in beta.vrm or it works not with installations with solar. Currently I‘m also much confused.

I hope for explanations in the webinar on next Tuesday.

1 Like 1 ·
sieade245 avatar image sieade245 dirk-s commented ·

My installation also does this. My setup is very simple also because I am on fixed pricing. 7.5p per kWh from 23:30 to 05:30 and about 30p per kWH all other times. I assumed that the algorithm would aim to charge during the off peak period but I turned it on today and it instantly started charging from grid during the peak period.

Currently I have to check the solar forecast manually each evening, compare against my current SOC and my anticipated load for tomorrow then work out whether I want to schedule a charge in the off peak period due to a lack of solar the next day. I'm hoping DESS is the automatic solution to this but think I'll need to wait for the manual to be fleshed out a bit to work out how to use it

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ sieade245 commented ·

Can you provide the VRM id’s of the systems, so we can take a closer look at the reasoning of the systems behavior?

We did test on several different systems, but as it is beta right now, more adjusting is probably needed.

0 Likes 0 ·
dirk-s avatar image dirk-s Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

My VRM Portal ID is c0619ab101c5. The ID from the VRM Link is 133372.

It hurts to see that the system toke 8,5kWh from Grid today (in total 18kWh consumption today). There was enough Solar forecast.

It never discharge below 50% of the battery. Therefore it takes the energy from Grid instead of battery during this night.

I keep it running, because I want to understand how it works. But it seems I daily use more energy from the grid than the whole month before. I have flexible energy costs in Germany (Tibber).

It seems that it hourly adjust a target SOC in the Dynamic ESS menu and try to reach it hard in this hour. If there is more consumption than forcasted it takes it from the grid instead of battery (night and day time). If there is less energy from solar than forecasted it takes it from the grid to charge the battery to the target SOC.

0 Likes 0 ·
1695584061137.png (18.2 KiB)
sieade245 avatar image sieade245 dirk-s commented ·

I have just seen this exact behaviour on my system too. I was at around 93% battery, with solar excess and feeding back to grid so I decided to charge the car. This initially used more power than solar could provide so batteries started to discharge to make up the difference as normal, my low cut off is at 70%. I checked a while later and the batteries were idle around 91% and all extra power was being pulled from grid at peak rate. Checking remote console, the DESS target had increased to 91%. I turned it off, the system started working again discharging from the batteries. So then I tried turning DESS back on and it instantly started charging the batteries at full power from the grid. Coupled with the car charger load this was around 6kW at peak rate from grid. I think it started charging the batteries because the SOC had dropped to 89% below the DESS target. So similar to your explanation, the system aims to hit that DESS target via charging (whilst loads are also supplied by grid) and then it idles the batteries and supports the load via the grid.

1st picture below is with DESS on. 2nd picture with DESS off. For same time/ load



1 Like 1 ·
dess.jpg (456.2 KiB)
dess2.jpg (462.9 KiB)
sieade245 avatar image sieade245 Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

My portal ID is b827eb52ffd9. I've carried out a full charge last night so will turn DESS back on if you want to have a look shouldn't cost too much if it decides to start peak rate charging again

0 Likes 0 ·
daza avatar image daza sieade245 commented ·

@sieade245 sounds like you are on Octopus intelligent in which case some times in the day they give you a 30min window when your car is plugged in at off peak rate if the dynamic ESS could know when that rate comes it that would be great.

0 Likes 0 ·
daniel-feist avatar image daniel-feist commented ·

It would be fantastic if there was a way to "test" an alternative fixed tariff to determine if an alternative tariff would make more sense financially.

In the U.K. we have Intelligent and Flux tariffs available with Octopus. Intelligent is a lot cheaper to import at night, but doesn't pay the same export rates. It's hard to know which tariff is best, or at what time of year it makes sense to switch tariffs, but it seems that with the data Dynamic ESS has this would be easy to determine.

Actually, another use case for simulation is battery upgrades. If I add an extra 20kWh battery, will it improve things financially or not?

@Dirk-Jan Faber Can you add simulation to your backlog for once the basics are stable? Would be super cool and powerful

1 Like 1 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ daniel-feist commented ·
It is an interesting idea. But, considering all other requests, it will probably not reach the top of our priority list for a while.
1 Like 1 ·
daniel-feist avatar image daniel-feist Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Is there was a way to refresh the schedule and graphs manually, rather than having to wait an hour. If there is a way to do this it would be possible to do something similar to this without a specific feature. It would probably be best to do it just after midnight looking forward 24hrs:

1) Wait until 00.10
2) Take a screenshot of the schedule/energy graphs for the day ahead.
3) Change tariff, battery capacity or battery charge/discharge rates
4) Force schedule update
5) Take a screenshot of the updated schedule/energy graphs
6) Revert tariff, battery capacity and battery charge/discharge rate config.
7) Compare screenshots at your leisure.

Of course, this feature could be super powerful and suggest changes based on the cost of Mutiplus, the cost of battery storage and other available tariffs, but that is more complex and it requires knowing about all these possible things and simulating them all, before offering up suggestions.

I'd be happy with the basic/manual process for now, but how can we do 3) and force a schedule update without waiting until the next hour @Dirk-Jan Faber ?

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ daniel-feist commented ·

We are working on getting the graphs ready for next day + old data in VRM. Right now only the Node-RED implementation can look 33 hours forward (after 15.00) (see

AFAIK forcing a schedule update without waiting for the next hour is not possible.

0 Likes 0 ·
stroller avatar image stroller daniel-feist commented ·
Hi Daniel, there are a number of App's that will automatically do a comparison for you of all the Octopus 'smart' Tarrif's along with a number of examples of spreadsheets that will show/guide you to what the 'best' Octopus Tarrif is for you based on your energy usage.

At the moment, Dynamic ESS for half-hourly changing energy costs cannot be used for the UK, only if you have set period/fixed unit prices.

0 Likes 0 ·
daniel-feist avatar image daniel-feist stroller commented ·

Those apps are based on past usage. The reality though, is that with a different tariff, dynamic-ESS would change it's behaviour accordingly. So a true comparison could only be done by Dynamic ESS functionality.

0 Likes 0 ·
honzaxw avatar image honzaxw commented ·


This is a great add-on to VRM. I am very glad I went for Victron solution last year. I already tested DESS several times (VRM beta version), checked my settings, watched the webinar, read through this thread.

Still, I experience similar issues already mentioned here.

To my understanding there are two key components in DESS - scheduling and processing the schedule. The scheduling is indeed difficult due to forecasting. It can be hardly always perfect. Still, this can be tuned by users in the NodeRed DESS version.

It is the schedule processing (via hourly target SoC) that I observe not optimal in its current state. DESS seems to treat the hourly target SoC as a fixed objective without taking changing conditions into account. Within one hour it starts feeding in energy from the battery to the grid, only to use the grid for the direct consumption or even charging the battery later on, because the target SoC was reached well before the end of that hour. All that during the priciest hour of the day. The result is obviously the net loss for that hour.

How about to tag the whole hour as "sell" or "buy" based on the difference between starting SoC and the target SoC?

  • In the "sell" hour I would never actively buy back (direct consumption or charging) from the grid and let the SoC go even below the target SoC due to higher then scheduled consumption, only respecting the minimal DESS SoC.
  • In the "buy" hour I would never sell to the grid, when the target is reached sooner, only it case there is an excess PV (battery is throttling charging) and the selling price>0.

Or simply speaking once the target SoC is reached, the DESS could switch to normal ESS for the rest of an hour (respecting the disabled feedIn for selling price>0).

Does this sound reasonable to you?

My VRM ID: 48e7da89959b

1 Like 1 ·
daniel-feist avatar image daniel-feist honzaxw commented ·

Your observations are very similar to mine. High-level scheduling based on grid pricing is fantastic (good job Victron!), but the hourly SoC-focused implementation just doesn't make sense in many cases and can actually lose you money.

I like the idea of "buy" and "sell" hours determined by the master schedule, and then more logic to determine what happens during the hour. It's not as simple as reaching a target and then switching to ESS though, as there is also the case where it can't even reach the target and will import at a bad time. That said, your initial description I think is correct. In order to implement your "buy" and "sell" periods you'd need to combine a target SoC and mechanism to prevent selling/buying during these periods. In this case, the target SoC and the actual SoC at the end of the hour could be different.

The only problem I see with this approach (and potentially why Victron haven't done this) is that a simple tariff with 2-3 different prices during the say this approach seems obvious would prevent unnecessary import/exports and give you the best financial result but in the case of more dynamic tariffs "buy" and "sell" are more relative and things get more complex. For example, if you have reduced consumption then it seems obvious to store the excess in the battery if the grid export rate isn't very high, but with some tariffs filling the battery more during this period may actually prevent you from importing at a very cheap (or negative) rate overnight! It's a very interesting problem, and challenging to try to meet all scenarios with a single algorithm.

0 Likes 0 ·
g8n avatar image g8n commented ·

Hello, I have already spent quite a bit of time on the Dynamic ESS and tried it out on various installations. I have tested both the Node-Red variant and the BetaVRM variant. Maybe I don't understand the purpose of the Dynamic ESS? I have searched to see if I can find a flow chart that explains how the decisions are made in the Dynamic ESS? My expectation would be that the Dynamic ISS would reduce my electricity costs.

My expectation would be (for Germany)

1. Solar direct usage

2. charge the battery for the night and maybe the next days

3. if the battery is full, then feed the unused solar into the grid

4. if battery charge is not expected to be sufficient, then grid use at low prices priods and maybe Car charging.

5. if there is not enough solar forecast for consumption and battery charging then charge battery from grid but only if grid price is at least 20-30% below average because of the resulting charging losses and discharging losses.

Whenever I turn it on, however, it does weird things and this on different installations. All installations have the latest 3.10 version and have been running for more than 28 days.

Some installations use electric cars that are occasionally charged in solar surplus or installations with the Victron Wallbox that charge in solar surplus. As a result, consumption fluctuates greatly between 7kWh and sometimes 60kWh a day, in since the past months all from Solar. Also because the pools are no longer in used. And the heat pumps are still switched off. If I have configured the Dynamic ESS and switch it on including solar feed. The system immediately starts to feed the batteries into the grid. If I switch off the solar feed, the system suddenly starts charging the batteries from the grid. It is not clear to me how the respective target SOCs are calculated?

Perhaps someone could clarify this.

Thanks a lot

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ g8n commented ·

The purpose of Dynamic ESS is to minimise the running costs made on the grid and the battery. So it should reduce your costs. Mind that the running a battery also costs money, so that is accounted for in the decision making as well.

The system can only look 9-33 hours ahead (assuming new day ahead get in at 15.00), so scheduling days in advance will be impossible.
Admitting that we mainly tested with Dutch beta-testers, but the system should also be functional for the rest of the countries.

At the moment the system does not really account for car charging, other than that it looks at 28 day consumption history to forecast future consumption. It will be certainly be off in some cases. A way to schedule heavier loads is certainly on our todo list.

If your system does not function as you would expect, please provide the vrm id, so we can have a closer look at its decisions and explain them (which likely will happen after the weekend).

0 Likes 0 ·
g8n avatar image g8n Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Thank you for your quick reply. I am very aware that the battery charging and discharging as well as the battery itself causes a lot of costs. Therefore, it is unclear to me why the system delivers the battery power to the grid when it is switched on, although the compensation for this is extremely low, but at the same time the solar forecast for the next day is very poor and the energy purchase price is very high. If I switch the DESS on again 2 hours later, it suddenly starts charging the batteries with maximum power even though the price is 0.38€. It would be really important to know what criteria are used for the calculation. We in Germany have extremely high grid and transmission fees. At the same time, the compensation for feeding electricity into the grid is extremely low.

As far as I know, it is legally forbidden to feed electricity from the battery into the grid. Since this electricity could be charged from the grid beforehand and you cannot ensure yourself that it comes from 100% renewable energies. However, the feed-in tariff is only permissible for 100 % renewable energies or, in the case of private households, even linked to the solar electricity. I know that no one can control that.

From my point of view, at the current prices in Germany, it doesn't make sense to charge electricity from the grid into the battery and then use it yourself later of feed in again. It would make more sense to use the existing battery power at times when the price is high and to draw the required power from the grid when the price is lower. If you add the charging losses, it almost never makes sense in Germany to store AC electricity in the battery and then feed it into the grid at a later date - even self-use does not make sense at current prices. In Germany, you currently only get 0.067€/1kWh for solar feed-in, and in Brandenburg, for example, you have to pay (p+0.18506)*1.19 / 1kWh "Tibber" to buy the electricity. What I would also like to understand is to what extent a distinction is made between AC solar and DC solar in the calculation. Two of the test VRM ID' are d41243b50a41 or c0619ab372c9 .I have attached picture i hope that helps. I will be at the webinar on Tuesday.


Have a nice WE!

2 Likes 2 ·
g8n avatar image g8n g8n commented ·

It would be really important to understand how the system makes its decisions. Today I tested the Dynamic ESS again via the VRM Portal. Of course, I switched off the entire flow in Node-Red for Dynamic ESS beforehand. The system charged the battery with maximum solar power at the same time as it drew the entire AC load from the grid. When clouds came, the system fed the battery power into the grid with maximum loads. 20min later the system used expensive grid power to charge the battery again.bildschirmfoto-2023-09-24-um-191222.png

If I see it correctly, the system calculated so correctly that I lost money.


0 Likes 0 ·
dirk-s avatar image dirk-s commented ·

Nice function. I just set up for my installation.

Could you explain more the value "Dynamic ESS SOC"? I don't understand why the system charge from grid if the current SOC is below the "Dynamic ESS SOC" and the grid prices are very high. E.g. current SOC is 45% and "Dynamic ESS SOC" is set to 50%. Minimum SOC is set to 10%

The description says: "The Minimum Dynamic ESS SOC determines when Dynamic ESS will stop selling to the grid to leave enough energy for self-consumption."

Why it charges from grid and does not keep it for my self consumption during the night from battery. The forecast for tomorrow shows enough Solar energy. I switched of selling to the grid.

It's a simple ESS installation (Multiplus II 5000 GX; 6* Pylontech US3000C; 8,22kWp SolarEdge PV AC connected). Forecast Solar and consumption will be shown. System is running for two years now and also location was set before months.

Thanks in advance.

0 Likes 0 ·
dirk-s avatar image dirk-s dirk-s commented ·

I just see, that the charging from grid has nothing to do with the "Dynamic ESS SOC". Nevertheless I don't understand why it charges from the Grid when there is enough forecast for Solar and the prices are high. But I will observe.

1 Like 1 ·
Torstein Kvamme avatar image Torstein Kvamme commented ·

This is asweome news. thank you for implementing this.

If i could have a wishlist on how it works.. i guess this is not that difficult to implement, and all of the ESS users might find it useful.
Here is some background.

Dynamic price + all cost for buying ends up in a total
Our plan located is SE4 Sweden. 50kWh battery

(Spot + 0,0421 € + energy tax 0,0413 € + transfer tax 0,0522) * tax 1,25 =0,1695 if spot is zero

Spot + 0,084

This means that i need minumum 0,1695 in dif between buy and sell before i want to sell anything.
We also shoud ad the cost of batteries. and even a margin possibility. so i manually can set the margin i want before the system starts buying and selling
I have run this manually during this year.

Here is a pic of the price. Sorryits in SEK but ill convert it.
at 1800 its about 0,26131 € then at 1900 its 0,05006
Lets put this into the formula

selling 1800
P=0,26131 + 0,084 = 0,34531

Buying 1900
(P=0,05006 + 0.0421 + Energy tax 0,0413 + tansfer tax 0,0522) + tax = 0,232075
Margin is 0,113235 without the battery cost.

To continue on this. as you made the forecast on solar and also consumption its possible to calculate if the system shouls buy os sell depending on the margin i have set.

Sorry if this was to long and not understandable. but let me know if you got questions.
Also if you need help with the Swedish SE4 and EON im happy to help out in anyway.


0 Likes 0 ·
1695446461488.jpeg (223.4 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ Torstein Kvamme commented ·

Hej Torstein. As far as I can see, your description matches the current implementation of Dynamic ESS quite nicely. Or I am overlooking something.

0 Likes 0 ·
Torstein Kvamme avatar image Torstein Kvamme Dirk-Jan Faber (Victron Energy) ♦♦ commented ·


maybe or im missing something.

i want to be able to set at what margin do i want to sell.

if the margin between buy and sell is 120öre (about 0,010Euro) or less.+ my picked margin let say i want a margin on atleast 0,010 euro then dont sell then there needs tobe 0,020euro in diff before it starts selling

i guess i only miss a margin parameter to put in the the calculation.

sure i can put that margin into the buy price. but then the calulation on how much i save in euro will be calculated wrong.

my excample above is

(Spot + 0,0421
€ + energy tax 0,0413 € + transfer tax 0,0522) * tax 1,25 =0,1695 if spot is zero

then ill just put in +0,010 additionally if a i want a extra margin

(Spot + 0,0421 € + energy tax 0,0413 € + transfer tax 0,0522+ 0,010) * tax 1,25 =0,1795 if spot is zero

Spot + 0,084 €

I have rescheduled my plans for today and i will attend to the webinar.

Looking forward to it.

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ Torstein Kvamme commented ·

Ah, that clarifies it a bit. At the moment the Node-RED implementation will be most flexible for now. You get all of the information of the API back-end and can adjust the scheduling logic yourself.
See (if you haven't already)

-1 Like -1 ·
ojack avatar image ojack commented ·

Thanks for starting this nice feature. I hope it will be developed the way I can use it especially for the winter.

Can you please explain some settings?

- "Can you sell energy back to the grid?" - You mean only from battery to grid? Or solar excess too? I want to export solar excess (AC and DC) but never from battery to grid.

- "Maximum import power" - Is this the sum of all possible loads + charger power of the multis?

- "Maximum discharge power" - This should be the max. power the Multis can take from the battery, correct?

- "Maximum charging power" - Is this the sum of the charger power from the Multis + all Mppts?

As other users said, I only want the system to buy from grid if solar forecast for the next day is lower than consumption forecast and the battery cannot deliver the difference. Then buying only at the lowest price. In summer solar is sufficiant for all loads 24/7 since May so it should never buy from grid.

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ ojack commented ·

| - "Can you sell energy back to the grid?" - You mean only from
| battery to grid? Or solar excess too? I want to export solar
| excess (AC and DC) but never from battery to grid.

This means both from battery and solar to the grid. The current system looks at costs on making its decisions. If discharging the battery to the grid makes economical sense, it will do that.

For example, if you have prices like today in the Netherlands, where the energy price is low during the day and peaking in the early evening. prices-today.pngThe system will not sell the solar energy when available and the prices are low, but store it for a while in the batteries and start selling when the prices are high.

The powers that need to be filled out are the "weakest links" in the system, so the lowest of grid power / multi power.

| As other users said, I only want the system to buy from grid
| if solar forecast for the next day is lower than consumption
| forecast and the battery cannot deliver the difference. Then
| buying only at the lowest price. In summer solar is sufficiant
| for all loads 24/7 since May so it should never buy from grid.

This is not the way the system is currently operating and definitely a good idea. It was not on our radar when we first designed it, but I'll make sure it is added to the todo list as a future option.

0 Likes 0 ·
prices-today.png (118.7 KiB)
ojack avatar image ojack Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Thanks for your answer,

For Germany it will be neccessary to ad an option to separate feed in from battery vs. feed in from solar. Because of strange pricing regulations systems in germany are not allowed to feed in energy from battery which was taken from grid before. Providers even want so see a certificate which garants this. Feed in solar excess is ok.

And because of very low prices for feed in in general in germany its (nearly) never a good deal to feed in from battery even if its solar energy. The feed in price in germany is at constant very low 7-8ct/kwh all time.

In my system I have a special situation which may have other users in germany too. I have different feed in prices for different parts of my system which are launched in different years. The old part has 39ct/kWh and the new part (which includes the battery) only 7ct/kWh feed in price. The official measurement for this is realized with a cascade of two meters. Because of this its optimal to sell the power of the old solar system (measured with a separate ET340 at ACin) compleatly to grid as long as the rest of the system (AC and DC solar) can supply my house and charge the battery alone. At the moment i do this with a little nodeRed flow which only writes "setgridpoint = actualPower of PV_AC_old *-1 "

Maybe this could be a point at your "b" priority todo list.

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ ojack commented ·

I've got a question about that German regulation. Does this need to be calculated on a daily basis? Or is it also allowed to feed back in yesterday's solar yields today?

Probably for us setting it on a daily basis would be most easy to implement.

0 Likes 0 ·
daniel-feist avatar image daniel-feist Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

I like the theory, but in practice, it doesn't work like this for me.

I have a 3-hour peak window for 4-7 pm:
- From 4-5 pm and 5-6 pm if discharged fast (much faster than needed to export the required amount in that hour) to reach a calculated target SoC.. During this time loads were covered by PV generation.
- From 6-7pm it is already at the target SoC of 52% so it doesn't export. The PV generation no longer meets the demand and it is importing from the grid during the most expensive time of the day!!

I assume there is some amount of learning required, but I'd expect it to be somewhat more conservative while learning if that is the case. Exporting from the battery at 200A, just to reimport again within the same tariff window 1hr later doesn't make sense as i) lose 11p/kWh ii) uses the battery unnecessarily.

I will leave it on and continue to monitor it, but if it keeps importing when the tariff is highest then I'll need to turn it off.

BTW. Any way to change the currency to UK Pounds £?

0 Likes 0 ·
daniel-feist avatar image daniel-feist daniel-feist commented ·

I realized what was going on. I'd configured a 560kWh battery by mistake (it's 560Ah). The algorithm should have still coped with this, but seems it didn't.

Anyway, with that resolved the schedule looks much closer to what I would expect, but there are still some things I don't understand, especially around how the target SoC is calculated and used. Couple of cases:

1. Eager Charging from PV

Currently, my battery target SoC is at 77% which means excess PV is being exported. However, given I have a very good export rate of 16-19hrs today (31p) it should fill the battery from solar before 4 pm given the current export is only 19p. If I look carefully at the "energy" diagram that in fact the plan, it seems, is to do this with 23% being added to the battery between 12 pm and 4 pm in a nice consistent way which is fantastic. The only issue is, what happens if the weather changes and the forecast solar doesn't happen? Isn't it best to charge eagerly when there is excess PV in this scenario?

2. Grid Charge/Discharge Rate & Schedule

The current algorithm appears to be fairly short-sighted in the sense that it will charge from the grid (for example during 3hr overnight off-peak) as fast as the battery will allow, even if this means running the battery at max discharge rate for 1hr and then not charging for the next two hours. The same happens when discharging during high export rate times. Ideally the algorithm would be able to spread the charge/discharge over the full tariff window to stress the battery less. For now, I have deliberately reduced the max charge/discharge rates in the dynamic ESS configuration to 9.5kW (battery capacity / 3hr) to work around this.

3. Margin Calculation

Today's schedule has been running from the grid (and not the battery) in the evening. This seems wrong as the whole point of having a battery is to load-shift from overnight tariff or PV to the evening. But, think it may make sense to empty the battery at a 31p export rate and then import at 30p in the evening, rather than save energy in the battery. My concern here is that it is doing this based on just a 1p margin! Technically I suppose that makes sense, but that assumes the battery cost is the same and it won't be if the actual evening usage is less than the amount discharged during peak.

0 Likes 0 ·
daniel-feist avatar image daniel-feist daniel-feist commented ·

So, this is what happens later in the day due to i) not eagerly charging using PV and ii) seemingly focusing on target SoC and not configuring any grid set-point.

The sun went behind the clouds and the cleaner came so energy usage went up. This means it's now re-importing what it exported in the morning (instead of charging the battery) in order to meet the target SoC. This results in an 11p/kWh loss.


0 Likes 0 ·
1695815181349.png (82.9 KiB)
frederikbove avatar image frederikbove commented ·

currently I don’t see the option to activate the dynamic Ess in my portal

0 Likes 0 ·
Kaj Lehtinen avatar image Kaj Lehtinen frederikbove commented ·

Are you on the right URL ? (

0 Likes 0 ·
Kaj Lehtinen avatar image Kaj Lehtinen commented ·

Tried the VRM version over night last night & switched back this morning to node-red due to that I missed the energy graph, I get the feeling that it has a problem holding grid setpoint = 0W, both VRM and Node-red version - keeps on buying 3-400 W instead of holding 0W - although my feeling is that I saw more of that in the VRM version than the current 0.1.6 Node red version.

Also with the Venus OS 3.20~4 I cant really say that I've seen it sell anything to the grid. the system has sold when the grid feedin kicked in due to full batteries - but not when Node-red says it should sell.

Another feeling I have is that the current beta version of DESS, doesnt cope well with sudden rises in consumption that goes above the forecast - that results in grid draw.

This can be illustrated last night, SoC at approx 75%, DESS idles the battery and consumes from grid at 1 & 2 am, same again 5 am.




0 Likes 0 ·
1695503948170.png (28.3 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ Kaj Lehtinen commented ·
From a technical perspective there is not difference between the current Node-RED and the beta VRM implementation. The energy graph is going to be added to beta VRM soon.

Considering the setpoint zero, you could be suffering from an issue that causes the battery not to operate completely stable. A fix for that is to be included in the next candidate release.

1 Like 1 ·
jakobgode avatar image jakobgode Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Maybe its possible to take the grid setpoint from gx device if dynamic ess want the setpoint = 0.
Our setpoint is the whole time on -70w beacuse then we kill energy consumption from grid.

0 Likes 0 ·
Show more comments



nickdb contributed to this article dfaber contributed to this article mvader contributed to this article