Dynamische Einspeisevergütung #219
Replies: 9 comments 7 replies
-
|
hmm ... würde es eher direkt aufnehmen, als über externen Sensor... (zu viele mögliche Fehlerquellen für weitere Nutzer ... ;-) ) daher die Frage - kommen die dynamischen Einspeisepreise hier auch von stromligning oder ähnliches? heisst ebenso über api einbindbar? Hast Du Bespiele / API Doku dafür? @LordMike : maybe you can also support here or have maybe (meanwhile) the same requirement |
Beta Was this translation helpful? Give feedback.
-
|
Im unsure what the question really is - but if this guy has electricity at nordpool prices without any extra transit fees - then he’s extremely lucky. .. or maybe it’s export pricing which surely is spot only. Is this to plan around charging from PV at expensive prices, to allow PV export to occur at those high prices ? |
Beta Was this translation helpful? Give feedback.
-
|
my understanding:
and for that it could be similiar integrated as the "normal" grid price sources - if the kind of API source is similiar ... but finally - @Maergsche can clarify our understanding ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I am not aware of an API (but that would also be very specific to the provider, wouldn't it?). The aim is to improve the optimiser's efficiency. Currently, we overrides eos_connect in order to charge the battery via PV at a later point in the day, as we receive a higher feed-in tariff in the morning and evening than at midday. It doesn't really matter where the current market price without taxes comes from... there must be an configuration field to add the additional costs to it. (The price doesn't have to be 100% accurate; anything would be better than having a fixed price at the moment. In EVCC, I calculate the price as described above. Perhaps the price for the feed-in tariff could also be used from EVCC? It seems that the current market price can also be obtained from stromligning (without taxes and such), is that right? Thank you for all your efforts. |
Beta Was this translation helpful? Give feedback.
-
|
Ah. I see. That’s a fun addition. I have no comments on what might be best. In DK we correctly enough get the market spot price for the energy, plus any provider-specific charges. My own provider takes 0.01DKK per kWh, but otherwise just give spot prices raw.
I’ve opted not to focus on these prices at all as the gains are likely small (without having calculated on it).
Mike.
Sent from Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Maergsche ***@***.***>
Sent: Monday, March 9, 2026 10:33:35 AM
To: ohAnd/EOS_connect ***@***.***>
Cc: Michael Bisbjerg ***@***.***>; Mention ***@***.***>
Subject: Re: [ohAnd/EOS_connect] Dynamische Einspeisevergütung (Discussion #219)
Hello,
That's correct, currently I can only enter a fixed price for the feed-in tariff in eos_connect. The aim is to enter dynamic electricity prices for the feed-in tariff. My friend feeds electricity into the grid via Vindstød. You can find out how the price is calculated here ( https://www.vindstoed.dk/tilmelding-solcelle ). As I understand it, it is basically the market price (excluding taxes) minus transport costs/fees an so on. (In other words: market price - fixed amount)
I am not aware of an API (but that would also be very specific to the provider, wouldn't it?).
The aim is to improve the optimiser's efficiency. Currently, we overrides eos_connect in order to charge the battery via PV at a later point in the day, as we receive a higher feed-in tariff in the morning and evening than at midday.
It doesn't really matter where the current market price without taxes comes from... there must be an configuration field to add the additional costs to it. (The price doesn't have to be 100% accurate; anything would be better than having a fixed price at the moment.
In EVCC, I calculate the price as described above. Perhaps the price for the feed-in tariff could also be used from EVCC?
It seems that the current market price can also be obtained from stromligning (without taxes and such), is that right?
https://stromligning.dk/elpriser?moms=nej&elafgift=nej&transmission=nej&visning=barsV2&omraade=DK1&pris-oploesning=15m&prognose=nej#top )
Thank you for all your efforts.
—
Reply to this email directly, view it on GitHub<#219 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAH2YJ2X4OXXDCRZWCXFJR34P2FW7AVCNFSM6AAAAACWEGK37OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBVGA3DMOA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
It's definitely worth it... The price per kWh was even better this morning. Today, 13.4 kWh have already been fed into the grid, generating 8.54 DKK... The battery (10kWh) started charging at around 11 a.m... It just adds up day by day. To do this, control is currently being transferred to a different script, which checks how many kWh can still fit into the electric car and the house battery. An offset is added to this. Then, with the help of the PV forecast, the expected surplus is calculated and halved... if the value falls below zero, the battery starts to charge. But that distracts from the main topic of being able to configure dynamic feed-in prices in EOS Connect. He pays an additional fee of 0.0354 DKK |
Beta Was this translation helpful? Give feedback.
-
|
Additional consideration. In Denmark we use “summation measurers” (translation unknown) which sum up the in/out energy used on three phases. Each 15 minutes (now, earlier 1h) the sums were tallied and subtracted.
This means that within one 15 minute interval, you may freely use the grid as a battery storage. If you output 1 kWh and pull 1 kWh within the Sam e15m window, it costs nothing.
This also means you can do peak usage, if you’re emitting a lot of power, from the grid at basically no cost. Example: you’re producing PV enough to charge, and also emit some power to the grid. If you suddenly need 2x power - you should /not/ use your battery. You should use the grid exclusively. When your peak usage drops again, maybe a few minutes later, you can output surplus again. It is probably likely you’ll output more to the grid than you take from it, and this will cost nothing - if you use your battery you’re straining that instead.
(Hope it makes sense)
I’ll try to model with grid pricing in some of my own calculations to see what it could give. Thanks for pointing me in that direction :)
Mike.
Sent from Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Maergsche ***@***.***>
Sent: Monday, March 9, 2026 3:51:37 PM
To: ohAnd/EOS_connect ***@***.***>
Cc: Michael Bisbjerg ***@***.***>; Mention ***@***.***>
Subject: Re: [ohAnd/EOS_connect] Dynamische Einspeisevergütung (Discussion #219)
It's definitely worth it... The price per kWh was even better this morning. Today, 13.4 kWh have already been fed into the grid, generating 8.54 DKK... The battery (10kWh) started charging at around 11 a.m... It just adds up day by day.
To do this, control is currently being transferred to a different script, which checks how many kWh can still fit into the electric car and the house battery. An offset is added to this. Then, with the help of the PV forecast, the expected surplus is calculated and halved... if the value falls below zero, the battery starts to charge. But that distracts from the main topic of being able to configure dynamic feed-in prices in EOS Connect.
He pays an additional fee of 0.0354 DD
—
Reply to this email directly, view it on GitHub<#219 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAH2YJ2TFTXXDGFDN5E4VUL4P3K7TAVCNFSM6AAAAACWEGK37OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMBVGQZDKNQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hallo @ohAnd, wird nun noch was benötigt? |
Beta Was this translation helpful? Give feedback.
-
|
Wenn du schon was "gebastelt" hast gerne einen PR auf dev... dann schaue ich mir das an. Sonst fehlt mit hier noch der genaue Weg ...
Ziel wäre in kurz -> feedin Preis bekommt als Interface in etwa das gleiche wie der Grid Preis -> Interface welches alle x Minuten ein Update von extern holt die Zusatzparameter verrechnet und als Array "parkt", um dieses dann mit jedem Optimierungzyklus dem Optimizer mitzugeben, anstelle des statisches arrays von 48 x der gleiche FeedIn-Preis Wenn wir die Story soweit rund haben, könnte ich was probieren ... |
Beta Was this translation helpful? Give feedback.
-
|
Börsenstrompreise für Feed-In sind die gleichen Strompreise wie die Nettopreise von EPEX. Für meinen Fall würde ich die Elpris API nutzen, da die Preise auch bereits in Dänischen Kronen vorliegen. Konfiguriert werden muss die Zone DK1 bzw DK2 und zusätzlich würde man ein statisches Konfigurationsfeld Eine API mit 15 Min Takt, konnte ich nicht ausfindig machen. Datein für den nächsten Tag liegen ab ca. 13 Uhr vor (sonst kommt von der API ein 404). Zur Frage wie Standardisierbar es für den Gebrauch in Europa wäre. Dazu mußte man eine APi haben die für Europa die netto EPEX Preise je nach Preiszone zurück gibt und ggf, noch einen Umrechnungsfaktor für die Währung mitberücksichtigen (sofern EOS-Connect das nicht schon intern mitbringt). |
Beta Was this translation helpful? Give feedback.
-
|
Hi, ich würde mich zwecks Direktvermarktung auch dafür interessieren. Wie wäre es mit einem einfachen 96-Slot-Array, das man dann mit Währungseinheit/kwh Werten füllen kann |
Beta Was this translation helpful? Give feedback.
-
|
Sorry war noch nicht fertig 😅 Das Array per API füllen, so hätte ich gedacht. Und dann die Optimierer nutzen, überschüssige Energie aus der Batterie möglichst kosteneffizient zu entladen. Nur gibt es von den Optimierern überhaupt schon die Möglichkeit, die Batterie per Zwang (ins Netz) zu entladen? Meine Batterie macht das zwar per Befehl aber halt nur händisch... |
Beta Was this translation helpful? Give feedback.
-
|
hab mal versucht den ersten Teil reinzubringen für die ersten Tests - schaut mal ob es in die richtige Richtung geht ... |
Beta Was this translation helpful? Give feedback.
-
|
Sehr geil:
Was auffällt sind die teils starken drops vom SOC. Plant der optimizer da erzwungenes Entladen ins Netz? Denn der load alleine reicht dazu nicht. |
Beta Was this translation helpful? Give feedback.
-
|
Vorher:
Nachher:
|
Beta Was this translation helpful? Give feedback.
-
|
Was hast du / hat sich zwischen den beiden Screenshots geändert? Also was hast du getan um zu dem Ergebnis zu kommen? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hallo,
vorab, ich Frage für einen Freund der in DK wohnt. Dort bekommt er für den eingespeisten Strom keinen festen Betrag wie hier aktuell es noch in Deutschland ist, sondern erhält den Börsenstrompreis abzüglich Transportkosten.
Kann ich das irgendwie in der Konfiguration hinterlegen, oder irgendwie anders konfigurieren (z.B. durch angeben eines HA Sensors, der den Preis beinhaltet) ?!?
PS: Seinen Strompreis konnte ich via stromliging (token: n1_c/norlys_flexel) perfekt hinterlegen!
Beste Grüße aus dem Norden
Marc
Beta Was this translation helpful? Give feedback.
All reactions