Ich versuch mich grad einzulesen ins Thema dymische Strompreise verwenden mittels kleiner billiger gadgets.
Dazu müßte auch gehören, daß einem die Belastung aller übergeordneten Netzebenen mitgeteilt wird. Da kocht aber jeder sein eigenes Süppchen, diese Information fehlt und das Format der Daten ist bei jedem Stromverkäufer anders (falls überhaupt abrufbar).
Der Bereitsteller des notwendigen Datenpakets muss, denke ich, Aggregator der notwendigen Steuerinformation sein. Außerdem muss es eine vereinheitlichte Antwortstruktur geben, die man beim jeweiligen Stromverkäufer abrufen können muss. Alternativ kann der das an eine zentrale Stelle abgeben, z.B. epex oder entso-e.
Das Format muss medienübergreifend funktionieren, also Informationen auch z.B. für Gas, Wasser, Öl, Holzstücke, Wasserstoff oder sonstwelche Energieträger umfassen können.
Ich stelle mir das ungefähr so vor: SPOT.json.txt (2,4 KB)
Das müsste eine EU-weite Vorgabe werden, aber wie kriegt man das hin?
Eine Idee, die ich gehört habe, wäre das der regionale Netzanbieter auch eine dynamisches Netzentgeld berechnen könnte. Das wäre in Ergänzung zum dynamischen Strompreis der an der zentralen Energiebörse gebildet wird.
Damit würde sich das Modell vereinfachen, so dass der Netzanbieter nur jeweils seine höhere Versorgungsebene betrachten müsste.
Aktuell stelle ich mir allerdings vor dass man noch nicht soweit ist. Sicherlich wäre es gut, wenn man ein einheitliches API hat und wenn man vielleicht auch einen zentralen Server hat wo diese Information abzurufen ist. Alles andere wäre unübersichtlicher und auch wenig ökonomisch.
Ich frage mich warum das Format medienübergreifend sein sollte. Es geht doch hier nur um Strom oder warum sollte man auch andere Energieträger berücksichtigen?
Ich denke, ein Standard setzt sich eher durch, wenn der universell ist, also nicht nur eine Nische bedient.
Vielleicht gibts einmal variable Tarife für andere Stoffe, da kann das gleich übernommen werden. Das könnte zuerst bei Wasserstoff und Erdgas oder Biogas interessant werden, vielleicht gleich regional. Oder innerhalb einer Fabrik, z.B. bei Hydrauliköl, Druckluft oder Grundstoffen. Mit einem universellen Datenformat ist das dann leicht.
Stell dir z.B. vor, ein Betriebsteil fragt sowas an:
Anfrage:
"https://apis.fabrik.local/json?tariff=braunkohle&1000ton"
Da ist dann gleich der Bedarf in der Anfrage mit drin
Ich bin in der Finanzbranche tätig, da gibt es den Börsenhandel. Der lebt auch davon das Produkte standardisiert werden und damit als austauschbar Güter gehandelt werden.
Zwischen Strom und den meisten anderen Gütern gibt es den Unterschied, das Strom nicht (noch nicht?) so gut speicherbar ist aber zu jeder Zeit Angebot und Nachfrage ausgeglichen sein muss damit das Stromnetz stabil ist. Das ist ja auch der Grund warum Strom im Day-Ahead Markt pro 1/4h gehandelt wird und das gleiche Produkt unterschiedliche Preise besitzt.
Das ist bei den anderen Gütern in der Regel nicht der Fall. Z.B. gibt es bei Fonds nur einen Bewertungspreis pro Tag. Bei Aktien, gibt es über den Tag verschiedene Preise, die richten sich aber nach Angebot und Nachfrage, die nicht ausgeglichen werden müssen.
Nun ja, grundsätzlich kann man all diese Güter mit Wertpapierkennnummern oder ISIN versehen und an der Börse handeln. Da gibt es auch eine ganze Menge Webportale und APIs.
Eine Frage, wäre was das API leisten soll? Geht es um eine seltene Abfrage (täglich, oder alle 1/4h) oder um laufende Kurse und viele Produkte.
Allerdings verkaufen die Börse solche Marktpreise meist gegen teures Geld und geben diese nur Banken per direkter Netzanbindung heraus. Da wird schon einiges an Aufwand betrieben. Auf der anderen Seite hüten die Banken diese Daten auch wiederum denn wer schneller darauf reagiert kann seinen Gewinn maximieren. Das ist im Energiehandel nicht anders.
Ich finde es an sich großartig, das man über PV-Anlagen als Privatperson "dezentral" an der Energiewende teilhaben kann. Allerdings gibt es durchaus Bestrebungen, die Regularien und Konditionen für kleine Anlagen zu erschweren. Man muss nur einmal schauen, welche Interessensgruppen im Markt vertreten sind. Privatpersonen haben meist nicht die größte Lobby.
Börse ist b2b, das hier ist die notwendige Standardisierung b2c.
Man kann es aktuell noch damit vergleichen, daß dein Bankmensch tschechisch redet und du deutsch, und gehst zum nächsten redet der französisch. Alle verwenden Zahlen und buchstaben und Sprache aber es bringt dir nur mit Aufwand was.
Um meinen Boiler zum besten Stundenpreis einzuschalten oder meinen Überschuss zum besten Stundenpreis einzuspeisen brauch ich die Information 1x alle 24h nach der Auktion für die nächsten 24h. Will ich Regelenergie verkaufen brauch ich das alle paar minuten. Das Datenpaket muss also aussagekräftig sein und kompakt. Einfache Stellglieder, die sich diese Daten holen, können (sollen! Nur dann verbreitet sichs schnell) durchaus billig sein mit wenig Rechenleistung. Beispiel funksteckdose.
Die Definition der Schnittstelle sehe ich weniger schwierig, das ist Fleissarbeit und den Vorschlag kann man gut aufnehmen. JSON oder XML via Rest sind gute Optionen.
b2c ist genau die Schwierigkeit. Wo ist die Geschäftsidee für das Business? Ohne die Businessseite wird man das Interesse der Firmen nicht wecken und die Datenanbindung nicht bekommen.
Aktuell habe ich eher den Eindruck das die VNB mit sich selber beschäftigt sind und auch die Politik nicht an einer besonders schnellen und dezentralen Umsetzung der Treiber ist. Vielleicht kann man über Medien und Wissenschafter ein Bewegung aufbauen, die solch eine Entwicklung möglich macht.
Eigentlich müssten die Stromhändler (tibber, awattar usw. wie auch Regelenergie) und die Verteilnetzbetreiber daran interessiert sein. Stromhändler, weil die massenhafte Verbreitung eines simplen billigen gadgets ihr business modell voranbringt, die VNB weil man sich den Netzausbau aufschieben kann.
Setzt natürlich voraus, daß die Jungs nen Computer wenigstens schon mal gesehen haben
Ja, genau. Und am besten die Beschreibung, Berechnung, Ansicht und Kontrolle auch gleich enthalten, so dass die Programmierung der Schnittstelle möglichst einfach ist. Hier ein weiterer Vorschlag für ein universelles Formal auf json Basis. Weil das vermutlich nicht auf Anhieb verständlich ist, anbei das Beispiel in von oben leicht angepasst.
Der Vorteil ist, dass die Beschreibung mit in der Datei vorhanden ist, so dass im Idealfall kein Programmieraufwand für die Schnittstelle anfällt. Und es fallen auch alle Einschränkungen wie z. B. wie viele Zeichen für die Einheit genutzt werden dürfen und welche Einheiten verwendet werden dürfen, weg. So wäre das Format wirklich für alles nutzbar.
wikipedia, wikidata, Linux und LibreOffice haben auch nicht wirklich eine "Geschäftsidee". Ich erstelle gerade ein Programm, mit dem man das umsetzten könnte und zwar als kostenloses Open Source Programm. Ich sehe daher nicht wirklich, wozu es eine "Geschäftsidee" braucht. Höchstens um es bekannt zu machen.
Aber wenn es Sie beruhigt, hätte ich schon eine "Geschäftsidee": Der Service ist kostenlos, solange die Daten öffentlich zugänglich sind. Wenn man die Daten aber nur für bestimmte Nutzer sichtbar machen möchte, kostet das für den ersten Nutzer 10 Euro pro Jahr. für den zweiten 11 Euro und so weiter.
Ja, ich vermute auch, dass es die gibt. Hätten Sie gerade ein paar Beispiele?
Ich habe in den letzten Jahren immer wieder API Schnittstellen programmiert und eingerichtet. Leider kosten die Anpassungen immer wieder Arbeit, die aus meiner Sicht nicht nötig wäre. Von daher wäre eine möglichst universelles API aus meiner Sicht schon eine gute Idee.
Strompreise frage ich bei Awattar ab. Doku dazu gibt's auf der Homepage.
Tibber habe ich genutzt muss man aber Kunde sein.
Hexenwerk ist das nicht.
Ich bin Preisgesteuert. Die Netzlast interessiert mich nicht. Es ist egal ob diese bei 70 oder 95% liegt. Es ist nur wichtig nicht in die Überlast zu kommen.
Das Problem hat sich noch nicht gestellt. Löse ich wenn es wichtig wird
Richtig, in vielen Fällen ist es einfach, vor allem, wenn Dich die Netzlast nicht interessiert. Andere wollen aber vielleicht die Netzlast nutzen. Oder Wetterdaten und Prognosen. Oder die Batteriekapazität oder den CO2-Preis. Oder Daten aus Studien und dann wird es meistens schon kompliziert. Das vorgeschlagene Format könnte in der Lage sein, auch den Austausch zwischen wissenschaftlichen Studien zu erleichtern.
Dann musste der Stromanbieter die Wetterdaten über die API liefern. Die hat der aber evtl. nicht.
Oder der Stromanbieter muss den Future des Börsenpreises für Tomaten in Spanien im Juni liefern. Weil könnte ja sein das ich einen Tomatenanbau betreibe und jetzt die eine API abfragen will um herauszufinden ob ich heute Nacht die Wärmepumpe anschmeissen sollte um meine Tomaten schneller reifen zu lassen so daß ich diese mit Gewinn im Juni verkaufen kann.
APIs leben davon granular zu sein. Der Gedanke das eine Ding zu bauen das alles kann ist falsch und steht Innovation entgegen
Ja, richtig. Nur wäre es gut, wenn man nicht für jedes API ein eigenes Mapping schreiben müsste, sondern das Mapping inklusive der Testfälle im Format integriert ist. Das würde die Erstellung und Inbetriebnahme eines API erleichtern.
Vermutlich haben das die Schriftentwickler auch gesagt, als die lateinischen Buchstaben eingeführt wurden. Meine Behauptung ist, der Mensch kann sich Zahlen ohne Worte nicht so gut merken und denken ohne Wort klappt auch nur bedingt gut.
Wie gesagt, ich suche noch noch einem Beispiel, was sich so nicht umsetzen lässt. Gibt auch etwas zu gewinnen ...
Bedenke, daß das format auf einer Mikro-CPU wie einem kleinen ESP mit wenig Leistung und wenig speicher auswertbar sein muss. Ich denke bei sowas an dumme kleine gadgets für den DAU, der nur 1x die Datenquelle auswählt und dann läuft das Teil, und das darf im Handel vielleicht 5€ kosten, damit dein Kühlschrank an dem Teil schon im 1. Jahr Gewinn macht. Nur mit sowas trittst eine Marktrevolution los.
Deshalb hatte ich eine eher kompakte feste Struktur vorgegeben. Die läßt sic in einem fixen Array verarbeiten, kein garbage collector der dir davonläuft und das teil nach 3 Monaten aufhängt. Dann isses im Mistkübel und die Revolution ist gescheitert.
Das Format muss noch etwas verändert werden, die Datei von mir ist erstmal Vorlage wie ich mir das in etwa vorstelle. Es fehlt noch die Aufteilung Preis Ankauf und Verkauf incl. Kosten (Netzgebühren, Verluste, Gewinn). Dazu: Stell dir vor, du hast LoRaWAN 4800bps und 16 Geräte.
Jedenfalls muss ein Aggregator (Stromhändler, VNB) die Daten von Preis und NBS zamführn, damit eine Netzbelastungssteuerung und die Marktpreise in einer einfachen Datei auswertbar sind. Dafür dürfte eine EU-Vorgabe notwendig sein, nationale Regelungen sind lieb aber was passiert wenn Aldi das Ding von Schweden bis Malta auf den Markt wirft?
