article

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: https://youtu.be/YU9jXyfM-eI

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
188 comments
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 ·

Hi,

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 https://octopus.energy/smart/agile/ 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 gbbvictronweb.gbbsoft.pl. It supports UK tariffs.

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

You can also try https://github.com/christian1980nrw/Spotmarket-Switcher 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 ·
Show more comments
Show more comments
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 https://github.com/victronenergy/dynamic-ess).

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 ·

Hi,

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.


bildschirmfoto-2023-09-22-um-224451.jpg


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.

bildschirmfoto-2023-09-24-um-192946.png

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

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

Selling
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.


1695446461488.jpeg





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 ·

Hi

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

Buying
(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

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

Selling
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 https://github.com/victronenergy/dynamic-ess (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 ·
Show more comments
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 ? (https://betavrm.victronenergy.com/)

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.

1695503948170.png

1695503976246.png

/Kaj

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 ·
sieade245 avatar image sieade245 commented ·

One small piece of feedback. The DESS setup page in the beta VRM portal only seem to allow me setup times using hours, not minutes. So for example I can't set it up to have fixed pricing between 23:30 and 05:30, I have to round up/ down to 00:00 and 05:00.

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

Good point. In the Netherland we are only used to energy prices changing hourly. In which country are you located and does it change there per minute? Or per half hour/quarter?

I created an issue for this: https://github.com/victronenergy/dynamic-ess/issues/84. Feel free to add the information there.

1 Like 1 ·
sieade245 avatar image sieade245 Dirk-Jan Faber (Victron Energy) ♦♦ commented ·
I'm in UK. I believe that dynamic pricing is hourly as with the Netherlands but I'm on a Fixed two rate tariff from Octopus with off peak between 23:30 and 05:30. They also have other similar tariffs such as 00:30 - 04:30.
0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ sieade245 commented ·

Thanks! So a granularity of half an hour would already help you. I'll forward that request.

4 Likes 4 ·
Show more comments
elko avatar image elko commented ·

Hello,

img-5389.jpegcan you prevent it from feeding ~200W into the grid now? The PV production is also at 0W

Edit:

and why is nothing more available from storage now?



0 Likes 0 ·
img-5389.jpeg (270.9 KiB)
img-5392.jpeg (265.0 KiB)
mrstackit avatar image mrstackit elko commented ·

Is the first screenshot perhaps the same bug that I reported in GitHub Node Red?

https://github.com/victronenergy/dynamic-ess/issues/78

0 Likes 0 ·
stroller avatar image stroller commented ·

The provision of Dynamic ESS by Victron is a great development. At this time, I am only aware of Octopus Energy UK that do “day ahead pricing” tarrif's. It would appear that the vast amount of people who are 'Grid Connected' and have a Battery ESS are using one of the Octopus Energy Tarrif's, and I would speculate that the vast majority of those people are using the 'AgileOctopus' Tarrif which has dynamic pricing based on half-hourly wholesale energy prices.

Users can get their 24 hours ahead half-hourly pricing each day via the Octopus Energy REST API that they provide. See https://developer.octopus.energy/docs/api/ 

To get your prices each day, which are released at 16:00 Local UK time, you just need to have your Agile tarrif Product Code, your private API Key, Your electricity meterpoint's MPAN: number (13 digits), and your electricity meter's serial number:

For Victron UK Users, can the Dynamic ESS set the the ESS Setup page Battery Costs to £ sterling/kWh and then on the Buy Prices page, if UK is selected for Country and the Procvider is set to Octopus Energy, allow for 4 data boxes for the user to input the above 4 items of information, Product Code, API Key, MPAN & Meter Serial which would then provide all the information that is required to be set into the REST Call to the API.

0 Likes 0 ·
Henrik Känngård avatar image Henrik Känngård commented ·

Great feature, much appreciated all the work that has been made to implement this!
I have a few thoughts and questions, which perhaps already has been answered, please point me in the right direction if this is so:

  • I am trying to figure out the price of battery usage, do someone have a good way of calculating this?
  • In Sweden where my system is installed we have the possibility to not only have a dynamic price for buying/selling electricity, but also for network usage. In my case we have lower price during nights and weekends than on daytime during the winter months (November to March). It would be great to be able to have this in consideration when developing this feature! :)
0 Likes 0 ·
stroller avatar image stroller Henrik Känngård commented ·

Henrik, take a look at Step 2: Battery of this link. https://www.victronenergy.com/live/drafts:dynamic_ess

  • Battery costs - Battery costs indicate how expensive it is to use it for charging and discharging, expressed in €/kWh. A typical calculation for this is: costs for buying the battery in € / (charging cycles * battery capacity in kWh).

If you don't care about the overal lifetime costs of the battery, then as suggested in the link, just put 0.01 €/kWh in there.

You say that you have the possibility to not only have a dynamic price for buying/selling electricity, but also for network usage. What do you mean by 'network usage'?

You then say, you have lower price during nights and weekends than on daytime during the winter months (November to March). Are these lower prices the same price per kWh all the time or do they rise or fall over those periods of time?


0 Likes 0 ·
Henrik Känngård avatar image Henrik Känngård stroller commented ·

Thank you for your reply. I'll use the info for the battery cost!
Regarding the network fee, the correct wording probably is grid fee, In Sweden we have the possibility to buy and sell electricity to a variety of companies, but for the grid we are locked to one company depending on region. And the price is fixed, but different depending on day of week and time during winter like workday between 06:00 and 22:00 the price is €0,04/kWh and during weekends and nights it's €0,01/kWh. Meaning it is not worth buyng energy during daytime unless the difference between the buy and sell price is higher than €0,03/kWh. This is not relevant during the summermonths though :)

1 Like 1 ·
Kaj Lehtinen avatar image Kaj Lehtinen commented ·

Hi,

Dont know if its reported already, or if its a gui glitch or something more fundamental but if P is negative and the sale formula is (P-0.05) the price graph in VRM becomes positive. See last night in picture.


screenshot-20230926-141707-chrome.jpg

Please also notice the forecasted draw from grid at the most expensive hour today.

/kaj

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ Kaj Lehtinen commented ·
Thanks for reporting. We'll take a look at it.
0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Alright. It looks like you changed the sell price at the moment of the point of the red arrow, so around 7.30. The graph shows how it was before that moment and how it is in the future. I don't see anything directly wrong with that, but I may be overlooking something.


1695824704020.png

Then about:
| Please also notice the forecasted draw from grid at the most expensive hour today.

The grid/battery usage graph is misleading and we are working on getting that fixed. The plan is to feed back into the grid then. Check the energy graph for a more clear view while we improve the usage graph.

0 Likes 0 ·
1695824704020.png (106.1 KiB)
Kaj Lehtinen avatar image Kaj Lehtinen Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Hi,

Both yes and no, at around 7.30 the morning in question I switched from Node-red version to VRM version of DESS and since I had been testing the VRM version last weekend I might have needed to adjust the sell price formula to that of what I had in Node-red from before

It might be oneoff - I saw that the price tomorrow night will once again become negative for me so i'll check at 23-00 tomorrow, and get back with a update.

Good, I've also concluded that the grid usage graph currently treats most/all as positive (consumption) and not negative (sale) even though, as you say, the new energy graph shows correctly.

One question/feedback, the what's the reasoning to have the same/identical graph on the top of both schedule and Energy tabs?

/Kaj

0 Likes 0 ·
joris-trooster avatar image joris-trooster commented ·

The manual talks about "The more advanced use is to set the Minimum Dynamic ESS SOC separately from the Minimum SOC. " But I do not have this option in betavrm. Only a setting for the minium state of charge. I cannot set the ESS SOC separately.
Should I enable something somewhere to have this option?

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

At the moment we disabled that "more advanced" use for all, so I'll update the manual. It is likely to come back, but after we had some more internal discussion on it.

0 Likes 0 ·
Torstein Kvamme avatar image Torstein Kvamme commented ·

img-4208.png

Why does it sell now when price is low?

It shoult charge batteries so i can sell later today when prices are much higher


0 Likes 0 ·
img-4208.png (516.6 KiB)
img-4209.png (544.5 KiB)
spazpeker avatar image spazpeker commented ·

Setup my system with a 4.4kw export limit however the system is exporting over 7kw

0 Likes 0 ·
img-0175.jpeg (670.9 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ spazpeker commented ·
Can you provide the vrm id so we can take a closer look at what is causing that?
0 Likes 0 ·
spazpeker avatar image spazpeker Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

ID is b827ebc51513

Today seemed to cost more with dynamic ESS


0 Likes 0 ·
img-0176.png (158.0 KiB)
daniel-feist avatar image daniel-feist spazpeker commented ·

Maybe Dynamic ESS should be even more dynamic and turn itself off when the sums show it is going to lose you money :-)

Mine is also generally worse than ESS too, but not as bad as €5+.

0 Likes 0 ·
Show more comments
daniel-feist avatar image daniel-feist commented ·
Another feature request:


Ability to see "cost/earnings" and "energy" graphs for previous days (schedule graph is less important, but would still be good to have). Ideally, this would be available via a widget too and have full historical data.

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ daniel-feist commented ·
This is already being worked on.
1 Like 1 ·
meyo084 avatar image meyo084 commented ·

Hi, thanks for the great work! Somehow i cant find the dynamic ess menu in my cerbo.. already on 3.10.. image type large.. any ideas? Thankyou

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

You are looking on the beta vrm? If so and you still can't find it, please provide your vrm id so we can take a look at what is going on.

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

Hi, no i mean the “dynamic ess” menu in the remote console on the cerbo gx..

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ meyo084 commented ·
It should be under ESS and then the last entry.
0 Likes 0 ·
Show more comments
yvos avatar image yvos commented ·

Hi Dirk-Jan,

Thanks for the webinair yesterday, super stoked on this release. After the first day of running DESS I was wondering if it makes sense?

There was 20kw solar and 15kw of direct use, so there was a 5kw surplus on power more or less.

I would have thougt that the system just injected this 5kw solar at the highest price level. Than I would have earned 5*0,46= €2,3. Instead the system bought 42kw and sold 48kw which led to €2,24 earnings. This seems to be less than to just inject the surplus of power. I also have to pay more transport costs for the power to go from and to the battery. And last but not least the battery was almost charged and discharged twice in one day this will shorten the life span of the battery I think. moving arround so much power seems somehow useless and keep filling the pockets of the energy company's

I hope you can give your view on this. I have also attached some screen shots.

schermafbeelding-2023-09-27-om-225424.png

schermafbeelding-2023-09-27-om-225406.png

One other thing to think about is what about the daily costs of having a electricity connection. This can be calculated to the hour so you know what the grid connection costs per day. If we want to know if we can be at zero costs I think we have to take this into account. As an end consumer it is nice to see what the total energy costs per day are for your household.

I will keep testing and If I have other comments I will post it here, thanks again and looking forward to future finetuning.

System: 20x500w solar, MPPT 450/100, 3 phase Multiplus II 5000/70, 6x4,8kw Pylontech

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

Can you provide the vrm id so we can analyze the reasoning of the system? My first hunch is that you may have something wrong in the formulas, but I'd like to check that.

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

id: 307125

0 Likes 0 ·
thekwchallenge avatar image thekwchallenge commented ·

1695890778172.png

Is it just me or are all the DESS graphs not working today? I've tried clearing my cache, switching DESS on and off again, even changing the buy/sell calculations, nothing fixes it?

0 Likes 0 ·
1695890778172.png (21.6 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ thekwchallenge commented ·
It should be working. What browser are you using?
0 Likes 0 ·
thekwchallenge avatar image thekwchallenge Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Chrome. I rebooted my Cerbo GX and that resolved it.

0 Likes 0 ·
john245 avatar image john245 commented ·

System running for two (2) days but still no solar forecast. When will this become available?


1695891361925.png

0 Likes 0 ·
1695891361925.png (19.0 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ john245 commented ·

Have you set the location of the device in VRM?

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

@Dirk-Jan Faber

Location is set, see:

1695907852363.png

0 Likes 0 ·
1695907852363.png (202.7 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ john245 commented ·

I just checked on your system and the forecast started working 2 minutes ago. All should be functional now.

0 Likes 0 ·
Show more comments
daniel-feist avatar image daniel-feist commented ·

@Dirk-Jan Faber I already posted a few findings in one of the threads, but now I've monitored Dynamic ESS functioning for a longer period of time I want to summarize my findings and suggestions:

Bulk Charge/Discharge

When bulk charging/discharging during a cheap tariff period, charging/discharging should ideally be spread out across the full-time period, rather than hammering the battery to achieve the target SoC ASAP.

Algorithm & Target SoC

It seems the algorithm is primarily focused on the calculation of target SoC levels using forecast solar, consumption and battery/tariff details. This algorithm gets all the basics right, but doesn't deal with the dynamic nature of solar/consumption, specifically:
- Clouds which lower actual PV kW.
- Lower than forecast consumption which increases excess PV.
- Higher than forecast consumption.
- Short periods of high consumption that are higher than the hourly average (boiling kettle, cutting lawn, vacuuming).

Because it doesn't deal with these more dynamic elements the use of Dynamic ESS can result in both:
- export to the grid when export tariff is low and the battery isn't full
- import from the grid when the tariff is high and the battery is charged.
(neither of these things happens with standard ESS!)

I see two potential solutions to enhance the algorithm:
1) Calculate the target SoC more frequently to account for reduced solar and real consumption. This would significantly minimize importing from the grid to achieve an artificially high target SoC which was calculated up to 1hr ago. It would also avoid exporting to the grid when the target SoC is lower than it could have been (because the last hour's current hours consumption was lower than forecast).

2) Combine target SoC with a "grid-setpoint" or "grid-setpoint limit". This will ensure that if forecasts aren't accurate then undesired import/export will be avoided. This approach would also deal very well with short-term loads, in the same way that ESS does. Depending on the time period (and tariff), you would either need to use target SoC, grid set-point limit or both. The details need a bit more thought though.

For the best solution, it may require using, or combining, both enhancements.

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

Regarding your first point. The system is taking an hour to reach the target SOC, so not ASAP. But IIRC you are on a fixed tariff where longer periods of a certain prices is more usual.
We are checking if it is indeed more efficient to spread that over the longer period, but as the optimal efficiency of inverters is typically more in the upper region of the device, I doubt that it will make much difference.

Thanks for the info for the second point. We are working on improving the scheduling. Do keep in mind that there is a reason that we've released to beta first. It is so we can tweak the system before going really life.

Btw no need to tag me in your posts. I do read all of the comments without that. Sometimes responding takes a bit longer than other times.

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

> The system is taking an hour to reach the target SOC, so not ASAP. But IIRC you are on a fixed tariff where longer periods of certain prices are more usual.

yes! So the issue here is how the target SoC is determined for each 1hr slot during the 3hr cheap tariff, not the rate at which it is charging/discharging happens to reach the SoC.

> Thanks for the info for the second point. We are working on improving the scheduling. Do keep in mind that there is a reason that we've released to beta first. It is so we can tweak the system before going really life.

Of course! I'm not expecting it to be perfect yet, and this is the reason why I took the time to provide a lot of feedback and thoughts to help ensure that the final product is the best possible :-) Do you agree that the final algorithm needs to i) update the target SoC more regularly ii) combine with elements of standard ESS in terms of setting/limiting grid setpoint to prevent unwanted import/export?


0 Likes 0 ·
Show more comments
flajzi avatar image flajzi commented ·

Would be great to have more dynamic buy prices (calculations) per day.

I have different price calculation between 09:00-10:00 + 12:00-13:00 and the rest 22 hours (10:00-12:00 + 13:00-09:00).

0 Likes 0 ·
kent2ben avatar image kent2ben flajzi commented ·

In Denmark we have different tarifs during the day as well.

So it would be a nice feature. Any news on this ?

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

Can you explain a little more on that? Do you mean that you have different dynamic prices during different hours?

Or do you have fixed pricing? With different (but fixed) prices during parts of the day/evening/week/weekend?

The last one can already be entered into the system.

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

Hi
I have dynamic prices and that works fine.

In Denmark everyone have dynamic transport charges. (Mine are as below)
00:00 - 05:59 = 0.0147 €/kwh
6:00 - 16:59 = 0.0440 €/kwh
17:00 - 20:59 = 0.1307 €/kwh
21:00 - 23:59 = 0.0440 €/kwh

I think the logic would be like what I see under "Fixed" prices.
1696240759129.png
It would be great if that kind of dynamic charges could be part of the solution - as you can see there big difference during the day.


So my formula would look like: p+"transport charges"
Where p is the dynamic price as implemented today.

0 Likes 0 ·
1696240759129.png (24.7 KiB)
Show more comments
Show more comments
Magnus Pernemark avatar image Magnus Pernemark commented ·

Long post - questings in bold at the end

I have just tried this two days. Cannot really say it is working at all.
With the excaption of 4 hours the last 48 hours, it has not been favorable to sell in Sweden SE3.
Right now the spot price is zero plus 0.0086, and buyprice is (p*1.25)+0.056

And it will be so pretty much all night and the next day, spot price is pretty much the same +/- 0.005 ct/kWh

In other words, it is most favorable to charge the batteries if solar is present, and it is most favorable to use the energy from the batteries during the night.

Still it is selling if I put it in auto mode. Not very much, but it is trying to reduce the SoC from 58% to 54% buy selling off. I know I will not last all night or just bairly make it to 15% SoC until sun up, and that is without selling off.
So for it to force sell at zero money then have to buy during the night makes no sence.

This morning the 28th, there was a few hours with spot price at 0.04€/kWh, still lower than what the average buy price would be entire day. But it chose not to chanrge the batteries.
So it opted to sell solar power for 0.04€/kWh and then have to buy later at minimu 0.06€/kWh. It had even estimated that solar for the day would yeild less then 30kWh, so with average consumption it would not be enough to fill the batteries anyway - but even more incitament to charge what ever it could, instead of selling cheaper then it buys.

I understand it is more complicated than if price more than then do else do something else, but still - the first basic calculation would be. If buy price is more then sell price, charge batteries with available solar. Of cource adding predictions to this makes it very complex.
I think most of us are used to - charge from solar as much as possible, and if any surplus - sell it - but still make it to morning without buying, because buying is often more expencive.

Grid Usage - What is that?

And this got me thinking. How do you calculate grid usage. I looked at the graph of predicted usage.I see in the graph "Grid usage" and "Battery usage". I have a grid tied inverter separate to victron system. I have no solar connected to victron. It says that I used "Grid usage" during the sunny day today. Kind of true, but in was not from power companies grid. It was from my solaredge system.

Is it calculating things wrong? Does it think I an buying frrom grid?
gridusage.png

Victron VRM data which is wrong - is that used?

I was also thinking - is Dymanic ESS using the real grid usage or the wrong data from vrm?
Take the 25th of September as an example
1695934606523.png

This day I sold 1.08kWh and bought 0.58kWh. But as you see in the picture above, victron says 9.6 resp. 8.8 which is totally wrong. Victron calculates each phase on it's own, but in most of Europe we use sum of all phases. I might have bought 8.8 and sold 9.6 seen from a phase perspective, but out of a billing and usage perspecitve I have sold and bought 1.08/0.58

0 Likes 0 ·
gridusage.png (34.2 KiB)
1695934606523.png (55.1 KiB)
victech-power avatar image victech-power commented ·

@Dirk-Jan Faber : I turned on the "buy" function yesterday instead of "auto" to store some extra kWh because I thought I could and I noticed following.
Once the batteries are 99%/100% full, while still in buy,.. the Solar Charger ramped down and it started pulling power from the Grid.

It should prefer solar before grid in this "buy" situation when battery is full.
You should never want to ramp down the Solar Charger in case of surplus.

Perhaps you want to turn back to AUTO automagically when 100% full.

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

Thanks for reporting. We'll investigate. It sounds a bit like the same issue described here, but it could be something else.

If we switch back to auto automatically once the battery is full, the system might start discharging directly to reach the new target SOC. Not all users want that, so we have to think of a way to please all of you.

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ victech-power commented ·
If you turn off dynamic ESS and set your ESS mode to "keep batteries charged". Is your system then also ignoring the PV and using the grid?

Underneath the hood the same system is used.

0 Likes 0 ·
hominidae avatar image hominidae commented ·

Dynamic ESS is not an option in the settings on my beta VRM account? How so?

1696063108325.png

0 Likes 0 ·
1696063108325.png (21.0 KiB)
hominidae avatar image hominidae hominidae commented ·

Ah...note to self: your GX device needs to be on Firmware Version 3.10 at least.

@Dirk-Jan Faber this prerequisite should go into the manual, shouldn't it?

0 Likes 0 ·
marceldb avatar image marceldb commented ·

I had set a scheduled charge from 10AM, but nothing happened, although the schedule shows active. Has the DESS schedule priority above the scheduled charge? Shouldn't it not be reversed, as it is not logic to turn off DESS first before scheduled charge will turn on.

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

The short answer is no, as this will interfere with the calculations of the system. If you want to use scheduled charging, then you need to either switch to normal ESS or get creative in Node-RED.

0 Likes 0 ·
andib avatar image andib commented ·

Hi, I read today about this very helpful dynamic ESS function, great! I tried to install but have a problem as this setting button for enabling dynamic ESS is not appearing in dashboard on upper right corner:

unbenannt2.jpg

The only interesting thing I am observing while clicking through the setup was this:

unbenannt.jpg

this seems to indicate that a communication error occurs... But I do not have a clue if this is the cause for not getting the above mentioned button. If I finish setup there is always a confirmation pop up "saved".

Has anybody an idea what I can do?

Firmware was updated to latest release candidate V3.20~7. VRM-ID is b827eb5fdea4

0 Likes 0 ·
unbenannt2.jpg (101.1 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ andib commented ·

That is unexpected behaviour. We are looking into the cause.

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

Got it clarified. It is because you don't have "Two-way communication enabled" in the menu. This means that VRM cannot contact your device to set the target SOC and such.
I'll add it to the manual for other users.

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

Thanks for clarification! I will try to enable.

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

Does the algorithm take into account approximately 90% charge & discharge efficiency?

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ daniel-feist commented ·
Not right now. But it is on our todo list.
0 Likes 0 ·
damandan avatar image damandan commented ·

Hi all, I have been using this feature as a Node-Red flow for about a month now and switched to the native one last week.


This has worked flawlessly up until yesterday.

Yesterday all of a sudden the Costs and Earnings page show '-' as earnings values and the Energy page also didn't load the bottom graph for most of the day. Yesterday, late in the evening the graphs and earnings info were available again, but now they are gone again.


Any clue on what is happening and how to get it to work again?

1696155026738.png

1696154998297.png

My VRM portal ID is c0619ab33d1e.

0 Likes 0 ·
1696154998297.png (100.1 KiB)
1696155026738.png (73.2 KiB)
damandan avatar image damandan damandan commented ·

Update: The same thing that I observed yesterday happened today as well. It's now early in the evening and the dashboard behaves as expected. And an additional little worry is the fact that, had I used the normal ESS, I would have had negative earnings (so costs?) of 0,94 Euro, but with Dynamic ESS, my electricity costs are 2,93 Euro? That kinda defeats the purpose of DESS, doesn't it? Or is the system already looking at the prices for tomorrow, where I will be getting 0.47Eur/KWh at 19:00 - 20:00?

1696177916295.png

1696177946236.png


0 Likes 0 ·
1696177916295.png (101.4 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ damandan commented ·

We are having troubles showing the correct earnings and costs. That is why we (temporary) removed the summary today. Showing the wrong values is worse than showing nothing at all.

2 Likes 2 ·
josleurs avatar image josleurs commented ·

hi Dirk-Jan,


great wrok on the VRM version.


after i use the Nod-red version i tried out the vrm version: i fond something odd:

20231001-te-veel-terug-leveren01.jpg

Some time the system go over my 9kW Max feed back:

20231001-te-veel-terug-leveren02.jpg

I cannot find out what i did wrong in my setting or system. can you have a look?


my vrm ID is: 138656


Thanks for your replay.

Jos

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

This looks indeed not correct. Do you recall if this was happening over a longer period or just a few seconds? (In which case the system might still be adjusting).

0 Likes 0 ·
rrr avatar image rrr Dirk-Jan Faber (Victron Energy) ♦♦ commented ·
Hi, i have the same problem, exceeds the network limit.

Max feed-in is in CERBO set 9800W and max export limit in DESS 9kW
As you can see the batteries are not charging.. shouldn't the excess energy go to the batteries (the first foto is DESS-on and second DESS-off)?

Vrm id: 48e7da88fa1dscreen-shot-2023-10-10-at-111559.pngscreen-shot-2023-10-10-at-111734.png
0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ rrr commented ·

Looked further into it and clarified the documentation on this (also for @JosLeurs). It boils down to that the power settings during the setup are capabilities, not limits for the system.

Also check https://www.victronenergy.com/live/drafts:dynamic_ess#qwhy_does_the_system_exceed_the_configured_power

0 Likes 0 ·
Show more comments
graham-willsher avatar image graham-willsher commented ·

Hi,

Having looked at this sort of thnig in the past I know that forecasting and predictive usage of Electricity is very hard to do. Congratulation to you for starting on it. Add into the mix the multitude of different Electricirty tariffs and regulation across the Countries that you operate in this is no mean feat. Well Done :)

Just started working with the Dynamic ESS and have a couple of questions regarding it.

I am based in the UK and use the Octopus Flux tariff like a number of other users on here, so can import cheaper electricity from 02:00- 05:00, and can export electricity at a premium from 16:00- 19:00 daily.

Originally my Multiplus II GX was setup to manually charge the batteries between 02:00 and 05:00 (set within the Multiplus), then use all excess solar produced during the day to top up my batteries (total of 15Kw) before selling any excess to the grid. I would then force discharge my batteries (using Node red) from 16:00 -19:00 (or until I was down to 40% SOC to leave me enough battery power for the rest of the day round to 02:00 the next day) and we start the cycle again.

My questions are two fold:

Do I need to stop the multiplus charging my batteries (will the Dynamic ESS take this over)?

Do I need to stop my node Red code to force discharge of the batteries (will Dynamic ESS take this over as the rate I get paid from exporting between 16:00 - 19:00 is most financially efficient)?


Having watched what is happening (albeit only for 1 day), the Dynamic ESS sent excess solar to the grid when my batteries were not fully charged netting me 0.22 Euros/kWh. As described above I charge my batteries as much as possible during the day so that I can sell as much as possible in the premium export window, netting me 0.37 Euros/kWh. Am I missing something?

Minor issue, the key is displayed twice in the Dynamic Ess /Energy/Energy graph (picture attached)

victron-beta-key-displayed-twice-2023-10-01-163114.png


Any help that you can give me will be appreciated.

Thanks,

Graham.

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

I'm also using Flux and have had mixed results. The high-level scheduling makes sense but I observe that:

- The battery discharges from 5-8 a.m. to cover forecast consumption, but if consumption is lower than forecast the battery discharges back to the grid. (while the export rate is the same as you just imported it for, you lose 20% due to efficiencies)

- During the day, if the sun goes behind the clouds and the PV forecast isn't achieved, then it will import whatever is required from the grid to meet the target SoC rather than use the battery or adjust the target SoC down.

- During the day, if consumption is higher than forecast, the additional will be imported from the grid rather than using the battery, even if the battery is quite full.

- During the day, if instantaneous consumption is high, the additional will be imported from the grid rather than use the battery. The is no grid setpoint in use.

- For some reason (as I think I can also see in your schedule), it schedules the use of the grid for 7 pm-12 am consumption rather than battery. I'm not sure why, because discharging to 10% from 4-7 pm isn't any more beneficial.

I think for a tariff like Flux, nothing can beat what you already have in place currently. I do hope though that Dynamic ESS with improvements will come close and potentially do a better job (using solar/consumption forecasts), for now, it will export/import at all the wrong times unless both PV/Consumption are exactly as forecast.

Anyway, given we have EV, PV generation is now reduced and the heating season will start soon I'm moving back to Octopus Intelligent, which will work out significantly cheaper over the winter and may consider moving back to Flux around April depending on rates. Dynamic ESS won't work well with Intelligent because the cheap tariff is 23.30->05.30 and currently it only supports full hours so I'll stick to ESS with a scheduled charge overnight and potentially a scheduled discharge down to 10% at 11.00 pm

0 Likes 0 ·
graham-willsher avatar image graham-willsher daniel-feist commented ·
Hi @Daniel Feist ,


I will give it a few more days (and hopefully the later 3.11 firmware upgrade) to see if that makes any difference. It there is no imporvement I shall disable the Dynamic ESS and go back to me manually charging the batteries from the Grid via the Victron scheduling in the 02:00-05:00 window and a forced discharge from 16:00 - 19:00.

I will also have a look at Octopus Intellignet to see whether that can work for me.

Thanks,

Graham.

1 Like 1 ·
Show more comments
graham-willsher avatar image graham-willsher graham-willsher commented ·

Hi,

Just a minor note, it looks as if the double displaying of the key is only in the 'recorded' section of the graph not the 'Forecasted' section. Hopefully that wil point you in the direction of where the issue is.

Thanks,

Graham.

0 Likes 0 ·
victech-power avatar image victech-power commented ·

@Dirk-Jan Faber I have been testing the Victron algorithm both on Node Red and VRM BETA. I am finding truly odd decisions or ( non action ) by the algorithm and before I start posting all my experiences here, where can I find a flow diagram overview of the algorithm ??.

Currently I am pushing the buy and sell button myself as I simply see the algo forecasting more negative cost than the normal ESS would.
I see more complaining about that here.

For us its simply about the best financial program for our customers and I mostly see the algo not even use our 52.8kWh battery test site to be charged to the max or discharged when price is low. If my consumption is less ... I do not mind the battery being used to make some money.
However.. I do not experience that this is (one) the algorithms "goal".

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

I've added a "determining the target SOC" part to the manual. You can find it here.

The part of the graph showing the different earnings with and without Dynamic ESS is not clear enough right now.

1696235716972.png

You should compare the "Total" on the left with the number on the right. That is going to be changed.

0 Likes 0 ·
1696235716972.png (17.4 KiB)
daniel-feist avatar image daniel-feist Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

> We keep the battery stable and not the grid: in our internal testing keeping the battery usage stable (basically the same as the plan) has been a lot more cost-effective than otherwise, because of the battery costs that pile up.

This is really hard to believe, especially given that keeping the battery stable during times of less consumption than forecast results in:
i) more battery usage discharging to the grid to meet Soc
ii) buying from the grid and selling back again soon after at a potentially higher price and also losing 20% to efficiencies at the same time.
Also, with additional consumption (or less PV), if the energy in the battery costs €0.10 to buy overnight and the grid cost is €0.30 currently, how can it be more cost-effective to use the grid if the battery cost is €0.06 to charge and discharge?


> If the forecast does not match the reality, Dynamic ESS does keep the planned battery usage stable while punishing the forecast inaccuracies on the grid (selling the excess to grid, buy the additional need from the grid). This can be less ideal, but it is an issue of the forecasts being inaccurate, nothing that the Dynamic ESS decided.

Yes, it's a result of inaccurate forecasts, we agree. However, forecasts will never be accurate as both the clouds and consumption are dynamic. While DESS can't do a better job at high-level scheduling, it can do a lot better job at the "in-hour" algorithm and various people have proposed improvements to this. For example honzaxw.

ESS deals with dynamic PV/consumption, but not dynamic grid pricing.

Beta DESS deals with dynamic grid pricing but not dynamic PV/consumption.

What is required is something that deals with dynamic grid-pricing *and* dynamic PV/consumption by combining the two approaches; beta-DESS for the day scheduling and a target SoC + ESS gid setpoint limit for each hourly slot (based on if it is a buy, sell or hold hour).

If this was implemented then it would be almost impossible to have higher costs using dynamic ess vs. ess, as various people are seeing currently.


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

I like the idea of the combined approach of beta DESS and ESS. Personally, I aim for the same goal described by Magnus Pernemark - use as much PV as possible in-house, sell excess when it make the best sense, and buy from the grid only when PV is not sufficient (ideally for the lowest price possible) or when invertors are overloaded.

This could mean selling from PV even if SoC<100% which is not possible with the current ESS. E.g. selling not consumed energy in the sunny morning instead of charging the battery and postponing the battery charging for noon.

In my case, I do not aim for the energy price arbitrage, the spread between sell and buy is so high (the transfer cost of inbound energy is high), that it does not make much sense with the current price volatility during the day.

But maybe I am missing the point and what I just described is the main goal of the original ESS. The DESS primary objective might be different.

In any case, it would be interesting to share more details to the quote: "We keep the battery stable and not the grid: in our internal testing keeping the battery usage stable (basically the same as the plan) has been a lot more cost-effective than otherwise, because of the battery costs that pile up." As I already invested to the battery I am among those who do not care so much for the battery cost. Who knows what the battery market will be in 10 years? I rather focus on minimizing variable costs - the grid.

2 Likes 2 ·
john245 avatar image john245 commented ·

@Dirk-Jan Faber

Sunday 01OCT.

Why is the system discharging with a very small amount. This is not efficient and it seems more efficient to put the battery on idle as unloading is scheduled for 02OCT evening.

1696180634186.png

0 Likes 0 ·
1696180634186.png (145.1 KiB)
stoneleigh avatar image stoneleigh commented ·

img-4200.pngUntil now I have been using scheduled charging in conjunction with the weather forecast, but automation using dynamic ESS will be a huge improvement. I’ve only tested it for a day or two so far but am experiencing strange behaviour, causing power to be drawn from the grid when there is plenty of power available in my batteries.


I am in the UK using the economy 7 tariff, meaning that I will schedule charge the batteries during the cheap period (0030-0730 UTC) when it looks like there will be insufficient solar pv generated the next day. I cannot sell power to the grid. DESS is configured for fixed buying prices, set for two periods, 0100 - 0700 UTC and 0700 UTC - 0100 UTC.


For example, this evening I used the fan oven (9.6kwh battery at 50%), but large amounts of power were being drawn from the grid (2-3 kw) the target SOC was sitting at 46%, having reduced from 61% earlier in the day. Today was a poor day for solar pv - only 2.5kwh. I schedule charged the batteries to 80% last night.


I hope this info is useful to the BETA testing, but of course I may be doing something wrong?

0 Likes 0 ·
img-4200.png (215.8 KiB)
john245 avatar image john245 commented ·

@Dirk-Jan Faber Is the minus sign correct. As a negative saving will cost money. An currently for all (5) days the negative amount was higher for Dynamic ESS as the normal ESS. Does this mean that it is more efficient to turn the Dynamic ESS off?

1696237663984.png

0 Likes 0 ·
1696237663984.png (15.6 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ john245 commented ·

That is correct, that seems to be the case. You might check if you have all prices set correctly.

We do expect best results during summer. The sun is providing less power now. Also at the moment there is not a lot of difference between sell and buy prices (at least not in NL).

This is another screenshot from a Dutch system, which does make more profit using Dynamic ESS compared to a regular ESS right now.
1696238505211.png

0 Likes 0 ·
1696238505211.png (16.7 KiB)
john245 avatar image john245 Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

@Dirk-Jan Faber Does the system standard compensate for 10% loss during charging and discharging?

Currently I added these losses to the tariffs.


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

No, at the moment it does not compensate for that.

0 Likes 0 ·
Craig Chamberlain avatar image Craig Chamberlain commented ·

Hi, I have enabled DESS and am seeing unexpected behaviour that I would like to query.

Background: I have a Multiplus-II 48/5000/70-50 with a pair of MPPT 250/60 controllers and a three Pylontech US5000 batteries totalling 14.4kWh (13.68kWh usable). The PV array is 6.8kWp and is DC coupled. Location is central Scotland. Tariff is Octopus Go with 30p/kWh at most times and 9p/kWh from 00:30 to 04:30 every day. Export is always at 8p/kWh. Battery costs currently set to 0.01 to simplify the expected behaviour.

During the hour from 12pm-1pm local time the target SOC was 51% and once that SOC was reached the inverter started to export to the grid. However, the target SOC for the next four hours is 57%, 64%, 70% and 72% respectively. Once it got to 1pm the new target of 57% came into effect and despite there being over 2.5kW of PV power available, it started to import from the grid at around 600w. That means it's costing 30p/kWh to import energy immediately after exporting it at only 8p/kWh. This makes no sense given that the future SOC targets are higher and higher. Why not just charge the batteries from PV power for free? Just a moment ago it hit the 57% SOC target and is now exporting to the grid again at over 1.2kW. I don't mind it exporting to maintain the target SOC but not if it's going to just import again when the target SOC rises at the next hour.

VRM ID is 48e7dadfbca5 if you want to take a look. I'll leave it in auto for now to see what happens for the rest of the day.

Many thanks, Craig.


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

This is by design currently, not unexpected. It tries to keep battery SoC stable and not the gird (by avoiding import/export), regardless of changes in PV/consumption vs. the forecast. In theory, in testing, this is a lot more cost-effective. That said, like you, I also struggle to see how this makes sense with some of the observed behaviour. See here for details: https://www.victronenergy.com/live/drafts:dynamic_ess#determining_the_target_soc

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

Maybe this is a design flaw. Backtesting of data usually does not work that good - backtesting of stockmarket is usually very good, but in real life not so good ;)

However. My system behaves just like Craig described. If buy price is 0.06€ and sell price is 0.01€ (battery cost zero), it still favours selling the PV energy, instead of charging the battery to use this energy later in the evening, when it would cost 0.06€ to buy.

I think/believe most of oss ESS users are interested in something that sucks up all cheap available PV during the day, and use this energy at night. But on those rare hours where it would be favourable to sell off some and still have battery energy through the night, that we want to automate.

If prediction is 20kWh of PV and 40kWh of usage and prices are low (but more expensive to buy), then one would like to save every available photon from the PV.

But if prediction is 60kWh of PV and 20kWh of usage, then there would be a 40kWh that could be sold off if prices are higher then the buy price.

I read the Q&A you linked and the last section if the opposite of how I think most of us want it to work. If price is cheaper right now, than later in the evening - we want to save the battery energy to when it is expensive - not as the example says, off load it when it is cheap and then have to buy when it is more expensive.

The text:

"Given a system at 15% SOC that has set the battery costs to 0.06 €/kWh, energy prices right now (11.00) set at € 0.29 and becoming € 0.40 this evening. Why would it feed into the grid already and not wait until the prices are higher?

The battery cost is € 0.06 per kWh. This means that for a cycle of battery usage to be useful (financially beneficial) the price difference should be at least € 0.12 cents per kWh (€ 0.06 for charging, and € 0.06 for discharging). € 0.40 - € 0.29 is € 0.11 which is below that, hence Dynamic ESS does not want to use the battery for this task, instead it is offloading the excess to the grid."


3 Likes 3 ·
Show more comments
marceldb avatar image marceldb commented ·

After I put DESS on Sell mode for a few hours, the SOC was 20%. After setting DESS to Auto, the target SOC was still 90%, so it immediately started charging, while the price was still pretty high.

So I turned off DESS in VRM, but DESS was still on in GX. So I had to turn it off in GX as well.

schermafbeelding-2023-10-02-210900.png

schermafbeelding-2023-10-02-210920.png

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ marceldb commented ·
Have you also been using the Node-RED implementation and disabled that? Both VRM as the Console write to the same "registry" for setting the mode. So they should always be in sync.
0 Likes 0 ·
john245 avatar image john245 commented ·

@Dirk-Jan Faber

It seems that the calculated saving with Dynamic ESS are not correct. Having a close look to the realized dynamic savings it will show all cost including the costs from the grid that is directly consumed.

1696403344391.png

0 Likes 0 ·
1696403344391.png (44.0 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ john245 commented ·

We are aware that there are still issues with the graphs and cost calculations. And working on fixing those.

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

Is it an option to mention the known issues/issues you are working on in the opening post so we can reduce the number of messages?

0 Likes 0 ·
kent2ben avatar image kent2ben commented ·

I have been testing DESS and it is a great feature! :)

Today I found a problem with my solar being limited with DESS on.

First picture: With DESS off I get 2.725W from solar and charges my battery with 2.222W

skærmbillede-2023-10-04-kl-110930.png


Second picture: With DESS on I am only getting 177w from solar and is only charging my battery with 193w.

skærmbillede-2023-10-04-kl-111039.png


Third picture: The "Target. SOC" is set to 36%

skærmbillede-2023-10-04-kl-111026.png


Conclusion / question: I looks like my "Target SOC" is limiting my solar production?
I have turned sell back to grid off but I would still like to charge my battery with solar?

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

Are you sure it was not a cloud that limited the solar production? There is nothing intentional in the code that would limit the solar production. Solar is preferred over grid when charging.

Check https://www.victronenergy.com/live/drafts:dynamic_ess#implementation for more info on the implementation.

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

It would be great to have an option like "only charge from solar" as long as solar forecast can cover the consumption forecast for the day and the following night.

Especially for countrys like Germany where selling solar is only some kind of emergency solution because of very low and not dynamic feed in prices. Here we have no benefit in selling from battery and in some cases it's even forbidden.

My wish would be running on 100% solar as long as possible (feed in only solar exccess) and buying as little as possible at the lowest price only if consumption forecast for the next 24h is bigger than solar forecast and battery stored energy for the next 24h.

1 Like 1 ·
hominidae avatar image hominidae ojack commented ·

I'll second this!

...and in most cases it is even forbidden to charge the battery from the grid (and then sell back later).

So energy prices for DESS in German only apply to energy directly consumed or the feed in from solar. The battery must only be charged from solar.

1 Like 1 ·
Show more comments
jns046 avatar image jns046 commented ·

Thank you all for bringing this to us! I live in the UK and really hope that you can incorporate the Octopus Energy range of products (that many of us with solar, battery and EV use because of their offerings). They have a product called Octopus Agile with day ahead pricing which would be perfect to use with DESS. They also have a range of fixed time fixed cost products with high and low costs not just overnight but through the day as well.

Please also consider adding the fixed price windows in 30 min sections as my current fixed price product (Octopus Go) runs at 9p/kWh between 12:30 and 04:30!

Thank you


Jon

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

The 30 minute interval has some more implications than just allowing it to be entered into the fields.

The calculations and forecasts are currently done on the whole hour, so that needs to be accounted for as well. And the same goes for the graphs. All not impossible to solve, but not trivial either and needs a fair bit of testing.

So the 30 minute interval will be added eventually, but it will take some more time.

0 Likes 0 ·
yvos avatar image yvos commented ·

@Dirk-Jan Faber

The system is dryving me nuts what am i doing wrong. In the morning it predicts normal buying on low prices and selling on high prices. In the afternoon the battery is full but the prediction is no selling anymore and setting me back for the third day in a row on about €6 loss per day.

Help is much apreciated.

https://betavrm.victronenergy.com/installation/307125/share/b4307021

schermafbeelding-2023-10-04-om-163438.pngschermafbeelding-2023-10-04-om-163452.pngschermafbeelding-2023-10-04-om-163503.png

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

Dynamic ESS charged the batteries during the low price hours to later in the day sell it in the evening. But after 3 PM it got the day-ahead prices (where tomorrow’s prices are on average higher than today’s) and it seems to hold on to the energy to sell it for even higher price tomorrow.

For your site this is tomorrows plan:
1696440105402.png

This does bring more urgency for us to get the graphs right for everyone to look at the planning for tomorrow.

3 Likes 3 ·
1696440105402.png (105.1 KiB)
yvos avatar image yvos Dirk-Jan Faber (Victron Energy) ♦♦ commented ·

Thanks Dirk-Jan that would give a better view on what to expect.

I cannot help myself to close the day with a positive earning on a sunny day :)

But I would imagine that manually turning the system into selling is not the way how it was intended.

One more thing

Tibber shows the day ahead prices at 13:00h is there a reason that the system imports them at 15:00h?


0 Likes 0 ·
john245 avatar image john245 yvos commented ·

In my opinion the system should do the first attempt at 13:00. In case the data for tomorrow is not available it should repeat at respectively 14:00, 15:00 till the data is available.

1 Like 1 ·
Show more comments
khostri avatar image khostri commented ·

Thanks for the work. Testing NodeRED variant for some time. I am curious - is it possible to use Dynamic ESS node just for parsing price? I would like to test VRM portal version, but need to have additional flow for Relay switching, connected to parsed price from dynamic ESS node.
Or is there stripped version of node, maybe even already combined with bigtimer? To be used together with Portal DynESS version without crossing each other? So bigtimer can be used for example for precharge battery to higher soc before weekend, use parsed price to switch Relay etc. I have tried to create flow for switching relay when there is excess to grid in specific amount longer that 10 minutes or when feeding is disabled and forecast is over specified amount of energy. But there is big room for enhancement :)

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

You should be able to import this example which allows showing the graphs from Node-RED, while leaving all controls to (beta) VRM.
From that flow you will still be able to access the dess context variable that contains all of the hourly pricing. The average price switching example uses the same logic.

If needed I can make a better example tomorrow.

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

Thanks a lot @Dirk-Jan Faber . I have tried that. On Beta portal I have some issue with Energy tab - that tab is not loading (other 2 are working normally):
1696760075514.png


I have tried to add my logic - as I have stated in github I dont know NodeRED - started to look at it just 2 months ago only for DynESS. So I know it can be done better. But there are my additions:

  • close relay2 in case there is excess for more that 8 minutes higher that heatpump consumption
  • on Friday and Saturday change ActiveSoC to higher value so battery is precharged for weekend cooking, working, etc (out of DESS logic). Then when targetSoC is reached once, it is switched back to DESS. I hope it ok to change mode from NodeRED even if control is normally done by BetaVRM (it seems that it works though :) )

Here are my additions (and full DESS flow):

DESS_addons.zip

DESS_full.zip

0 Likes 0 ·
Magnus Pernemark avatar image Magnus Pernemark commented ·

I see a few chearing this funtion that it is a good function. Is it really working for you guys?

Right now the sell price is 0.14 sek (0.01 ct) and buy price is 6 times that. In the coming 36 hours the buy price will be higher than the sell price, and battery will not öast through the night and tomorrow predicted solar is a fraction of required power to run the house.


Despite this DESS is opting to sell to the grid...

screenshot-20231005-223901-chrome.jpg



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

Looking at your site, it does not seem like it was planning on discharging to the grid. My best guess right now is that your consumption was lower than planned, so the offset was punished on the grid (by discharging). This is the default behavior right now, as also noted in the manual: "Dynamic ESS does keep the planned battery usage stable while punishing the forecast inaccuracies on the grid (selling the excess to grid, buy the additional need from the grid). This can be less ideal, but it is an issue of the forecasts being inaccurate, nothing that the Dynamic ESS decided."

Instead the system probably should have accepted that it was not going to reach the target SOC. And leave the offset power in the battery instead. This is definitely a point where the system can be improved. Finding general rules where the system always takes the right choice in these kind of situations is not that trivial.

1 Like 1 ·
André Jerleke avatar image André Jerleke commented ·

Hi!

Have a strange error when trying to set Battery SOC but it only say "loading" and after a while i get "having trouble communicating" , i tryied disable the dynamic ess in dashboard and enable it again, changing values but noting helps, i have another system exacly the same where this works fine, so right now i back to using nodered dynamic ess again until we find a solution., any idea? @Dirk-Jan Faber My VRM id: c0619ab2cc95

1696665706379.png


0 Likes 0 ·
1696665706379.png (53.9 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦♦ André Jerleke commented ·

It looks like your system does not have "Two way communication" set. It needs it for communicating with the GX device.


1696949567533.png

0 Likes 0 ·
1696949567533.png (24.7 KiB)
g8n avatar image g8n commented ·

I have now tried the Note-Red variant again on another installation. This installation has been running for more than a year and doesn't really have any special features. I switched back to the Note-Red variant to see what the system is planning. As long as I switch off the feed in Germany, it looks like the calculation could make sense. The moment I switch on the feed-in the system plans crazy things. In Germany we have a constant extremely low feed-in tariff. Feed-in fixed 0.067 €/kWh Grid usage is Tibber in Brandenburg is (p+0.18506)*1.19 The system does deliver all the stored energy to the grid despite the low remuneration. When I look at other comments, there seem to be calculation problems here, especially for Germany.

I wonder what happens if you have switched off feed-in, but there would be enough solar energy for feed-in and all batteries are full? Does the system then feed in or does it regulate solar down?

I have added two screenshots. The first is with the feed-in switched on. I absolutely cannot understand why the system would want to try to feed in the energy. The second screenshot is without feed-in.

1696668097741.png


1696668107301.png

0 Likes 0 ·
1696668097741.png (280.3 KiB)
1696668107301.png (164.5 KiB)
dennis-bosmans avatar image dennis-bosmans commented ·

1697011480767.pngI always have the problem that when the battery is charging and the grid setpoint is zero the software will also take an amount of electricity from the grid. The Exact amount depends on the solar production.
In the node-red version I added a formula to subtract ( P(pv) /13) from the grid setpoint and I always had a very small grid feed-in varying between +9W to -25W.


0 Likes 0 ·
1697011480767.png (52.4 KiB)
gdhondt avatar image gdhondt commented ·

Hi Dirk-jan Faber,


My setup:

  • 3 phase multiplus 48/5000
  • 45kWh battery capacity
  • 11kW PV connected on ac out
  • EV (start charging on lowest hour price by TIBBER app)
  • Heatpump
  • Running dynamic ESS
  • Location: Netherlands

Maybe it’s nice for you to follow my system to improve dynamic Ess.

My VRM token: c0619ab1df8b


Would be nice if you can implement boiler heating by Dynamic ESS. For example relay AC out 2


Kind regards,


Gertjan

0 Likes 0 ·
Ants Kosmos avatar image Ants Kosmos commented ·

In Estonia we have electricity 2 price times. From now on, the daily rate is valid all year round from 7 am to 10 pm. At the moment, the daily tariff applies on public holidays that fall on a working day. From now on, night traffic will apply on all public holidays. Day tax is 9,394 cents and night tax is 6,.... something. I do not remember. Difference is aprox. 3 cents. When my consumption is 2000kwh 50:50 day:night. This is 30€+ kwh price+ taxes. We have maybe 20 elecricity price packets, 6 sellers. Each has its own price formula but night and day prices not everyone has either. Sorry my english but i think you will understand. This is feature reguest. Add 2 times and 2 formulas for buy.

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

@Dirk-Jan Faber : Will there be a recording of the webinar? Unfortunately, I did not have time to attend the webinar today.

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

Yes, the webinar has been recorded. As soon as it is online, I'll ad a link to the webinar recording to the top of this post.

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

thanks a lot! I appreciate your and Victron's effort a lot. Really the right decision to choose your products. I encourage you to proceed in this way.

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

Updated the post with a link to the recording of the webinar (https://youtu.be/YU9jXyfM-eI)

1 Like 1 ·

Article

Contributors

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