Hallo Energiemanager!
Ich bin auf der Suche nach Informationen darüber, wie schnell OpenEMS in der Lage ist auf Wertänderungen im Smartmeter zu reagieren und in Folge dessen auszuregeln.
Gibt es da Erfahrungswerte, Daumen*Pi Berechnungen o.ä, einfach mal nur um ein Gefühl für das zeitliche Verhalten zu bekommen?
Die meisten Normen zusammengefasst, spielt sich das Ganze im Bereich von 0.8sec Reaktionszeit bis 2sec Ausregelzeit ab. Da bleibt in der ganzen Kette vom Smartmeter übers zB Netzwerk zum OpenEMS bis (nochmal übers Netzwerk) zur Ausregelung zB eines Wechselrichters nicht mehr viel zeitlicher “Spazi”.
Servus Max,
welchen Usecase hast du denn?
Grüße
Servus
Mir geht es konkret um die Exportlimitierung bei Solaranlagen in Kalifornien. Für den Betrieb dort muss die Anlage innerhalb von 0.8 sec mit der Ausregelung beginnen und nach 2 sec damit fertig sein. Das Smartmeter ermittelt die Werte im 500ms Takt, sendet sie via mqtt an einen broker, dort würde OpenEMS angebunden sein, die Regelung machen und die Ergebnisse wieder am Broker publishen, darauf reagieren dann die Inverter.
Lg
Hallo Max,
wenn du OpenEMS Kommerziell nutzt, bitte ich dich der Association beizutreten 
Das fördert die Entwicklung und die Kosten z.B. für das Forum, welches wir hier nutzen. Zu deiner Frage:
Schau dir mal die Cycle Time an 
Am Ende wäre genau das der Plan. Ich könnte mir auch vorstellen Entwickler für das Projekt abzustellen sollten wir all-in gehen, aber zZ bin ich noch in der Überlegung ob “Make” oder “Buy”.
Default cycle time ist ja 1000ms. Das wäre zu langsam um in 0.8sec messbare Änderungen am Einspeisepunkt zu erzeugen. Da müsste ich schon auf eine 100ms cycle time runter, damit auch die Inverter noch Zeit haben ihre Leistungselektronik zumindest anzutriggern. Gibt es da Erfahrungswerte was eine um den Faktor 10 verringerte Zykluszeit an processing power erfordert oder irgend einen Weg das im vorhinein abzuschätzen, ohne jetzt großartig mit einem Versuchsaufbau an die Sache rangehen zu müssen?
Da wirst du nicht drum rum kommen 
Das ist mir schon bewusst. 
Die Frage ist halt: Lohnt es sich den mit OpenEMS zu machen, wo schon im vorhinein absehbar ist, dass ich die Zeiten so und so nicht hinbekomme oder starte ich gleich mit meiner eigenen, genau für diesen Fall zugeschnittenen Lösung.
Darum auch meine Frage nach bereits vorhanden Erfahrungswerten. Warum Zeit in etwas stecken, an dem sich andere Kollegen bereits die Finger verbrannt haben? 
1 Like
Das kommt auch drauf an auf welcher Hardware du das laufen lässt. An sich ist es von OpenEMS Seite erstmal kein Problem die cycle time drastisch zu reduzieren. Ich habe schon von Setups gehört die weniger als 100ms cycle time haben. Ich persönlich habe sie mit einem RevPi schon auf 200ms runter gesetzt. Haupt Bottleneck ist im Prinzip die Komplexität deines Controllers und Netzwerkkommunikation.
1 Like
Hallo @max-win-at,
wir haben unsere Industriespeicher in Schweden für “Fast Frequency Reserve” präqualifiziert. Dort sind noch etwas striktere Reaktionszeiten gefordert. Meine Tips:
- So wenige Kommunikationsstrecken wie möglich (Wofür braucht es den MQTT-Broker dazwischen?)
- Niedrige Cycle-Time. 200ms sollte ausreichen
- Sorgfältig ausgewählte Komponenten (v.A. sehr schneller Netzzähler, z. B. von Janitza)
- Leistungsfähige IoT-Hardware. Wobei hier sowas wie ein Raspberry Pi 4 genug ist.
Gruß,
Stefan
Danke @stefan.feilmeier für die Tips und den Beispiel use case. Ich denke auch, dass zZ der Zähler das bottleneck ist und da ein schnellerer notwendig sein wird. Der MQTT-Broker ist als kleinster gemeinsamer Nenner ein entgegenkommen an das heterogene Geräteumfeld, dem ich gegenüberstehe und sollte das gesamte System simple und stupid halten. Zum Testen verwende ich eine Pi4, im Feld wird es ein äquivalentes Gerät sein.
Sehr interessant, vom Anwendungsfall der schnellen Frequenzreserve (FFR) zu hören.
Ich würde gerne wissen, welche Messgeräte Sie verwendet haben – sind es die Janitza-Messgeräte, die bereits mit OpenEMS kompatibel sind – z. B. UMG 96RM-E und UMG 604?
Wir haben einen Lieferanten für sehr schnelle Industrie-PCs zu einem guten Preis gefunden und denken, dass wir möglicherweise Zykluszeiten von unter 100 ms erreichen können, was Anwendungsfälle wie FFR ermöglichen könnte.
Danke,
Thomas
(Yes I did use Google Translate )