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 ·

kudos50 ojack commented · Feb 01 at 09:00 AM

I'm lost. I have read posts stating 90% for a one way transition (which is rather realistic) and also found posts stating it's 90% round trip meaning it probably needs changing as that is not realistic at all.

On top of that, I left it at the default of 90% and behaviour of DESS clearly shows it's not using a single conversion 90%. Buy and sell delta's have not been very big recently in the Netherlands but DESS only seems to start with an 8 to 9 cent delta. With battery cost set to 4 cents it has another 4 to 5 cents to clear which matches a 2 x 90% theory.

0 ·

grua kudos50 commented · Feb 01 at 10:18 AM

Here you find some efficency curves for MultiPlus II (but not for MPPT):

https://community.victronenergy.com/questions/56351/multiplus-485000-efficiency-curve.html

For my Multiplus II 48/5000 and my typical loads I calculate with 89% for charching and 93% for discharching, i.e. 83% over all, see PDF in appendix.

Wirkungsgrad Speicher Laden-Entladen an Victron Multiplus II 48-5000.pdf

0 ·

wirkungsgrad-speicher-laden-entladen-an-victron-mu.pdf (249.6 KiB)

kudos50 grua commented · Feb 01 at 01:27 PM

I think I have about the same numbers during tests I ran last summer. But the question is not so much related to the exact numbers as that varies depending on imposed limitations (I use the MPii-3000 in 3 phase and need to set 60A and 6000W to reach 83% round trip).

There a 2 questions about the 90% efficiency default for DESS buy/sell calculations.

Is it 90% round trip or 90% from AC to DC and another 90% from DC back to AC. The latest post from Dirk-Jan says 90% round-trip but that does not add up with the observed behaviour.

The other question concerns efficiency losses for MPPT. It does not make any sense to include efficiency losses for MPPT in the DESS calculations. Only battery costs. Unless you have DC loads to consider, all energy will eventually be inverted thereby defeating the purpose of including it. It's inverted either when the sun shines or a bit later when the battery unloads. Efficiency losses are the same either way.

In that sense, only 4 cents battery costs can make storing MPPT energy profitable far more often than buy/sell from grid or AC PV.

(it matches the design recommendations from Victron itself; if lots of AC loads during the day, try and mix AC PV and MPPT to cover day and night)

0 ·

kudos50 kudos50 commented · Feb 10 at 02:12 PM

@Dirk-Jan Faber (Victron Energy) If you have time, can you please comment on this thread ? Both on the 90% round trip or 90% each conversion question and on the question concerning efficiency calculations for DC PV.

0 ·

kudos50 kudos50 commented · Feb 25 at 12:07 PM

@Dirk-Jan Faber (Victron Energy) It's been a while and you guys have done some great work on the 3.30 beta. Any chance you can respond to the comments above pls concerning 90% round-trip and storing MPPT in battery instead of inverting ?

0 ·

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

I am not responding to this as this is still not closed for debate on our side. Once all of the dust settles it will be documented, including all of the tweak-able parameters.

1 ·

kudos50 Dirk-Jan Faber (Victron Energy) ♦♦ commented · Feb 26 at 03:47 PM

Fair enough. I was reading another post in this thread earlier today from someone that simply stops his inverter using node-red during the day to bypass DESS for DC-PV.

Cannot wait for the dust to settle :-)

0 ·

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 ·

danieltom martin-henning commented · Jan 23 at 12:06 PM

If I can deliver the performance of the wallbox via MQTT, is there a way to deactivate something through Node-RED, so that it does not affect the forecast analysis?

0 ·

martin-henning pim57 commented · Jan 21 at 01:54 PM

I guess one could even have the EV wallbox metering as an input to the whole algorithm. That could make it pretty much perfect. But as of now I think system is totally not usable if you run any kind of EV which easily offsets the forecast 3-fold and thus destroy the whole DESS idea in every sense. Question would be, how to define a universal input interface to supply EV metering data. MQTT usually works well over many platforms? And/or read in a separate smart meter for the wallbox if none is built into the box or the data is not available.

0 ·

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 ·

Dirk-Jan Faber (Victron Energy) ♦♦ martin-henning commented · Jan 23 at 08:18 AM

The issue relates to hourly differences as well. It will essentially put the system into self-consumption mode for the hours where that makes most sense.

0 ·

martin-henning Dirk-Jan Faber (Victron Energy) ♦♦ commented · Jan 23 at 10:05 AM

Ok, even with the grid sales features turned off, it still feeds PV into the grid instead of the battery.... THAT is strange to me.

I deactivated DESS for now. can't afford to waste PV these days :D

EDIT: I probably not only need to turn off the grid sales but additonally make the battery costs 0, right?

EDIT2: Even with battery cost 0 it feeds excess PV into the grid, hourly forecasts have NOT been met, so I consider this behaviour unexpected :)

0 ·

screenshot-2024-01-23-at-110329.png (650.0 KiB)

screenshot-2024-01-23-at-111358.png (128.6 KiB)

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 ·

sarowe sarowe commented · Jan 26 at 06:56 PM

Mein System produziert momentan in den Mittagsstunden einen gewissen Überschuss, den es dann in der Zeit mit dem höchsten Preis nutzt. Für die restliche Zeit ist die Preisdifferenz nicht groß genug um den Akku zu laden. Bei mir alles gut

1 ·

Andi sarowe commented · Jan 26 at 08:51 PM

Ich habe jetzt nochmal die Preisformel angepasst.
Vielleicht versteh ich diese ganze ess sache falsch? Aber Müsste da nicht mal geladen werden, wenn der Netzstrom günstig ist, und der Akku leer wird?

Ich verstehe es einfach nicht.

0 ·

photo-2024-01-26-21-47-25.jpg (57.1 KiB)

bildschirmfoto-vom-2024-01-26-21-54-51.png (138.0 KiB)

sarowe Andi commented · Jan 27 at 06:38 AM

Wenn du bei 23 Cent Einkaufspreis die Verluste fürs Laden und Entladen berechnest bist du bei ca 27 Cent. Angenommen du hast die Akkukosten dann bei 3 Cent kommen da schon 30 cent raus. Nach meinem Verständnis kauft das System dann nur Strom für Zeiten in denen der Strom teurer als 30 cent ist und kein pv Strom zu erwarten ist. Und aus meiner Sicht ist das auch genau richtig

1 ·

Andi sarowe commented · Jan 27 at 09:10 AM

Moin!
Wir hatten die Tage, wo so viel Wind war, Zeiten, da hat der Strom 15 cent gekostet. Da wurde auch nicht geladen. Bei 15 cent kann doch mal geladen werden?
Es war ja auch weit und breit keine Sonne zu sehen.

Ich habe 0.05€/kWh Akkukosten. Wie berechnet man das?

1 ·

sarowe Andi commented · Jan 27 at 12:34 PM

Dann liegt da das Problem. Deine Akku kosten sind sehr hoch. Du hast ja eine gewisse Abnutzung des Akkus. Die Zyklen sind ja begrenzt. Ich schwanke irgendwo zwischen 2-3 cent

1 ·

Andi sarowe commented · Jan 27 at 03:15 PM

Ah ok, ich danke dir für den Hinweis!

Ich habe jetzt nochmal nachgerechnet.

4091,80€ / 6000zyklen * 28,8kWh = 0,0237 €.

Wie komm ich denn auf 0,05...

Mal gespannt ob sich jetzt was ändert.

1 ·

grua Andi commented · Jan 27 at 09:25 PM

Ich bin ja nach wie vor unschlüssig, ob die Angabe von Batteriekosten überhaupt Sinn macht. Der Speicher ist ja im Falle eines Eigenheims bereits zur Gänze bezahlt, es fallen dann keine weiteren Kosten dafür an. Dass jemand für einen Speicher Kredit aufnimmt schließe ich jetzt einfach mal aus.

Der worst case wäre, denn Speicher zu kaufen und ins Regal zu legen, niemals zu nutzen.

Der best case wäre ihn so viel wie möglich zu nutzen und 6000 Zyklen zu erreichen.

Die Realität liegt irgendwo dazwischen.

Um die 6000 theoretisch möglichen Zyklen auch tatsächlich zu erreichen müsste man bei ca. 250 Vollladungen im Jahr (was eh hoch gegriffen ist) den Speicher 24 Jahre lang nutzen. Nach 10 oder spätestens 15 Jahren ist der aber gealtert. Real sind also eher 2000 oder 3000 Zyklen.

Mit 2 bis 3k Zyklen kommen aber derart hohe Batteriekosten raus, die keinen Sinn machen im DESS.

Daher warum nicht 0 als Batteriekosten eingeben und das so betrachten, dass man den Speicher ohnehin schon bezahlt hat und ihn daher so viel als möglich nutzen möchte um ihn nicht zu wenig genutzt "altern" zu lassen?

1 ·

Andi grua commented · Jan 28 at 01:39 AM

Hört sich logisch an.
Und was hast du an der Stelle eingetragen?
Bist du auch bei Tibber/Awatar und klappt das bei dir mit dem nachladen bei günstigen Preisen?

0 ·

Show more comments