article

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

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

CLOSED - Dynamic ESS on Beta VRM - part 2

Update 2023-11-28: This article has been closed for further comments. The follow up article can be found here.

UPDATE 2023-11-03: Venus OS version 3.20~17 (latest candidate release) offers several 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.
  • Fix bug that limited solar chargers in relation to the target SOC. Rather than limiting, get there early, and power loads or feed excess into the grid.
  • Implement restrictions for the German market:
    • Two modes are supported: Disallow export from battery to grid, and Disallow import from grid to battery.
    • When converting from DC to grid is disallowed, export-power is limited to local consumption, plus DC-coupled PV (which is green).
    • When converting from grid to DC is disallowed, import-power is limited to AC-coupled PV.

Controls for setting the restrictions can be found under the Dynamic ESS battery settings.
1699115293410.png
For Node-RED users, you can read how to configure it here.

First of all thanks for the overwhelming responses to the first beta release of Dynamic ESS on VRM. As the previous post on community became very large I’ve closed that one and started this new one, containing what we have done after the initial deploy on beta VRM and our plans and focus for the coming weeks.

We got quite a lot of questions/remarks on why the system is sometimes (dis)charging on the grid. 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. We’ve done several long running simulations and in the long run this proved to be the most cost-effective way. But we are still looking on ways to improving this.

Here is an update of improvements made in the past weeks:

  • Removed the separate Dynamic ESS SOC from the settings, as it seemed to be an unclear feature to many beta users and does not work well.
  • Improved the calculation of the figures showing what you would’ve made without Dynamic ESS, so it is a fairer comparison
  • Improved the configurator, so editing data in one step doesn’t force you to undergo all steps
  • Improved the energy graphs on the dashboard
  • Improved the overview of the configuration settings, so you can see you configuration in one glance
  • Improved the configurator, to not show bidding zones when the country selected doesn’t have those
  • Pass the battery capacity entered in DESS to the GX device

To be completed before official release:

  • Allow you to see past and future data (plan for tomorrow) for Dynamic ESS on the dashboard
  • Inform in case there is a problem with generating Dynamic ESS schedules, and why this is happening (unable to fetch prices from entseo for example).
  • Improve the UI and wording around the amounts earned / costs with and without dynamic ESS
  • Add a setting to disable selling from battery to the grid for your installation; as required for Germany as well as other areas.
  • Improve validation on the input fields in the configuration
  • Add a link in the configurator to an excel that helps you calculate your battery costs
  • Add site specific currencies to Dynamic ESS

With above, we expect to have it ready for first official version.

Many plans are already being made for what is next, here is an overview.

  • Incorporate battery efficiency losses into the algorithm
  • Support differing transportation costs through different times of the day
  • Allow to specify a feed-in time range to allow for selling from the battery to the grid at set times
  • Show the state of Dynamic ESS and any potential error codes more prominent on the dashboard
  • Simulate what an installation would’ve earned in a week’s time with and without Dynamic ESS for new users
  • Allow copy-pasting formulas so configuration for multiple installations becomes easier

The manual will always cary the most up to date instruction and also contains a FAQ, so make sure to check that too, before posting a new question / remark.

For those of you who missed the original post, and wonder what this is all about. 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

ESSdynamic essbeta
1699115293410.png (75.4 KiB)
149 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.

stephanoffice avatar image stephanoffice commented ·

Dear Victron,

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


Greetings



4 Likes 4 ·
heinvdb avatar image heinvdb stephanoffice commented ·

@Dirk-Jan Faber


In my opinion, the system needs 3 extra parameters.


1) An adjustable safety buffer on the low side of the battery. If there is less sun or more consumption, in a given hour than predicted, the system does not have to reach its target SOC. It could use its buffer to continue with its predicted algorithm and can correct this later when the prices are lower.


2) An adjustable buffer on the high side of the battery. If there is more sun than predicted or less consumption than predicted, the system can use this buffer to fill so that it can correct later on when sell prices are higher.


3) An adjustable time interval (every week, 2 weeks or once a month,...) at which the system charges the battery to 100% at low prices or a lot of sunshine. Then the SOC can be reset correctly and the battery cells can balance again.

Hopefully the Victron-team can modify the DESS system in this way to overcome some limitations and thus create a better DESS system.


Kind regards,

Hein


                  
2 Likes 2 ·
koll avatar image koll heinvdb commented ·

Hello!


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

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

At the moment that is not possible yet. We'll put it on our todo list. Out of interest, which country and provider is this?

1 Like 1 ·
Jakub Fiala avatar image Jakub Fiala commented ·

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

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

For now that can only be done using Node-RED implementation (which can be run while using the VRM beta version at the same time); just make sure not to overwrite the schedule.

This example should help in achieving your goal, where some scheduling is done based on the price being above or below the average day price: https://github.com/victronenergy/dynamic-ess/blob/faberd/extra-example/examples/nodered-ui-with-vrm-dess-with-average-price-switching.json

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

Hi Dirk,

I will check it, thank you for reply. Jakub

0 Likes 0 ·
larsea-dk avatar image larsea-dk Dirk-Jan Faber (Victron Energy) ♦ commented ·
Hi Dirk


I have once tried the NodeRed DESS, but it messed up with my own NodeRed and I deactivated it. So I’m a bit afraid to test your Beta version. Should be on a test GX unit then.

My own do 2things:

1) shut off production to grid (feedin) if price is below an adjustable set value. So it imports the Nordpool prices.

2) constantly adjust or tweek the grid-setpoint to control the maximum charge to my battery in case of high solar energy and charge is depending on my present SOC. This gives me a much better balanced battery and do not add unnecessary amps to my battery. Also minimize the amp’s to battery at high SOC. My dual-phase system then simply feedin to grid instead. My SOC do though seems to drift over time if nit charged full now and then, but that’s another story.

Could you please advice if your upgrade with the new DESS will mess with my NodeRed coding?

Really looks promising the DESS and maybe you also work on a solution where we can input a max battery charge a bit similar to what I have done. I’m a rookie on NodeRed, so you can surely do it in a much greater way.

0 Likes 0 ·
g8n avatar image g8n commented ·

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

1 Like 1 ·
tuxedo0801 avatar image tuxedo0801 g8n commented ·

Same issue here: DESS charges the battery due to low SOC and high demand and low buy-price...but after demand drops, it discharges the battery into the grid... I bought for ~30cent and sold for ~7cent ... So evene if I where allowed (in germany) to sell from battery, this makes not that much sense.

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

That option is not there yet. It is still under "To be completed before official release".

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

My system is also planning to discharge the battery in order to sell to the grid although I have set net feed-in to zero in the (ordinary) ESS settings. Fortunately, it doesn’t come to this feed-in in reality. So the forecast is always inaccurate.

Therefore, I wonder why the dynamic ESS forecast doesn’t take into account my (ordinary) ESS settings in the remote console.

0 Likes 0 ·
vestax-1 avatar image vestax-1 g8n commented ·

Same issue from my side (Germany based as well). In this config it is unfortunately a cash destruction machine :-(

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

@G8N , @tuxedo0801 and @Vestax-1: Wondering if you are able to provide some feedback, now that the restrictions can be configured (mainly for the German market). Can you test if it works as you expected?

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

@Dirk-Jan Faber it seems to be fixed. I've just a small Solar (10KWp) and batterie (16KWh) environment, but I’ve not seen this behavior (discharge battery to the grid) after activating the discharge restrictions again. Thaks for the great Support.

PS: Just the challenge that the system feed Solar energy to the grid before SOC 100% have been reached is now still open. But I know that probably a bit difficult to solve and related to the SoC target level calculation.

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

Testing right now... (just updated to 3.2.0~18). For the moment, I don't see any battery-to-grid feedin. Need to test longer. BUT:

1699474298353.png


The day is over and system consumes most of the energy from the grid instead of just using the battery. If you check the grid price...

1699474488317.png

It's at 0,27€/kWh... but will drop to 0,24 ... Can't see why DESS is right now using the grid and not in 2hrs when price is low?!

Will keep the DESS function for tonight and check tomorrow if it makes sense to stick to DESS or go back no normal ESS and control by hand.

0 Likes 0 ·
1699474298353.png (102.6 KiB)
1699474488317.png (52.7 KiB)
tuxedo0801 avatar image tuxedo0801 tuxedo0801 commented ·

@Dirk-Jan Faber DESS has stil weird behavior. Feedin totally stopped. That's fine now. But grid-usage is not explainable...
Look at this:
1699516246591.png

Battery SOC is ~41% (30kWh battery). What's the idea behind "feed solar to grid" if battery is not even half full, grid buy price is kind of low and solar energy has to be feed to grid instead of charging the battery" ??? Especially if you look at the sell-price... Compared to the buy-price, it's in any case better/cheaper to put all (or at least most) of the solar energy into the battery and not to the grid.

I doubt that people will use DESS if it's not explainable why the system behaves like this.

3 Likes 3 ·
1699516246591.png (64.5 KiB)
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦ tuxedo0801 commented ·

As mentioned in the manual we currently 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.

That being said, putting excess solar into the grid at the wrong moment is indeed not ideal. Now that we are quite sure that the restrictions work, we will add the ability to set them on schedule level as well. That should prevent excess solar to be fed into the grid and put it into the battery instead.

Do also note that the system performs best during summer and winter time. During the transition (autumn and spring) results are less ideal.

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

Solar surplus into the battery instead of into the grid is the first important step. In addition, it should also be possible to use more of the battery in hours with a high purchase price than was planned according to the forecast, as long as the SoC is high enough. This together would address most of the weaknesses in the solar and consumption forecasts.

1 Like 1 ·
gdhondt avatar image gdhondt commented ·

Hi Dirk-Jan,


My DESS give a alarm. Dynamic ESS battery level unknown

img-5008.png

img-5009.png

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



1 Like 1 ·
img-5008.png (227.5 KiB)
img-5009.png (649.4 KiB)
kudos50 avatar image kudos50 gdhondt commented ·

Same here. Whereas Cerbo says all is good. Glitch in the matrix. Seems to have resolved itself.

2 Likes 2 ·
Noel avatar image Noel kudos50 commented ·

Same here...

1 Like 1 ·
kudos50 avatar image kudos50 commented ·

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

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

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

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

1 Like 1 ·
hominidae avatar image hominidae commented ·

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

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

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

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

Thanks for the remark. Though making it all little more complex to implement, we'll make sure to add that option too.

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

@Hominidae : Now that the restrictions can be configured (mainly for the German market), can you test if it works as you expect and provide some feedback?

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

@Dirk-Jan Faber yes, I've seen it - thank you very much for implementing it.

I don't have a variable tariff atm and to add some more complexity: I actually have two tariffs, one for household loads and the other for my Heatpumps & EVs.

Though the household tariff will be changed to tibber in the future, hopefully starting from January '24 onwards.

0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦ hominidae commented ·
Thanks for the response. Support for multiple tariffs will probably take a while longer to be implemented.


Meanwhile I'll try to find some other users that can already test and provide feedback then.
0 Likes 0 ·
hominidae avatar image hominidae Dirk-Jan Faber (Victron Energy) ♦ commented ·

@Dirk-Jan Faber (Victron Energy) thanks for your reply.

I can confirm, that for my household tariff, I'll be on tibber starting from febuary 2024.

The tariff for heatpumps and BEVs is a fixed one anyway.

The way I optimise this is with node-red implementing the following rules:

  • if BATT-SoC is below 50% the load from heatpumps is excempted from battery use/ESS by increasing the grid-setpoint to the power currently consumed by the heatpumps.
  • if BEVs are set to charge on direct mode (non PV), their loads always get excempted from the battery use/ESS

...this way PV usage gets priority for charging the batteries and for household consumption.
Which in my situation with a fixed tariff is always known to be the most expensive one.

With Dynamic ESS the same rules should apply, but the current costs (or the difference of the two) should be taken into account into the decision if charging/discharging the batteries is a good measure.

This is an example what it currently looks like (both, one heatpump and one BEV are active loads, very weak solar intake, SOC below 50%)

1700913658156.png

TLDR;

My setup has two tariffs, one for heatpump & BEVs and one for household/normal loads.

The internal wiring is set-up in the way, that PV self-consumption always gets priority and that it is possible to self consume for household and heatpumps/BEV loads. This is a cascading setup, very popular here in Germany.

There is one Meter at the Grid-Point (Z1) and another Meter (Z2) at the point where only household loads (and PV + Batteries) are connected.

Energy for household is measured with Z2, while energy for heatpumps/BEVs is measured as the difference from Z1 and Z2 (Z1 minus Z2).

Hence I placed one EM540 as the grid meter (Z1, for ESS) and added another EM540 at the connection of Z2 (other AC loads - in order to fetch its data via the GX).

I then use node-red to calculate the different loads and energies, as shown in the diagram and use the data to control the grid-setpoint.

Here is an example where the excess solar (after self consumption for household loads) gets charged into the batteries, while the BEV gets charged from grid:

1700914696058.png

..I am still working on a way to smooth the values when there are fast changes in the loads, though ;-) But it works pretty good for now.

0 Likes 0 ·
1700913658156.png (363.6 KiB)
1700914696058.png (47.6 KiB)
Robert Zeugswetter avatar image Robert Zeugswetter commented ·

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

0 Likes 0 ·
tdupas avatar image tdupas Robert Zeugswetter commented ·

and perhaps a follow-up question. I see that in the latest venus os (3.11) the setting is still there and can be altered, but seems to get reset back the next push. Would have liked to still use that feature, to have some deliberate "buffer" between the minimum SOC only to be used at power outage and the "minimum SOC as seen by ESS and used for calculations".
So correct that it's "really gone", or could make a reappearance for users who want it?

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

It could return in the future. But we don't want to have an unclear setting that does not function properly.
While you can still read from and write to it from Node-RED, it will be ignored by the dbus-systemcalc proces.
If you want an extra buffer, you can increase the normal minimum SOC. In case of power outage, that is still available.

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

I hope that this will come back as working function. In my opinion the fact that it is not clear and not working should not justify the removal. Instead the functionality should be explained and the function fixed. Currently for me not a high priority. But for sure I will see the advantages for users with a large battery pack. I have plans to extend my battery pack Q1 2024.

0 Likes 0 ·
kudos50 avatar image kudos50 commented ·

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

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

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

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


0 Likes 0 ·
Dirk-Jan Faber (Victron Energy) avatar image Dirk-Jan Faber (Victron Energy) ♦ kudos50 commented ·
As soon as all the dbus paths are solid, we'll add them to dbus_modbustcp. Meanwhile, you can use the Node-RED custom output node to write to the dbus service `com.victronenergy.system` and path(s) under `/DynamicESS`.


Incorporating EV charging plans are being made, but that will get the attention it deserves after the official release of dynamic ESS on VRM.

2 Likes 2 ·
kudos50 avatar image kudos50 Dirk-Jan Faber (Victron Energy) ♦ commented ·

Yeah I can imagine that being a huge challenge. In the mean time, does a manual switch to off and back to auto indeed prevent the statistics from that period from being included in the forecast ? Probably not, but a guy can hope.....

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

The Node-RED custom output node towards system did not work. I can see the path you are referring to:

com.victronenergy.system/DynamicEss/Active

But writing a 0 to try and switch DESS to off does not seem to work. Instead I used:

com.victronenergy.settings/Settings/DynamicEss/Mode

Works as expected. 0 for off and 1 for auto.

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

You are correct. The list of different modes can also be found here: https://github.com/victronenergy/dynamic-ess/blob/main/VRM-BETA.md#check-which-version-is-running.

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

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

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

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

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

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

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

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



0 Likes 0 ·
kudos50 avatar image kudos50 commented ·

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

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

0 Likes 0 ·
john245 avatar image john245 kudos50 commented ·

@kudos50 I have this issue for weeks.

1 Like 1 ·
kudos50 avatar image kudos50 kudos50 commented ·

Not sure anyone is still experiencing this but for me nothing has changed since the last post. First I thought it might just be me making changes to the config here and there. Or too much EV charging that hopelessly breaks forecasts.

But it's not. Today, again the whole day no soc forecast in the graph and no energy graph. And when the energy graph is available it happens pretty often that there is a gap as mentioned earlier. A gap that usually resolves itself before the hour has passed bringing consumption numbers back inline with energy.

On a truly positive note: I think it's just the graphs. The decisions DESS has made have been irrational only once or twice. I did put in higher numbers for battery costs to compensate for the inherent energy losses in a 48v system as well as the actual costs of the battery system. As mentioned in "what's next" it would be better to incorporate that separately as cost of losses is relative to price whereas battery costs is not.

0 Likes 0 ·
kudos50 avatar image kudos50 kudos50 commented ·

Not sure if @Dirk-Jan Faber fixed the soc forecast in VRM but for me it started working again about 1h after downgrading to 3.12. Maybe just a coincidence...

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

That is indeed just a coincidence. It was fixed today.

2 Likes 2 ·
Show more comments

Article

Contributors

dfaber contributed to this article