article

Dirk-Jan Faber (Victron Energy) posted Jan 19, '24

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

Update 2024-03-05: This article has been closed for further comments. The follow up article can be found here.

Update 1-3-2024:

There is finally some news on resolving our blocking issue #1. With Venus beta release 3.30~10 it became possible to set input current as well as export current for systems having an Energy Meter. Please check the Peak shaving for ESS systems with an energy meter part on the details and how to configure it here: https://community.victronenergy.com/questions/265862/venus-os-v33010-available-for-testing.html

With this issue out to the way, we are getting real close to the official release.

Update: 22-2-2024:

With the new 3.20 release in between progress has been a bit slower than we'd wish, but I am happy to report that progress has been made on resolving the blocking issues. We are still testing with the fix for the first one and I hope to report a (beta) release of that one soon.

The second blocking issue has an update in the latest Venus beta release: 3.30~7. If you update to this release, the system should no longer offset discrepancies between the forecast and the actual consumption onto the grid. Meaning buying less power from the grid when the price is high.

If you want to use this, please update to the this release by setting the firmware update feed to "Beta release" and updating the GX device.

Welcome to the fourth update of Dynamic ESS (DESS) and (beta) VRM

It is about time for another update. Besides the previous post got so many comments that it got hard to keep track of it all. At the moment there are still two blocking issues, which prevent us from moving from BETA to release shortly.

Blocking issue #1: In a few test installs with Dynamic ESS, the main breaker, ie the one between the utility and the house, has tripped. For example when a EV was being charged at full power while at the same time Dynamic ESS was charging the battery. To prevent this, we’re implementing a new AC input current limit setting, for the connection point of the Energy Meter. Just like the traditional Victron PowerAssist and PowerControl features, the system will limit charging and/or use battery power to keep the AC currents within the configured limit. Both for import and for export. - See the 1-3-2024 update above.

This is not only for DESS, it is a generic ESS setting that can also be used for peak shaving. A very valuable and welcome new feature. More information on that will follow shortly in the v3.20 beta series.

Blocking issue #2: When prices are high, and solar or consumption forecasts don’t match reality, Dynamic ESS can still make for loads to be powered with that expensive utility power instead of being powered from the battery. We have a plan to fix that before release. Note that the related issue, charging with expensive utility power in case of forecast deviations has been solved a few weeks ago. - See the 22-2-2024 update above.

Then the other things that already got implemented during the last weeks:

Dynamically determine when to apply grid or battery restrictions, so when prices are high, DESS doesn’t charge from the grid, when prices are low, it doesn’t sell to the grid
Plot the fixed prices in the correct timezone in charts
Show the correct settings on the summary page
Correct yes/no on ’different prices in the weekend
Show 00:00 to 23:59 instead of 00:00 to 00:00
Take efficiency losses into account when simulating DESS and default ESS
Support entering negative (fixed) prices
Difficulty for users to change their formulas / settings due to the battery cycle cost fields
Show all DESS graphs to users without solar
Dynamic ESS on VRM taking Battery losses into account. The system looks at the dbus service com.victronenergy.settings, path Settings/DynamicEss/SystemEfficiency
When you use Dynamic ESS but don’t have solar in your installation, you will now still see the energy graphs

Meanwhile, we’ll keep on adding more improvements and fixes until the blocking issues have been resolved and tested. Note that it, in order to keep track of the latest additions, please run the latest candidate firmware release.

For those of you who missed the original posts, and wonder what this is all about. Dynamic ESS is an algorithm that aims to minimise the costs made on the grid and battery. Please check the three previous posts on the subject for further information.

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

There is a concept manual. 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

231

2 |3000

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

fjack commented · Feb 09 at 09:07 PM

Very nice that Victron is working on DESS.

Apart from the known errors, what bothers me most is that the battery discharge is stopped when the planned discharge is reached if consumption is higher than planned at high electricity prices.

It should be possible to optimise this significantly with a rule:

If more electricity has been consumed than planned, check whether there is still planned battery utilisation at lower exchange prices and then bring this forward.

I have this situation quite often with my WP. The heat pump starts earlier than planned and the electricity is expensive. When the planned consumption is reached, I draw from the grid. However, there are other hours with planned battery utilisation at lower exchange prices.

It makes much more sense to use the battery at 30 ct/kWh than at 25 ct/kWh.

3 ·

ojack commented · Jan 20 at 08:17 AM

Unfortunately, I completely lost track in the previous thread.

Are there plans to evaluate the losses differently for AC charging (Multi) and DC charging (MPPT)? And AC usage/AC feed in and DC usage/DC feed in?

In my experience, charging the battery via the Multis results in much greater losses than via the MPPTs. If my 3 Multi 3000 charge the battery with a maximum of 105A~5200W, then they take almost 6100W from the grid or from the AC PV. That's a 15% loss here alone. For PV this means that it could be good to use the AC-PV for the current loads and feed-in and the DC-PV to charge the battery.

1 ·

kudos50 ojack commented · Jan 21 at 11:39 AM

Earlier post in the 3rd topic that basically says the same thing: https://community.victronenergy.com/revisions/256028.html

0 ·

kudos50 ojack commented · Jan 23 at 07:30 PM

@Dirk-Jan Faber (Victron Energy) can you comment on this one pls ? In another post you elaborate a bit about 90% per transition for the calculations. Since DC PV only transitions once I guess the calculation must be a little different ? I cannot seem to achieve that result no matter the numbers I punch in the config.

Would also be good to know if DESS can actually charge DC PV but feed inverter PV to grid as I have only seen that behaviour during a low-soc condition as it's ESS default.

0 ·

kudos50 ojack commented · Jan 30 at 02:34 PM

@Dirk-Jan Faber (Victron Energy) gentle reminder...

0 ·

Show more comments

sarowe commented · Jan 21 at 07:01 PM

Ich hoffe, es reicht, wenn ich hier auf Deutsch schreibe.

Ich habe das DESS seit 7 Wochen laufen und bin begeistert. Mit einer Einschränkung, das Berücksichtigung von großen Lasten Für mich und viele andere ist es der zentrale Kritikpunkt.

Sie schreiben oft, dass sie an den Prognosenfeatures arbeiten, aber solange sie diese großen Lasten nicht auf irgendeine Weise einbinden bleibt das Problem. Für mich gibt es 2 Ansätze.

-Im DESS gibt es eine Schaltmöglichkeit für große Lasten, um darüber einen kausalen Zusammenhang für große Lasten zu erkennen.

-Da wir alle mehr oder weniger unseren Verbrauch dem Preis oder höherer PV-Produktion anpassen, sollte der Algorithmus das erkennen. Zum Beispiel, wenn ein sehr geringer Bezugspreis ist, geht der Verbrauch hoch, weil Lasten dazu geschaltet werden. Wenn der Algorythmus diesen Zusammenhang erkennt, wäre meiner Meinung nach schon viel erreicht.

Ansonsten großen Lob und vielen Dank für Ihre Arbeit

1 ·

dirks-1 commented · Feb 19 at 11:54 AM

Im on DESS with NodeRed. NR should be the main way because VRM need's internet and cloud based should not be the main way to handle such ciritical things.

Anyway, i'm testing DESS a couple of month now but it is still not usable. Also with v3.21 it is starting to feed the grid out of the battery just because of wrong target SOC decisions.

From tomorrow on i'm in a dynamic tariff with Tibber. But i have to switch DESS of. It is starting to feed the grid with 15 kW out of the battery because the target soc is a couple of one digit % below the real soc. Then it is starting to load the battery again. After reaching 0,1 % more than the target soc it is starting again to feed the grid with more than 10kW out of the battery and so on. The average PV production is ~6 kW at the moment.

It is switching on off all the time like this. It seems there is no hysteresis and the german law to never feed in out of the battery is not matched.

The setting is Germany but it want to feed in.

1 ·

1708349291226.png (17.8 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ dirks-1 commented · Feb 26 at 03:09 PM

Im on DESS with NodeRed. NR should be the main way because VRM need's internet and cloud based should not be the main way to handle such ciritical things.

I don't agree with you on this. The VRM implementation schedules 12 hours in advance, where the Node RED implementation only schedules 4 hours ahead. Both systems do the same thing, which is filling out the schedule; the controlling itself is done on the GX device.

The system should not feed into the grid if you have that value unchecked in the node red configuration. I checked yours and you seem to have "Feed in possible: Can you sell back to the grid?" checked. You should probably uncheck that.

0 ·

dirks-1 Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 28 at 06:56 PM

How could you know my vrm id? But yes i had the checked because i thought the meaning is i can sell to grid in general.

But in the meantime i switched to DESS from VRM beta. This implementation is better and i noticed the benefits. But it is still feeding to grid if the target SOC is lower than the real SOC. Disallow feeding the grid out of the battery is checked. (And the description is more clear in vrm) I think that makes no sense. If the real soc is higher than the target, then just keep it as it is and recalculate the forecast.

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ dirks-1 commented · Mar 04 at 02:30 PM

I know your vrm id because I work at Victron, which comes with the benefit of having extra ways of checking VRM and community.

The only way to prevent the feeding into the grid at the moment is to switch from running the latest official Venus firmware (3.22) to the latest beta release (3.30~10).
You can do that in the console via Settings -> Firmware -> Online updates -> Update feed. And setting that to "Beta release", update and reboot.

0 ·

grua commented · Feb 23 at 08:52 AM

@Dirk-Jan Faber (Victron Energy)

I have another, completely different suggestion:

LiFePo4 cells should be fully charged to 100% SOC at regular intervals (e.g. once a week). Otherwise, the SOC calculation by the BMS will no longer be correct after a while. Otherwise, top balancing is never carried out and the state of charge of the individual cells diverges over time.

It would therefore be nice if it were possible to specify the period in which 100% SOC must be reached at least once. DESS can then use either PV surplus (= preferred variant) or a favorable purchase price.

Currently, this is only possible by deactivating DESS and activating scheduled charging.

1 ·

dirk-s commented · Jan 20 at 02:33 AM

Question related to topic

Dynamic ESS on VRM taking Battery losses into account. The system looks at the dbus service com.victronenergy.settings, path Settings/DynamicEss/SystemEfficiency

What does it mean? Does DESS knows the efficiency of my installation? For example: my losses are around 18% for charging and discharging together. Currently I try to simulate this losses with the battery cost in DESS. I set battery costs of 0,04 Euro/kwh for an assumed average electricity price from grid of 0,25 Euro/kwh. Could I stop it?

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ dirk-s commented · Jan 22 at 01:56 PM

It works currently with the default value of 90% / 10% losses, which is arguably too high. As there currently is no easy user interface available for adjusting this value, you can use this gist in Node-RED to adjust the value: https://gist.github.com/dirkjanfaber/81d51dda52854a30aa1f1b2839e562fc

If you don't want the system to take efficiency into account, you can set that value to 100.

1 ·

ojack commented · Jan 20 at 08:25 AM

I reactivated DESS after some time.

I'm wondering why DESS plans to feed in first and only charge the battery at the end. If the clouds come earlier, a lot of PV has been sold for only 7ct and the battery can no longer be charged, which means that an unnecessary amount of electricity has to be purchased for more than 25ct.

0 ·

1705738814892.png (61.8 KiB)

1705739045478.png (48.9 KiB)

ojack ojack commented · Jan 20 at 09:29 AM

Now about 1 hour later the system plans no more loading the battery today. That's not acceptable for me. So I switch DESS off again.

Even the systemefficiency I set to 80% could not justify this because the gap between buyprice and sellprice is that large.

0 ·

1705742793819.png (50.7 KiB)

1705742818639.png (60.6 KiB)

ojack ojack commented · Jan 26 at 01:53 PM

Again first feed in and later charging the battery. If the weather changes during the day I need to buy expensive grid power instead of using my cheap PV.

0 ·

1706277179767.png (39.6 KiB)

martin-henning commented · Jan 20 at 01:08 PM

Updated to latest versions aswell, but I also experience solar being fed into the grid when battery is not full AND forecast of usage is super high, so next day PV cannot possible cover it. In a german installation the main objective is always to maximise self-consumption of PV, because anything grid-related is going to be more expensive. I tried to enforce that by setting the battery costs super low, but it does not help:

Target SOC is not being adjusted to higher value... because it thinks it will get it done by the end of the day? I think most Lithoum systems are confgured to to balancing only at the top end, so charging to 100% only at the very end of the day would shorten the balancing period to a minimum - might be advisable to prioritize that somehow. It seems the target SOC does not take PV power beyond the forecast into account? So it THINKS it cannot get over said SOC while actually more energy is being generated than forecasted which then actually overflows into the grid. This could probably be handled easily...

Secondly: Since irregular EV charging (my wallbox [openWB] automaticaly feeds excess PV into the car) completely destroys the forcasts, i suggest implementing a forcast max limit that the user could set based on the historical average of the house consumption. E.g. i KNOW that my daily average of the house is 20,6kWh/day. So a forecast of well over 100 is defnitely so far off, that we could actually throw that away. Why not cap the forecast at some value, say 25 in my case. It would greatly improve accuracy after charging our car and not totally destroy all planning.... ?

Will keep testing throughout the week, cars are full now..

.martin

P.S.: ID 48e7da89ba45

0 ·

screenshot-2024-01-20-at-135818.png (242.8 KiB)

pim57 martin-henning commented · Jan 21 at 08:32 AM

I support your idea of limiting the daily forecast because of EV charging destroying the forecast.

When EV metering is available, is this EV energy left out of the forecasting algorithm?

0 ·

Peter pim57 commented · Jan 21 at 09:37 AM

In GbbOptimizer you can tell program when you are going to charge EV and with what kWh.

0 ·

martin-henning Peter commented · Jan 21 at 01:58 PM

Exclude extra loads (eg. EV car charging) from house load profile"

That's exactly what DESS is missing to make it work at all in many cases.

2 ·

Show more comments

sarowe martin-henning commented · Jan 21 at 08:59 PM

Ich hatte heute einen extremen Stromverbrauch. Wegen Familienbesuchs hatte ich heute 2 e Autos zum Laden auf dem Hof und einige andere zusätzliche Verbraucher. Zwischen 8- 16 Uhr war mein Verbrauch ungefähr 3 fach so hoch wie normal an einem Sonntag. Ja es hat meine Verbrauchsprognose für einige Stunden völlig zerstört. Allerdings hat es sich jetzt 22 Uhr halbwegs wieder eingependelt.

0 ·

martin-henning martin-henning commented · Jan 22 at 10:32 AM

Ok after updating to v3.14-2 and no EVs connected I gave it another shot. First I set that i CAN sell energy back to the grid, meaning i can sell my PV for 8.6cent/kWh. Battery cost was configured to be 3cent/cycle. The result:

Yet again pushing my precious PV power into the the grid for no reason? I deactivated the setting that i can sell, then it finally charges my battery with excess PV. Did I misunderstand the price calculation?

For now will let it run without "selling" to see what it will do over time...

0 ·

screenshot-2024-01-22-at-112332.png (619.6 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ martin-henning commented · Jan 22 at 02:14 PM

The main cause for this is the fact that blocking issue #2 is still there.

0 ·

martin-henning Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 22 at 05:16 PM

Hi Dirk-Jan, i wasn't sure as this was during the day when the daily sum of the forecast had not yet been reached - or would the above issue relate to hourly differences aswell?

0 ·

Show more comments

daniel-feist commented · Jan 21 at 12:26 AM

This progress sounds really positve! I havn't used DESS for months given the issues with it not ajusting (within the hour slots) to real consumption/PV which I, amoung others, raised as a significant issue. Looks like now is a good time to take it for another spin though..

Just one thing, I havn't seen mentioned recently, is that for me to be able to use this in ernet (as with everyone else in the U.K) we really need support for 30min slots.

Thanks!

0 ·

Peter daniel-feist commented · Jan 21 at 07:52 AM

GbbOptimizer supports 30 min time slots

0 ·

daniel-feist Peter commented · Jan 21 at 10:31 AM

I did look at GbbOptimizer a few months ago but the UX was really quite complex, and I didn't get as far as configuring everything. Might have another look,

0 ·

Peter daniel-feist commented · Jan 21 at 11:24 AM

Contact with support on Discord, they help you.

The UI is complicated because the program has so many possibilities.

1 ·

daniel-feist daniel-feist commented · Jan 21 at 02:00 PM

Unfortunately it's being turned off again :-(

Had all night to charge the battery at just 7.5p, but it decided to only charge to 63%. This didn't seem right but I thought I'd trust it (maybe based on pv/consumption forcast that was all I needed to to get through the 35p day rate), so I left it enabled. Still not behaving as I'd expect though:

Couple of things I noticed:

1) Last night the consumption forcast seemed too high, and DESS thougt my battery needed charging to 100% and would only last until 6pm, but then at some point during the night it changed it's mind; consumption forcast is now seems really quite low and it only charged battery to 63%

2) I just cooked lunch (3kW oven coming on/off every few mins for 30min) and it's importing from the grid at 35p, trying to maintain a specific SoC.

I know just using plain ESS isn't as efficient as it could be because:
- I'm charging battery to 100% every-night even if not needed.
- It puts PV into battery when export rate is high (15p) and there is already enough in the battery to last until nighttime cheap-rate (7.5p). (this will be more of an issue as we move into spring summer).

But, currently my assumption is that, while DESS continues to import at 35p during the day it is best for me to stick with ESS.

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ daniel-feist commented · Jan 22 at 02:12 PM

The main cause for you bad experience is the fact that blocking issue #2 is still there.

1 ·

Andi commented · Jan 21 at 09:39 AM

VRM ID :c0619ab313dc
Ab wann läd das DESS aus dem öffentlichen Netz? Ich habe das DESS jetzt fast 24 Stunden laufen und bis jetzt hat er nicht aus dem Netz geladen. Der Akku war vorhin bei 48% und die Kosten waren 21cent/kwh. Ich habe dann mal bei 20cent manuell dazugeladen. Morgen ist der Strom wieder teurer.

Hello, I am wondering from when DESS starts to charge my battery. I use an hourly electricity tariff. And it would make sense if, for example, it charges during the cheapest 4 hours of the day.

My battery is currently at 48%. At the moment, electricity costs 21 cents, and the battery should be charged at this price.
Gruß Andi

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ Andi commented · Jan 22 at 02:46 PM

What I see on your site is that you have it set to use the Node-RED implementation, with a buy price set to "(p*1.19)+17.62", which adds more than 17 euro's to each kWh.
So I guess you need to adjust your formula.

1 ·

Andi Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 26 at 03:21 PM

Hi!I have changed the purchase price to 0.1762 cents. I've been running the system for two days now without manually charging the battery. Unfortunately, the weather is so bad at the moment that no sun is charging the battery. The battery is now at 46% and the dynamic electricity prices were so low in between that the battery can be charged from the grid, right?

0 ·

sarowe Andi commented · Jan 26 at 06:50 PM

Sind die Preise wirklich so niedrig? Mein System lädt auch nicht. Aber wenn ich nachrechne und bedenke das ich ca 15% Verluste beim Akku habe und dann noch 2-4 cent Akkukosten habe, ist es dann wirklich günstiger aus dem Netz zu laden?

1 ·

Show more comments

andrii-podanenko commented · Jan 21 at 01:56 PM

Using DESS more than a month now.

I can't see any difference at all.

My setup

Pylontech US5000C

MultiPlus II 3000 48

Cerbo GX

DESS 70% SOC, ESS no battery life

https://betavrm.victronenergy.com/installation/380883/share/813a14fb

I have 2 price levels in Ukraine

Night - 50% lower than a day. (Night tariff 23-7, day 7-23)

No ability to sell

No solar.

AC in comes from independent main system on Multi RS 6000 Dual Tracker with own cerbo and solar.

Expectation - DESS to charge battery at night when SOC could go less than a threshold. Would be great to come to night->day moment with 100% SOC, but this is not happening.

Additional variable I have - when there is an excessive solar power on Multi RS system I'm changing MultiPlus II ESS to "keep batteries charged" and switching back to "ESS without battery life" when lack of solar. Happens after the noon . You can see it on the graph above - short charge in the morning when sun is on a horizon, and full charge afternoon when excessive solar in a previous system. This is organized via Node-RED by myself.

On graphs I can't see "saved funds" at all. Would be great to have DESS graphs weekly, monthly in order to see if there is anything at all there.

Or let me know how I can see work of DESS algorithm in order to notify myself with "woohoo" Push notification and understand the process.

Thank you.

Ping: @Dirk-Jan Faber (Victron Energy)

0 ·

screenshot-2024-01-21-15-52-00-371-comandroidchrom.jpg (319.2 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ andrii-podanenko commented · Jan 22 at 03:27 PM

This is a bit if a non-typical system, which might be better of running plain ESS and scheduled charging.

1 ·

andrii-podanenko Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 23 at 10:55 AM

I'm about to install MPPT 150\70-MC4 VE.Can on this system and still hoping to see it to charge at night when the price is lower and SOC is on treshold.
Thank you for your reply @Dirk-Jan Faber (Victron Energy)

0 ·

Peter andrii-podanenko commented · Jan 22 at 05:02 PM

Try GbbOptimizer. It supports such systems.

0 ·

zed-must commented · Jan 21 at 06:05 PM

is DESS intended to work with wind power too? because everything mentioned is for solar - will it work for wind only?

0 ·

grua commented · Jan 21 at 09:11 PM

Same problem for me as already reported by others:

PV excess is sold to the grid at very low prices (6 cent/kWh) instead of being used to charge the battery. Shortly afterwards, the battery is charged from the grid at much higher prices (18 cent/kWh).

That makes absolutely no sense! The PV excess must go into the battery! Under no circumstances should it be sold cheaply to the grid only to be bought at a higher price shortly afterwards:

Again: PV excess must go into the battery, at such high differences between sales and purchase prices!

Edit: I used release candidate v3.20-35, but there is a newer v3.14-2. Just installed it and give it a try!

0 ·

1705871349817.png (75.6 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ grua commented · Jan 22 at 02:18 PM

This is caused by the second blocking issue being there.

Once a fix for that has been released, I'll report it.

2 ·

sarowe Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 22 at 06:05 PM

Ja bitte......Ich glaube es wäre für viele von uns sehr wichtig, wenn nicht sogar entscheidend

1 ·

dirk-s grua commented · Jan 22 at 03:07 AM

In the meantime I recommend the option in DESS not to sell to the grid. This avoid this behavior.

1 ·

sarowe grua commented · Jan 21 at 10:56 PM

Läuft die 3.14 schon sicher

0 ·

grua sarowe commented · Jan 22 at 06:15 AM

The screenshot above is from v3.20-35.

I discovered and installed v3.14-2 afterwards. I will have to observe whether this behavior (sell cheap, buy expensive) still occurs with v3.14-2. I will report!

1 ·

Show more comments

grua commented · Jan 22 at 06:34 AM

No consumption forecast for today afternoon?

Also non for tomorrow:

VRM ID: b827eb273733

0 ·

1705905163142.png (43.4 KiB)

1705905239027.png (31.0 KiB)

grua grua commented · Jan 22 at 06:47 AM

I have therefore deactivated DESS again for the time being, as any PV production is planned to be fed into the grid due to a lack of consumption:

0 ·

1705906005115.png (36.9 KiB)

grua grua commented · Jan 22 at 12:23 PM

OK, consumption forecast is back again von Beta-VRM

So I activated DESS again, but without selling energy to grid, as recommended by @Dirk_S (https://community.victronenergy.com/comments/256503/view.html)

At the evening I'll try to enable selling again. Curious to see what the plan for tomorrow will look like...

0 ·

ronaldt commented · Jan 23 at 06:30 PM

Good news and a lot of improvements. Really happy with improvement number 1. I now try to fix that with node-red, which works but is more a workaround and a bit slow so it can still overshoot.

One other improvement would be that the charging of the car is taken into account in some way. It completely destroys the forecast while the charging time is known because the charger is part of the Victron eco-system.

I use the node-red DESS 1.11 version, and see something strange now. It is not buying and selling at all anymore. The prices go up and down a lot (thanks to storms Henk and Isha) but DESS decides to just use the grid and not even the battery when the price is high.
See screenshot below.

EDIT: I found the issue. I had set the battery cost too high. I calculated the cost for one cycle of all the batteries (60kWh). But I now changed it to cost per kWh and it works again. These costs are apparently not shown in the buy/sell price graph and that has got me on the wrong foot.

0 ·

schermafbeelding-2024-01-23-om-165206.png (364.1 KiB)

ronaldt commented · Jan 24 at 09:14 AM

Keep up the good work! I am trying to understand the system but it makes decisions I cannot understand and do not seem related to issue 2.

It seems that DESS has a preference to sell, sell, sell.... I always end up with empty batteries for some reason. See screenshot below.

When there is no possibility to buy back the energy cheaper then I sell it now, I would not sell it. If I look at a guesstimate (see screenshot below) of the prices, then I'll have to use the high prices from the grid for my energy the coming days. While I had cheap energy in my battery available, but that is all sold. And why does it not charge between 12:00 and 14:00. That seems a good time to buy back the energie that was sold between 8:00 and 10:00.
At 10:00 it is putting my PV directly in the Grid and not in my batteries. Why? I would save it and sell it between 17:00 and 20:00 where the sell prices are much better.

0 ·

schermafbeelding-2024-01-24-om-100318.png (118.3 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ ronaldt commented · Jan 24 at 01:09 PM

I took a look at your system and noticed you only had it running for a few hours (and switched between the Node-RED and VRM implementation). The system tends to plan the battery to be able to supply the forecasted consumption. If there is more power left in the battery and the system can make some money with it, it will sell when the price is high.

You can set the option not to sell back to the grid, which will prevent selling to the grid. Once issue 2 has been resolved, that should no longer be needed.

The system is likely to adjust the planned schedule as soon as tomorrows prices come in (latest at around 15.00).

0 ·

ronaldt Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 24 at 03:36 PM

Yes, I indeed switched between the VRM and node-red implementation to figure out if there was different behaviour.
When the new prices came in, the system decided to sell tomorrow (and not today anymore). Which is good. But still no plan to buy from the grid to charge the batteries. So I will end up with empty batteries with the only plan left is to use the grid at any cost.
If that is an Issue #2 issue, then I'll just wait.

I am more than happy to perform tests if new software is available. I can run VRM beta and node-red. I will leave it on node-red for now and see what happens.

Below a new screenshot. The forecast is ruined because I charged the car between 12:00 and 14:00. But that will come back normally in a few hours.

0 ·

schermafbeelding-2024-01-24-om-162347.png (382.5 KiB)

ronaldt ronaldt commented · Jan 25 at 02:34 PM

Also today I see opportunities to buy for a low price and sell for a high price. Selling for a high price works. But the system doesn't buy for a low price. I think there is a good price between 35 and 40 to be sold later. The only energy increase in the battery is from the PV at the moment.

0 ·

schermafbeelding-2024-01-25-om-153059.png (128.2 KiB)

Show more comments

grua commented · Jan 29 at 02:22 PM

@Dirk-Jan Faber (Victron Energy)

Is this also a problem related to blocking issue #2 or is it intentional?

PV excess is sold to the grid at low prices, so that at the end of the day target SOC = minSOC. As a result, however, expensive electricity has to be purchased from the grid in the following hours, as the battery is already discharged to minSOC. In this case, it would be much better to store the PV excess in the battery instead of selling it cheaply.

Will this be changed when blocking issue #2 is resolved?

0 ·

screenshot-20240128-173441-chrome.jpg (233.1 KiB)

screenshot-20240128-173455-chrome.jpg (204.8 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ grua commented · Jan 30 at 12:40 PM

That is a slightly different issue, but we are working on that too. That is ending the day with more power in the battery.

1 ·

grua Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 30 at 12:49 PM

Very good! Ending the day with more power in the battery would be very important in my opinion. Precisely for the reason that between midnight and the start of solar production there is no need to buy unnecessarily expensive power from the grid. I'm glad you're working on it!

0 ·

Show more comments

gnagflow commented · Jan 31 at 11:11 AM

Hello, thank you for working on that great feature.
I tried it first and i found two issues: a) when purchase price is lower than sales price, it does not buy during nights and sell during days. (sometime it happens)
b) example below. why does it sell from the battery to the grid from 8-9 oclock for 15cents, when it bought the energy from grid to the battery during night for 18cents?

thank you

0 ·

1706699430566.png (64.1 KiB)

freese commented · Jan 31 at 10:14 PM

Next try….

PLEASE… Victron. Can you help me to find the issue? …or is it a feature I misunderstood? Mistake in the configuration on my side?

To be honest I own a very small diy system but I am very happy with it and your idea of the DESS… and the Tibber prices.

Why decide the dess to discharge the battery at 4-5am and not at 6-7?

Please help to understand.

Ich Danke euch

Christian

0 ·

img-1222.jpeg (211.7 KiB)

freese freese commented · Feb 01 at 07:03 PM

Next day…next try… happy sunshine

0 ·

img-1226.jpeg (228.6 KiB)

grua freese commented · Feb 01 at 09:22 PM

Which Venus OS firmware are you using? I don't know if it's related, but I use the latest release candidate, currently v3.20~43. I can't observe this behavior so far.

0 ·

freese grua commented · Feb 02 at 12:27 PM

It is the 3.20 -43

0 ·

freese freese commented · Feb 07 at 06:42 AM

another day…. Any feedback?

0 ·

img-1234.png (178.3 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ freese commented · Feb 07 at 08:58 AM

It is indeed strange that it used the battery between 3:00 and 5:00. Not sure why it does that, but I'll investigate and report the findings.

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 07 at 02:09 PM

The cause for it has become clear. The grid has maximum import power of 2 kW. In those hours DESS expects more consumption than that hence it plans to use the battery.

But that does not help you much right now (apart from that you might be able to increase that value). In this case the system does make the wrong decision and we want to fix that properly, making sure we don't introduce undesired side-effects.

It would be nice to get the site id of @Hominidae as well, as that might be also happening on that site. The more sites that have this happen, the easier it is to check if a solution will work.

0 ·

hominidae commented · Feb 01 at 08:22 AM

OK, finally the switchover to tibber occured this night.

I set-up and enables DESS right away and actually the shedule looked quite good.

The system started to charge the battery immediately, as that time also marked the slots with the lowest price.

But charge went only halfway, stopping at SOC 49%, while low prices continued for some more hours during which the battery would not discharge.

While the latter is fully understandable to me, I do not understand why the battery was'nt charged to a higher SoC.

As with higher prices, discharging the battery started, which is also fully OK.

But then, the system decided to go full chargemode while the price was at its peak this morning (and SoC still 36%).

This is actually not acceptable.There is no way, that this is commercially feasible, as solar would kick-in as well soon, with a good forecast for the day (should top-up the battery with another 50% SoC until evening).

This is how the system behaved. I now disbled DESS...this is not ripe for a pilot.

Maybe I need to look into other ways of optimizing that with NR myself.

0 ·

1706775535594.png (132.5 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ hominidae commented · Feb 02 at 01:37 PM

Can you provide the site id you where testing on, so I can take a look at what caused the problem? (it could be issue #2, as mentioned above).

0 ·

hominidae Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 07 at 02:46 PM

@Dirk-Jan Faber (Victron Energy) sure, this is it: 48e7dadf2705

1 ·

Peter hominidae commented · Feb 01 at 08:43 AM

> Maybe I need to look into other ways of optimizing

Try gbboptimizer.gbbsoft.pl :-)

-1 ·

hominidae Peter commented · Feb 07 at 03:57 PM

@Peter pls stop advertising your alternative solution...IMHO it's becoming a nuisance and I'll consider it spam from now on. This is the modification section of the forum and I'd also consider participants to wish to improve the existing victron installation or software here. Maybe another part of the forum is in order for such advertisments.

1 ·

Peter hominidae commented · Feb 08 at 10:55 AM

OK. I'm sorry, I didn't know it bothered you. You're right, I won't propose the program more here, because the number of people interested is already quite large. ... and it's not even spring yet.

0 ·

daniel-feist commented · Feb 01 at 10:28 AM

Are 30min slots on the roadmap? Can you give U.K. users a rough idea of where it is on the list? My cheap tarrif is from 23.30->05.30 and it's sub-optimal to have to use 00:00->5:00 in DESS.

Thanks!

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ daniel-feist commented · Feb 07 at 09:39 AM

This is on the roadmap. It is quite a big change, involving adjusting all of the graphs as well.

Meanwhile you can also put in the average between those two prices for 23:00-0:00 and 5:00-6:00. In your case that would be 0.075 + ( 0.306-0.075) / 2 = 0.1905.

0 ·

daniel-feist Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 08 at 12:03 PM

Yes, but average won't necesarily give the expected results in terms of avoiding import at higher rate. That is why a defensive approach of reducing the off-peak window from 00:00->05:00 (instead of 23:30->05:30) is preferred I think.

This will work, but limits optimization possible a bit and also reduce the time available to charge battery in off-peak period. In my case 5hrs is still plently, but with smaller inverters or shorter off-peak periods this can be a concern.

0 ·

ferguswheatley commented · Feb 11 at 10:12 PM

I love this, I have been involved with Grid pricing in Ireland for years, letting customers know when is good / bad to run district heating heat pumps or CHPs. up to now I have been using an echelon smartserver to do the switching. e.g. Run the heat pump in the 8 cheapest hours in the 24 hours. I supply Irish prices on my website, but I would love to provide this information via an API. Is there a countries format I could copy? XML would be preferable, but JSON would work also.

I was putting an ESS system on my house and followed this rabbit hole, very very impressed with Victron.

Irish Electricity Prices. DAM, IDA1, IDA2, IDA3, Balancing Market (smartpower.ie)

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ ferguswheatley commented · Feb 23 at 07:35 AM

We are using the API from https://transparency.entsoe.eu/transmission-domain/r2/dayAheadPrices/show to get the day ahead prices. This is the main source for all energy providers in Europe.
You can also get the info quite easy using one of the two Node-RED nodes: https://flows.nodered.org/node/victron-dynamic-ess or https://flows.nodered.org/node/victron-dynamic-ess.

0 ·

ron-h commented · Feb 13 at 07:19 PM

Verry interesting this DESS, as soon mine battery is up and running I will test it.

Main input is the day ahead price, but is Victron also looking at a virtual powerplant integration?
For example Zonneplan (powerplay) here in the Netherlands is planning to start a virtual powerplant based on (nexus) home batteries.

Know Sonnen has done this in Germany.

Is Victron planning to make an integration with Sonnen or Zonneplan?
As a virtual powerplant you can trade on balance market and gains are this way bigger than the day ahead price trading.

0 ·

Ants Kosmos commented · Feb 13 at 09:12 PM

Suggestion.Important. In Estonia electricity taxes in weekdays from 7 to 22 are higer. What ever is kwh price.I use dess and what i see tomorrow ? Pure charging. 12kwh. Please make charge time at night only. I have 60kwh battery. VRM portal id is b827eb33b05e. I think no one is in estonia not want charge battery at weekday day. Sry my english.

0 ·

screenshot-2024-02-13-at-230759.png (173.6 KiB)

Eric commented · Feb 14 at 07:12 AM

Hello,

I enabled the beta VRM for the first time last night. The setup seemed to go smoothly, and after correcting my error on the fixed pricing schedule, the vrm looked like it was going to charge during my fixed cheap rate period early this morning.

It didn't so i wonder what i got wrong?

Vrmid = d83add039270

Other questions i have:

-- Do i need to load the beta Venus OS as well? I didn't because i couldn't see that in the setup instructions.

-- When setting the export and import power, should it reflect the grid settings or the victron inverter settings?

I have an AC coupled inverter capable of 3.6 kw, i am also allowed to export up to 3.6kw by the electricity company. However my battery has a Multiplus 2 48/3000.(so only 2.4va charge/export)

-- I like the VRM app. I assumed i will have to wait until Dynamic ESS is live to use it again.

I'm looking forward to the feature improving.... Keep up the good work.

Eric

0 ·

kampfiltis commented · Feb 14 at 08:36 AM

Hello,

i noticed the Problem "Dynamic ESS slow discharge on idle when reached target SOC" described here: Dynamic ESS slow discharge

This behaviour seems to be startet with this change:

Changes v3.20~15 -> v3.20~17
Various Dynamic ESS related improvements:
Remove the separate DESS MinSoc setting. DynamicESS now uses the ESS MinSoc.
Stop showing "Low Soc" errorcode when DynamicEss reaches the target SOC.

0 ·

Erling Anderberg commented · Feb 15 at 08:49 PM

Hi, I am running DESS since autumn. Works quite well now. Thus, I can not charge the battery bank “outside” the Victron system. In VRM; SOC 30%, no Batt. Life, buy & sell, 48VDC 200AH, 3x MPII 5kVA, MPPT 450/200, Cerbo Venus OS v3.20~50.

I want to charge the batt. from a source that Victron system do not know about.

Let’s say SOC is 30%, all charging power to batt., at 33% system starts to invert and put the power to support the load & grid instead. If I then stop the charging, system reduces the SOC to 30% again. I want to raise the SOC instead. I have also tried to fool the Cerbo DI “generator”, Running/Stopped.

Yes, I know that I can go over Node Red and take the whole control. Not the prio. solution, the Venus OS are doing a quite good job.

Suggestions ?

0 ·

julienlg commented · Feb 19 at 01:13 PM

Hello,

I would like to input 30-minute time intervals. How can I do this?

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ julienlg commented · Feb 19 at 01:39 PM

That is not yet possible. Work around right now is to take the average price of the two hours around it. See https://www.victronenergy.com/live/drafts:dynamic_ess#qmy_providers_changes_price_at_the_half_hour_instead_of_the_full_hour.

0 ·

Peter julienlg commented · Mar 03 at 06:18 PM

GbbOptimizer supports 30-minute timezone and a lot of people from UK are using it.

0 ·

dirks-1 commented · Feb 21 at 08:15 AM

I'm located in Germany but DESS want to feed into the grid out of the battery. What it is calculating at the moment makes totally no sense. Why not just keeping the energy in the battery for later use?

0 ·

1708503247387.png (89.9 KiB)

Andi commented · Feb 22 at 04:37 PM

Heute Nacht habe ich einen Strompreis von 16 cent( 23:00 Uhr - 6:00 Uhr. Ich frage mich, warum DESS nicht den Akku vollmacht?

0 ·

bildschirmfoto-vom-2024-02-22-17-36-48.png (199.2 KiB)

grua Andi commented · Feb 22 at 05:01 PM

zeig mal die zugehörige SOC-Prognose für den morgigen Tag. Soweit ich das bisher nachvollziehen konnte wird vom DESS immer nur soviel in die Batterie geladen (egal ob von der PV oder vom Netz), dass der SOC am Ende des Tages dann bei ca. min. SOC liegt. D.h. nur soviel in die Batterie laden, was lt. PV-Produktionsprognose und Verbrauchsprognose unbedingt notwendig ist um über den Tag zu kommen.

Mehr Energie lädt DESS offensichtlich bewusst nicht in die Batterie, da das erstens Umwandlungsverluste bedeutet und zweitens nicht für die Laten notwendiger PV-Überschuss lieber verkauft wird um Geld zu verdienen.

Mir gefällt das so auch nicht. Ich hätte lieber mehr PV-Überschuss in die Batterie bzw. sonst bei günstigen Kaufpreisen in die Batterie geladen um Reserven für höher als prognostizierte Lasten zu erhalten. Zusätzlich sollte am Ende des nächsten Tages nicht auf min. SOC geplant werden. Denn dann existiert keine Energie mehr in der Batterie für die Zeit zwischen Mitternacht und Beginn der nächsten PV-Produktion...

Aber angeblich arbeitet Victron an beiden Themen (höhere Reserven für unvorhergesehene Lasten und mehr als min. SOC am Ende des Tages).

@Dirk-Jan Faber (Victron Energy) ist Deutsch in Ordnung oder sollten wir bei Englisch bleiben?

1 ·

Andi grua commented · Feb 22 at 05:33 PM

Du meinst also, den SOC hochsetzen?

0 ·

bildschirmfoto-vom-2024-02-22-18-30-24.png (131.5 KiB)

grua Andi commented · Feb 22 at 05:47 PM

Ich meinte das Bild darüber, wo man den zeitlichen SOC Verlauf sieht mit Prognose von PV Produktion und Verbrauch.

min. SOC höher setzen bringt auch nur ein einziges Mal was. Die nächsten Tage plant DESS dann (soweit ich sas beobachtet habe) wieder nur gerade soviel Batterieladungen, dass der Target-SOC am Ende des Tages dann am neuen höheren min. SOC zu liegen kommt. D.h. man verschiebt damit die gesamte Target-SOC Linie parallel nach oben. So zumindest meine Vermutung.

0 ·

Show more comments

gloitom commented · Feb 23 at 08:26 AM

with v3.30~7 nothing changed, still loading from the grid at high prices

0 ·

screenshot-2024-02-23-at-09-20-11-vrm-portal.png (222.6 KiB)

stefan-db commented · Feb 23 at 12:25 PM

2 questions after basic testing DESS & his actions.

Why is there no custom field "Minimal profit for sales?". In my simulation he planned to sell to the grid à profit 0.02€ what is to low to take any risk in my opinion.

Second why not linking more weather data to the forecast consumption? If you would make correction factor on consumption forecast based on historical data (min T - max T & Humidity) then you can solve mainly the problem off inaccurate forecast due extra loads off heatpumps or airco.

0 ·

sarowe commented · Feb 24 at 08:20 AM

Ich teste jetzt seit Monaten das DESS und bin im Prinzip begeistert. Allerdings das Nachladen aus dem Netz zur vollen Stunde, nur weil das Soc Ziel nicht erreicht wurde, ist aus meiner Sicht kontraproduktiv. Vorallem bei erwarteter PV Produktion. Solange dieses Problem nicht gelöst ist, ist das System aus meiner Sicht unbrauchbar.

Trotzdem das ich von der Grundidee und der bisherigen Arbeit begeistert bin.

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ sarowe commented · Feb 27 at 11:21 AM

With the latest update (running the beta firmware feed), this reaching the SOC should no longer be done every hour. If it still does, please let me know your vrm id, so I can take a closer look.

0 ·

sarowe Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 28 at 11:57 AM

Danke....

Ich glaube jetzt läuft es wirklich gut. Jedenfalls soweit ich heute beobachten kann. Für mich wäre es der Durchbruch. Ich werde berichten.

Danke Jungs......gute Arbeit soweit

1 ·

Show more comments

dirks-1 commented · Feb 24 at 12:42 PM

My feeling is that DESS is still very far away to be fully functional. Also we need a few more options. The formular to load from the grid should not only be decided by price and forcast target soc depending on expected need but also from the autarky point of view. In the summer time, if enough PV is available i don't need the grid in general. Only in the dark time without enough PV, loading from grid can be relevant. But every system is different so we need more options which will change the way of forecast and decision making of the formular.

Also heaters like MyPV should be considered in connection with Gas Pricing. This should be considered together with grid sell prices. It can be more efficient to not load the battery from the grid but feed the electric heater when the grid prices and is lower than the gas price and heating with gas.

In general we need a hard option to never sell to grid out of the battery. It is still the case. This never should happen in case of a fix sell price. Only the very last sureplus can flow into the grid. At the moment it just take the (mostly wrong calculated) target soc and start to feed the grid out of the battery if the real soc is higher than target soc. That makes no sense in general.

We also need hysteresis options. At the moment it seems there is no hysteresis in general.

As i said every system is different and every situation as well also the user expectation is different. So a general formular for DESS does not make sense.

When you really want to be the highest developed DESS system, then Victron should consider to hire a KI developer instead of using static formulars for decision making ;)

0 ·

grua dirks-1 commented · Feb 24 at 01:13 PM

You wrote "In general we need a hard option to never sell to grid out of the battery". This option already exists!

In my opinion, the gas price is a very special issue, and I really wouldn't demand that in the initial phase of DESS. There would be so many more special points, please let Victron optimize the basic functions first. More can be done later if necessary.

"Only the very last sureplus can flow into the grid." Here I agree. Only after the next day's prices are available should any surplus be sold, but to be on the safe side, the battery should be charged beforehand if it is not yet fully charged.

1 ·

dirks-1 grua commented · Feb 24 at 02:52 PM

Yes, it would be a nice to have to have a gas price and decide to feed a electric heater instead. But i agree, first the main DESS need to work perfectly.

I know it should be already implemented to not feed the grid out of the battery. But it does not work at all. The last DESS tries to always make the battery empty to the grid:

0 ·

1708786329444.png (107.0 KiB)

dirks-1 dirks-1 commented · Feb 24 at 03:08 PM

I used the NodeRed Flow. But now i try the Beta VRM Flow which seems much more developed.

0 ·

sarowe dirks-1 commented · Feb 24 at 05:05 PM

Weit entfernt funktionsfähig zu sein würde ich es nicht nennen. Für mich als „Nulleinspeiser“ läuft das System prinzipiell gar nicht schlecht. Allerdings finde ich das Nachladen zum Ziel Soc einfach nur ärgerlich. Ich habe auch das Gefühl, es wird schlimmer und nicht besser. Ich bin mir nicht sicher, ob es an den Veränderungen von Victron liegt oder an der zunehmenden PV-Produktion und damit auch höherer Prognose und Ziel Soc.

Ich werde jedenfalls erstmal das Experiment DESS abbrechen und auf Infos zu Verbesserungen hier im Forum warten.

1 ·

simonyoungtree commented · Feb 26 at 08:19 AM

Energy Graph incorrect:

Yesterday's (25-2-24) energy graph showed some grid-to-battery energy moves (see between 13h and 16h). However during this timeframe no grid energy was moved to the battery. For your information: I am forcing my DC connected solar energy to the battery by setting the inverter power to zero from 10am to 16pm (via Node-Red)

This is the graph of grid energy moving to various targets of the same day on the same VRM-beta. You see only a tiny bit of grid energy flowing to the battery at 14:00.

I am running the latest of the latest software.

See below what happened with the solar energy.

0 ·

1708934602360.png (26.4 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ simonyoungtree commented · Feb 27 at 11:35 AM

I don't want to rule out that there is a bug here. But, for a large portion of the systems that support it the new strategy only got activated yesterday morning (26-2-2024). Yesterday I also released a new NR implementation release.

While I can trace the data from Sunday, I'd rather do that if it happens again while I am sure the latest updates are running.

0 ·

simonyoungtree simonyoungtree commented · Mar 01 at 04:04 PM

Unfortunately there is still a mismatch in energy usage (grid to battery) between regular VRM graph, end the DESS graph: See the columns of 12:00 and 13:00h and compare the two graphs: As you can see the first one does not report energy flowing from grid to battery and the second one stll does. (I am on the very latest beta software 3.30~10)

At least for the 12:00h column I can proof there was no AC flow through the multiplus, so certainly nothing came from the grid. Also for the 13:00h bar there is for 15 minutes on average 150 watts, which is by far not enough to cover the 1.06kwh (orange) in the graph. Even then this could also be AC power coming from the

My guess the orange part is AC-connected solar to battery (1.06kWh)

Grid view:

Consumption view

Solar:

DESS Energy Graph: In this graph "Grid to Consumption"should have been 2.20 kWh, and the text "Grid to Battery" should have been "Solar to Battery"

Perhaps all those reports about batteries getting charged from the grid are based on a wrong graph?

0 ·

1709308739959.png (22.6 KiB)

marceldb commented · Feb 26 at 08:39 AM

I found a new feature in the Remote Console to limit import and export current per phase. I set this to 16A, but when I increase the grid current limit on the Multis, it still exceeds 16A. What goes wrong (or what am I doing wrong)?

It is one Multi 48/5000 GX in a 3 phase installation. With grid meter

0 ·

1708936688988.png (35.9 KiB)

1708936707472.png (8.7 KiB)

kudos50 marceldb commented · Feb 26 at 10:30 AM

It's not just a DESS feature but more of an ESS feature. Comments and updates about this are given in the 3.30 beta 7 thread.

When it was initially released temporarily in a late 3.20 beta it worked fine for me. I do have a three phase setup so that is a little different from yours I guess.

Heaving read your post I will re-test to see if it still works :-)

In the post above from @SimonYoungtree he seems bypass the DC PV DESS challenge by limiting inverter power during the day. Not sure what disabling inverter will do to the system limiting feature and to peak shaving on AC-OUT.

0 ·

kudos50 kudos50 commented · Feb 26 at 06:41 PM

Confirmed. If inverter power is set to 0, the system limiting feature will not work. In a 3-phase setup, another unit will start charging to the DC bus but the unit that needs to invert is not allowed to therefore the battery will start charging.

0 ·

kudos50 marceldb commented · Feb 26 at 12:40 PM

Confirmed. For me this new feature still works exactly the same as it did in the late 3.20 beta. Once L1 exceeds 25A, the L1 multi will start inverting to compensate. To accomplish this, L2 will start consuming more energy from grid and starts charging to the DC bus where L1 is inverting from. This way, the penalty on the battery is fairly limited and losses are limited to AC-DC conversion losses and not so much chemical losses.

I did not continue testing this time. But last time I continued by overloading L2 which was then covered by L3 in the same way. And once I overloaded L3 as well the process started to punish the battery as a 17kW grid connection could not deliver a 21kW load :-)

Again, this is not DESS but ESS. I think @mvader (Victron Energy) mentioned in his 3.30b7 release notes that the feature was put back in, but a write up of functionality is still in the works. Maybe good to reach out to him in that thread to discuss your single Multi in a 3-phase setup use-case.

0 ·

stefan-db commented · Feb 27 at 08:50 AM

Yesterday I have modified once my prices from fixed to dynamic but the graphics don't update to the new prices. Waited first till 15h & left once passing midnight but still the same. Reason?

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ stefan-db commented · Feb 27 at 10:20 AM

You still have it switched "off". Setting it to auto should fix it.

Also noticed that you run version 3.14 of the firmware. In order to get the most out of dynamic ESS, I advice to update the firmware.
Setting the online feed to "beta release" will give most features.

1 ·

1709029086037.png (13.2 KiB)

grua Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 27 at 01:25 PM

Latest beta v3.30~7 shows wrong DESS SOC values in Remote Console:

Correct actual values are:

min SOC: 15%

Target SOC at the end of the hour: 64%

0 ·

screenshot-20240227-141807-chrome.jpg (220.0 KiB)

stefan-db stefan-db commented · Feb 27 at 10:45 AM

Update done.

Temporary putted on auto but get no reaction (can't leave in in auto as I don't have dynamic prices - just changed it to see if it is interesting to change in future).

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ stefan-db commented · Feb 27 at 11:17 AM

You can put in fixed prices as well and leave it in auto.

0 ·

stefan-db Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 27 at 04:22 PM

Set back to fixed prices.

But now similar issue like above.

Target SOC = 100% (battery is now full loaded).

I can't change this value neither the DESS min SOC%.

Result is that DESS plans to use the grid as soon sun goes down instead off using the battery. Logic as the target SOC = 100%.

I don't know how you define the target SOC but in my logic the target SOC should be calculated if off the planned (consumption - solar production) off tomorow. Based on this data you know what to can be sold.

0 ·

andrii-podanenko commented · Feb 27 at 10:41 AM

Hey @Dirk-Jan Faber (Victron Energy)

Thank you for the DESS

Could you share rough timeline when MultiRS Dual could be added to DESS?

0 ·

Andi commented · Feb 28 at 11:32 AM

Today the sun is shining, and the system is additionally drawing power from the grid into the battery. The sun can easily fully charge the battery today. I don't need electricity from the grid.

Why?

C0619ab313dc

DESS is now deactivated

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ Andi commented · Feb 28 at 01:23 PM

You are running firmware version 3.21. In order to benefit from the strategie that prevents this, please switch to the beta release feed (Console: Settings -> Firmware -> Update feed). At the moment the latest beta is 3.30~7.

1 ·

Andi Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 28 at 05:32 PM

Thanks a lot !

0 ·

stefan-db commented · Feb 28 at 01:09 PM

Timeframe yesterday first pict from beta - second from vrm

First picture : from 11 till 12h - very confusing information. I don't really know what figures are really showed here. I suppose these are the energy flows but in that case the names are totally not really clear. Positive means to grid or battery & negative from grid or from battery. Maybe "flow" would be better word then "use".

Second picture : VRM data this is correct

0 ·

1709125159865.png (19.3 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ stefan-db commented · Feb 28 at 01:28 PM

If you look at the energy graph on the third tab, you see that you had 0.54 kWh as consumption. So from that 3.17 kWh of solar, 0.54 kWh went to consumption, 1.49 kWh got stored in the battery and 1.14 kWh got sold to the grid.

0 ·

1709126846313.png (101.4 KiB)

stefan-db Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 28 at 01:36 PM

Was clear to me after thinking further :) .

The names at the graphs where confusing (i made edit to the original post).

ps : while I have your attention take once a look to solar forecast as this is often wrong seems to me something is wrong with "the irridance filter factor". Irridance value is correct but this should be corrected with how mush the filtered by clouds/snow/rain. Wrong prediticions off solar are nefast for good working DESS.

0 ·

stefan-db stefan-db commented · Feb 29 at 12:14 PM

@Dirk-Jan Faber (Victron Energy)

Dirk-Jan some more remarques for finetuning :

- Price formule : I would add a tab for the fixed grid costs or at least clearly mention in the manual. Otherwise chance is big people will forget to add this cost.

Real cost off electric = ((the formula) + (gridcost)) * tax

- Limits : Input or Output limit is defined by the gridconnection or the maximum you may have as peak. In case off charging or feed-in the limit should be (limit - actual grid power). Because now the limit is on top off the actual power.

Example : Real grid limit 3000W - Max power charging 2000W - Actual consumption from grid 1500W -> 3000 - (2000 + 1500) = 500 (fuse blows or peakcharges).

0 ·

Show more comments

dirks-1 commented · Feb 28 at 04:43 PM

I have to switch on and off DESS couple of times per day because it still makes wrong decisions. The target SOC is always wrong and if the real SOC is higher it starts to push the gap into the grid but this is not allowes by option. Also if the target SOC is higher than the real SOC it is loading from the grid even if the price is the highest at the day. So why just deciding by target soc? It need to be calculated more frequent depending on the real situation. Also why does it feed the grid if i disallow it by option? Just keep the soc as it is if the real soc is higher than the target. And never load from the grid if the target SOC is lower than the real soc but the price is very high. In that situation i had 93% and the target was 95%. No need to load from the grid.

Also i would like to have the option to share the PV load if it exceed an individual settable load peak.

Let's say i have 8kW PV, then i would like to share my load with a settable range ratio. For instance 70% percent of PV sureplus should go into the battery and 30 % into the grid. That would be good in case you use an ACthor or other electric sureplus heater, cooler or what ever. Because i could feed this before it goes to grid. If i can set rules like that the DESS would be a game changer to share PV load.

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ dirks-1 commented · Mar 01 at 07:50 AM

Assuming that you are testing on your "DSHOME" system, I see that you are running version 3.21. Please set the firmware update feed to "beta release" and update to v3.30~10 to benefit from the latest updates.
At the moment only that will resolve the issue of offsetting the differences to and from grid.

0 ·

john245 commented · Feb 28 at 07:40 PM

@Dirk-Jan Faber (Victron Energy)

Not a question specific on DESS, but in my opinion the question is related to that.

Competitors are introducing battery systems that can trade on the energy imbalance market. Zonneplan is currently going to the market with this (https://www.zonneplan.nl/thuisbatterij) and Sessy is investigating the possibilities (https://www.sessy.nl/verdienmodellen-van-een-thuisbatterij/).

Is Victron Energy currently also investigation this business model for Victron System owners?

For example the Nexus generated Euro 20,41 on February 27th.

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ john245 commented · Feb 28 at 09:06 PM

No, afaik we are not investigating that business model. And if we were, I could and would not disclose it here.

1 ·

axel-koning commented · Feb 29 at 03:27 AM

29/2/2024 I have installed DESS for 2 weeks now and its working great, but I got an error no schedule available on the 29 febr. DESS was not charging when it scheduled to do so. It was on min SOC. I checked the FAQ : Time in the Cerbo GX (v 3.14) is correct set. I put it manually on buying and it got charging. What can I do about this error?

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ axel-koning commented · Feb 29 at 01:32 PM

This was an error from our side, resulting in not filling the schedules since yesterday afternoon. This has been resolved and we've made sure that this won't happen again. At least not because of this error.

1 ·

axel-koning commented · Feb 29 at 03:35 AM

Dynamic ESS now working for 2 weeks. Its doing great but I got my first error -no schedule available-. I checked the FAQ: checked time in Cerbo GX: It is on the correct date and time 29/2. SOC is on minimum and it won't charge. My GX is on v3.14. It will manually charge when put on buying. What can I do about this ?

0 ·

sarowe commented · Feb 29 at 04:14 AM

Ich habe Version 3.30-7 aber die gleiche Fehlermeldung und verhalten heute morgen

0 ·

Andi sarowe commented · Feb 29 at 06:34 AM

Version 3.30-10
Selbe Fehlermeldung bei mir: "Dynamic ESS error code: No matching schedule available"

0 ·

ojack commented · Feb 29 at 01:45 PM

After reading about Update v3.30~10 and DESS improvements I wanted to give DESS an new chance....

But why it wants to drain the battery tomorrow. It is not planning to charge although so much PV is available that all loads could easily be supplied 24 hours if battery would be charged to 100%. Sell price is only 7ct vs buy price above 26ct so earning money could not be the plan.

0 ·

1709214016456.png (63.2 KiB)

1709214046669.png (47.2 KiB)

grua ojack commented · Feb 29 at 03:27 PM

Similar I mentioed here:

https://community.victronenergy.com/comments/265761/view.html

But I will give v3.30~10 a change. Maybe it will do better

0 ·

grua commented · Mar 01 at 05:53 AM

The current beta v3.30~10 has actually fixed the bug that PV surplus was being charged to the grid instead of being used for AC loads. This worked flawlessly in my test yesterday. Many thanks for that!

However, my current criticism is still that the target SOC is still planned to be at min-SOC at the end of the day. The plan is to sell most of the PV surplus during the day so that the battery charge level is only at min-SOC at the end of the day:

The following night, there is then no battery charge left that could be used in the hours between midnight and the start of the next PV production. As a result, energy must then be purchased at high cost during the night. (buy prices are almost always higher then sell prices in Austria)

This should definitely be changed so that there is still enough SOC left at the end of the day to get through the next night!

@Dirk-Jan Faber (Victron Energy) didn't you say some time ago that you actually wanted to make changes in this regard? Only then will DESS actually be ready for use!

Otherwise, keep up the good work!

0 ·

dess01.jpg (32.6 KiB)

dess02.jpg (36.7 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ grua commented · Mar 01 at 06:55 AM

Yes, that is indeed one of the things that we are working on. So some more patients on that is required.

0 ·

grua Dirk-Jan Faber (Victron Energy) ♦♦ commented · Mar 01 at 07:15 AM

Very nice - I'm looking forward to it! This will make DESS a really great thing!

0 ·

Show more comments

damandan commented · Mar 01 at 12:36 PM

I am having an issue with DESS where it plans to charge the battery with surplus PV energy, but then, when it actually should do so, the surplus PV energy is dumped to the grid and the battery is not charged at all.

Example:

Planned

Actual.

I had a lot more power draw this morning, but that shouldn't matter for this afternoon as there is plenty of surplus PV available right now, but that is not put into the battery.

Why is this happening?

0 ·

image.png (53.7 KiB)

1709296445167.png (76.7 KiB)

1709296516591.png (97.4 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ damandan commented · Mar 01 at 01:01 PM

With the rather flat curves of buying and selling we've seen lately and your battery costs of 0.05 €/kWh, storing the solar into the battery for later use is quite often the more expensive option. Even that feels counter intuitive sometimes.
If you want to use your own solar, my advice is to set "Can you sell energy back to the grid" to no during the winter months.

1 ·

damandan Dirk-Jan Faber (Victron Energy) ♦♦ commented · Mar 01 at 01:39 PM

Thanks for your answer Dirk-Jan. I didn't expect the storing of locally generated PV to be the culprit here.

If I am allowed to ask a follow up question here, if this is the problem, shouldn't the graphs show this in advance? It now looks like the DESS algorithm determined the costs of storing to be less then the costs of selling and then buying back, which is what gave me the impression that something is wrong here. If the graphs had shown that selling to the grid is all in all more economic, I wouldn't have doubted the calculations.

0 ·

grua damandan commented · Mar 01 at 12:57 PM

Did you use the latest beta Firmware v3.30~10 and the new ESS Assistant?

0 ·

damandan grua commented · Mar 01 at 01:41 PM

If by 'New ESS Assistant' you mean the ESS Assistant as opposed to the PV assistant then, yes, I have the ESS Assistant and the latest beta (3.30~10)

0 ·

sarowe commented · Mar 01 at 02:07 PM

Heute Nachmittag erneut die gleiche Meldung

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ sarowe commented · Mar 01 at 02:13 PM

On what site / vrm id is that?

0 ·

sarowe commented · Mar 01 at 06:12 PM

Bei mir läuft es jetzt den 3ten Tag in Folge korrekt. Glückwunsch.

Ein kleiner graphischer Fehler ist mir noch aufgefallen. Morgens wenn der Akku-Soc unter dem mindest Soc liegt, wird als erstes der Akku geladen, während die Hauslasten noch aus dem Netz versorgt wird. Das ist soweit auch richtig, allerdings werden diese Mengen als "Grid to Battery" dargestellt und nicht als "PV to Akku" . Das führt glaube ich zu Verwirrungen und einigen Beschwerden hier.

Sehr Sehr hilfreich finde ich die neue AC Begrenzung und werde sie morgen einrichten und testen.

Für mich ist das DESS jetzt soweit nutzbar.

2 Dinge wären noch "nice to have"

- eine prozentuale Verbrauchsreserve des Akkus für unerwartete Verbräuche

- Ich würde es begrüßen wenn über das DESS eins der programmierbaren Relais schaltbar wäre, zur Ansteuerung von Extra-Lasten wie die Wallbox.

Danke für die gute Arbeit

0 ·

stefan-db commented · Mar 02 at 01:22 PM

Price @14h today Belpex 59.86€

According the graf purchase price 0.39€ - sales price 0.01€

But

Purchase (0.1068*59.86+0.204+0.16)*1.06 = 7.16 -> /100 = 0.072€/KwH

Sales (0.08505*59.86) = 5.09 -> /100 = 0.051€/KwH

Or the grafics are wrong or DESS is calculating the wrong price (or I can't calculate).

0 ·

grua commented · Mar 02 at 05:47 PM

@Dirk-Jan Faber (Victron Energy) The grid setpoint in the remote console for ESS is obviously ignored when DESS is activated. I always have the grid setpoint slightly negative (-10W). So over a whole day with sufficient PV production or sufficiently filled storage, I always had well under 1kWh drawn from the grid, usually around 0.6kWh.

Since activating the DESS, this grid consumption has been significantly more than 1kWh, rather more than 1,5kWh because most of the time the DESS regulates slightly >0kW at the grid feed-in point.

Could this possibly be changed so that the configured grid setpoint is also taken into account when DESS is activated?

0 ·

grua commented · Mar 02 at 05:53 PM

v3.30~10

new ESS-assistant (updated Multiplus-II few days ago)

The SOC values in remote console DESS settings are not correct:

0 ·

screenshot-20240302-185203-chrome.jpg (219.2 KiB)

guntherb commented · Mar 03 at 09:36 AM

I recently configured DESS. I am on the latest beta v3.30. I put the price formulas, but I see two straight lines in the energy prices graph. What do I wrong?

0 ·

schermafbeelding-2024-03-01-om-181013.png (33.8 KiB)

schermafbeelding-2024-03-02-om-080255.png (91.5 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ guntherb commented · Mar 03 at 04:12 PM

A typical formula for buying is the hourly price "p" plus a fee for the provider and that multiplied by the taxes, e.g. 21% (so multiply by 1.21). So a typical buy price formula would be: '(p + 0.03) * 1.21)'
And for selling, the provider part needs to be subtracted from p (making the total you get less). E.g.: '(p - 0.03) * 1.21'.

Your formula's multiply 'p' by a small number first, that seems unlikely, but rules can be different in other countries. And sometimes providers get creative too. E.g. if your provider takes a percentage (e.g. 4%) instead of a fixed part, you would need to multiply by 1.04. In order to be sure, we'd need to know your contract details.

0 ·

guntherb Dirk-Jan Faber (Victron Energy) ♦♦ commented · Mar 03 at 08:38 PM

Thanks for your answer, but in Belgium the price formulas are different from what your are explaining. I added the contract details and the example given by the electricity provider.
The buy price has a tax of 6%. The sell price has no tax. The unit of the price formula is eurocent/KWh.
Unit price/hour = euro/MWh --> = p?

The multiplicator '0,1044' (buy) or '0,0825' (sell) is multiplied by the Belpex (euro/MWH) to end with a unit eurocent/KWh.
Hope this info helps you.

0 ·

schermafbeelding-2024-03-03-om-213301.png (294.6 KiB)

stefan-db guntherb commented · Mar 03 at 09:13 PM

Denk dat we maal 10 moeten toevoegen in ons formules om tot correcte cijfers te komen.

Nu kom bij uw formule aan 11.45 inkoop & 7.295 verkoop bij belpex index van 100.

Doch zelf met deze toevoeging krijg ik ook niet de correcte waarden in m'n grafiek.

0 ·

Show more comments

kent2ben commented · Mar 03 at 04:56 PM

Any plans for implementing the feature below ?
"Support differing transportation costs through different times of the day"

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ kent2ben commented · Mar 04 at 09:09 AM

Yes, I can confirm that is on our todo list.

0 ·

anonimoes commented · Mar 03 at 05:46 PM

Hello, i've recently installed a victron multiplus 48/5000/70 with a battery on phase 1. I have AC coupled 3 phase solar. The system is now running as an ESS en doing very well! At the moment I just have the multiplus connected with AC-in, planning to maybe convert to a 3 phase system in the future and then put everything 'behind' the multiplusses.

I am interested in converting to DESS, at least when it comes out of Beta, but maybe also earlier. I do have a question though: one of the prerequisites for using DESS is that all loads need to be behind the Multiplus. I cannot figure out why this would matter though? Could Dirk-Jan maybe comment on this? I am very interested to hear the reasoning behind this. Maybe there is already an explanation for this elsewhere but I could not find it yet, would be very happy with a referral to that post!

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ anonimoes commented · Mar 04 at 10:07 AM

No need to have all of the loads behind the Multiplus for using Dynamic ESS.

Probably the, no longer, blocking issue #1 made you think this. We had some reports on the main breaker failing in cases where some heavy loads (ev charger / heat pump) where active before the multi and DESS decided to charge the batteries. The total energy drawn caused the breaker to trip. But with the latest updates, a supported energy meter and current limits configured, you can prevent this.

2 ·

grua anonimoes commented · Mar 03 at 08:35 PM

What makes you think that? I have PV and all loads on the AC in the MP-II. DESS still works

1 ·

kudos50 anonimoes commented · Mar 04 at 08:41 AM

No need... therefore no need to wait. Go for it.

0 ·

kudos50 commented · Mar 04 at 08:19 AM

Did anything change in the logic over the weekend ? My DESS has been pretty much predictable up till now. Yesterday afternoon after the new prices came in for today it started buying (between 2pm and 3pm) with plans to release it this evening. The price gap was 7 cents which is not within 0,04 + 2 x 90% efficiency losses. Considering the 90% story single or round trip is still open that's OK.

But yesterday evening between 21-23 it tried to keep grid meter at zero which it hasn't done since I started using DESS. Using up 3%.

Between 04:00-04:30 this morning it did the same thing but as consumption was a lot higher it used another 6% until it hit low SOC.

@Dirk-Jan Faber (Victron Energy) can you have a look and help explain what caused this (c0619ab2ef52)?

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ kudos50 commented · Mar 04 at 12:55 PM

Nothing changed over the weekend. And your system also did that more often (but you may not have noticed):
- 1-3-2024: between 4AM and 6AM
- 1-3-2024: between 19PM and 21PM
- 2-3-2024: between 23 PM and 1 AM (on 3-3-2024)
- 3-3-2024: between 21 PM an 23 PM
- 4-3-2024: between 4AM and 5AM

It is a bit unexpected and it happens when both production and consumption forecasts being zero for the hour. We are planing some other changes that are likely to affect this behavior as well. So, unless there is a compelling reason not to, I think it is safe to ignore this.

0 ·

kudos50 kudos50 commented · Mar 04 at 01:35 PM

Nope, no reasons from this end. Will ignore.

I do experience the lack of forecast you are describing pretty often. Sometimes it's real and sometimes it's just a browser refresh.

Did not have an opinion on all that as buy = sell (zonneplan and all kWhs within saldering-range) means most of the forecast did not matter much due to absence of sun in winter. The forecast only needed price and system capacity to determine how fast it could charge and invert to make a profit.

Now that solar irradiance starts to make a difference again, forecast is starting to matter. Will keep an eye out. Thanks for checking and explaining.

0 ·

stefan-db commented · Mar 05 at 08:05 AM

@Dirk-Jan Faber (Victron Energy) why is the forecast SOC not updated every hour? I have the impression that also the DESS planning is based on the forecast DESS but if he isn't up to date the planning can't be correct. As you can see in below screenshot "accu naar net" volume is based on SOC 100% while this will not be like that if you to the current SOC.

0 ·

1709625585268.png (83.0 KiB)

1709625799343.png (80.6 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ stefan-db commented · Mar 05 at 08:21 AM

Recalculations are done every hour. At the moment your system (389794) seems to have Dynamic ESS switched off (instead of set to auto).

0 ·

1709626767961.png (14.1 KiB)

stefan-db Dirk-Jan Faber (Victron Energy) ♦♦ commented · Mar 05 at 10:00 AM

Ok then it is ok for DESS. But for the normal ESS the grafics is then not recalcullated?

0 ·

Dirk-Jan Faber (Victron Energy) ♦♦ stefan-db commented · Mar 05 at 01:14 PM

That is correct. The box indicates that the graphs are about Dynamic ESS. And it should not be shown if DESS has been switched off. We'll fix that.
Thanks for noticing.

0 ·

grua commented · Jan 23 at 12:41 PM

VRM Portal-ID: b827eb273733

I am not sure if the following behavior is caused by blocking issue #2:

To avoid buying at high buy prices and selling at low sell prices I had DESS on "Auto" today with selling disabled.

The plan originally created by DESS for today only had the following phases:

Grid to consumption (at night when buy prices are low)
Battery to consumption (at night when buy prices are high)
Solar to consumption
Solar to battery (with PV excess)

Grid to battery was never part of the original plan.

Positive: Never actually sold to the grid.

Negative: Charging from the grid to the battery was very frequent, although this was never part of the original plan. Especially from 08:00 - 11:00 charging from the grid to the battery took place even at the time of the highest buy prices, which is by no means acceptable. But also at all other times of solar production battery was charged by the grid. But why?

Is this the problem according to blocking issue #2?

You write in the first post "Note that the related issue, charging with expansive utility power in case of forecast deviations has been solved a few weeks ago." But this is exactly what happened to me: The battery was charged at high prices. So this problem has not yet been solved?

Will this unplanned charging from the grid be prevented in future?

Here you can see part of the original plan (from 09:00) and what DESS actually did:

-1 ·

screenshot-20240123-093129-chrome.jpg (214.1 KiB)

screenshot-20240123-134055-chrome.jpg (195.7 KiB)

grua grua commented · Jan 24 at 10:11 AM

I disabled DESS again, because also today this was the plan:

But in real it was charching from grid into battery with full power:

1 ·

screenshot-20240124-070500-chrome.jpg (169.3 KiB)

screenshot-20240124-070510-chrome.jpg (211.2 KiB)

screenshot-20240124-110513-chrome.jpg (140.2 KiB)

screenshot-20240124-110527-chrome.jpg (149.9 KiB)

screenshot-20240124-110536-chrome.jpg (192.5 KiB)

Dirk-Jan Faber (Victron Energy) ♦♦ grua commented · Jan 24 at 11:19 AM

This is again the second issue showing, where we are still working on. Once that has been solved, I'll post and update.

1 ·

sarowe Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 20 at 11:17 AM

Seit ihr euch sicher das es sich um das Blockierungsproblem handelt? Ich habe mehrmals ein ähnliches Problem bei meiner Anlage beobachtet. Vor einigen Tagen hatte ich Zeit das ganze live zu beobachten. Das DESS verwendete den PV Ertrag dazu den Akku zu laden um ihn später in der Hochpreisphase zu nutzen. Parallel wurde der Hausverbrauch aus dem Netz bedient. Dargestellt wurde die Energie allerdings als Netz zu Batterie, was eigentlich nicht korrekt ist. Damit ist das Problem für vorallem ein graphisches.

1 ·

Show more comments

gloitom grua commented · Jan 24 at 09:20 AM

Same problem here, now with v3.20~37 still the same problem.

https://community.victronenergy.com/questions/254195/dess-loading-from-grid-when-prices-are-high.html

blocking issue #2 not fixed:
"Note that the related issue, charging with expansive utility power in case of forecast deviations has been solved a few weeks ago."

0 ·