Diskussion zum Thema Fernsteuerbarkeit PV gemäß § 9 EEG 2023

[CiNcH83]

Es dürfte in Zukunft bei Einbau einer SteuVE nach § 14a EnWG bzw. eines iMSys ja immer häufiger der Fall sein, dass der Netzbetreiber die Fernsteuerbarkeit für PV-Anlagen mit IBN ab 27.05.2023 verlangt. Meine Anlage ist da zum Glück erstmal außen vor.

Natürlich kann man die Fernsteuerbarkeit über die FNN Steuerbox (3- bzw. 4-Relais-Steuerung) realisieren. Dann hat man halt hoffentlich schon ein paar "Relaiskabel" vom Zählerschrank zum Wechselrichter gelegt.

Nutzt man ein HEMS, könnte man die Steuerung doch schon bereits heute digital auslegen? Für EEBUS gibt es den LPP (Limit Power Production) Use-Case, den evcc ja schon unterstützt, siehe hier. Diese Leistungsreduzierung wird aktuell noch nicht an die PV-Anlage bzw. den Wechselrichter weitergereicht. Hier können gerätespezifische Implementierungen zur Reduzierung der Einspeiseleistung festgehalten werden.

[VolkerK62]

dass der Netzbetreiber die Fernsteuerbarkeit für PV-Anlagen mit IBN ab 27.05.2023 verlangt

hast du dazu mal eine Rechtsgrundlage?
Hab schon befürchtet, dass das auf mich zutrifft.

[CiNcH83]

Hier noch eine Forderung des BDEW an den Bundestag, wonach das für Bestandsanlagen mit IBN vor 1.1.2023 entfallen zu lassen, da diese noch unter das EEG 2021 fielen, wo nur Anlagen >25 kW steuerbar sein mussten. Es besteht auch kein nachvollziehbarer technischer Zusammenhang zum § 14a EnWG.

Der Netzbetreiber enercity fordert das gar nicht (siehe Anmeldeformular), nicht einmal für Neuanlagen, bezieht sich aber trotzdem auf das Gesetz. Wahrscheinlich blicken die bei dem ganzen Chaos auch nicht so wirklich durch.

[HWE70]

Da das Thema Feed In Management seit der Anpassung des §9 EEG im Februar 2025 eigentlich so ziemlich jeden erwischt, sobald der MSB mit dem SMGW vorbei schaut, ist das Thema durchaus dringender Natur. Mein gMSB startet zum Beispiel gerade bei den Bestandsanlagen durch (bei mir nicht, ich habe eine Kaskade, und die unterstützt er (noch) nicht). Wer bei inexogy eigentlich nur das SMGW bestellt (weil der gMSB nicht aus dem Quark kommt), reibt sich die Augen, dass auch ohne SteuVE bei > 7kWp die Controlbox gleich mit auf dem Zettel steht (§29 Abs. 1 MsbG läßt grüßen). Daher würde mich die Zeitleiste zur Implementierung von FIM in evcc interessieren. Gibt es eine Roadmap für das Thema?

[andig]

Die Holzhammermethode ist in Vorbereitung: #21747. Wenn das umgesetzt ist muss LPP (FIM?) nur noch verdrahtet werden. Im ersten Schritt wird's allerdings nur Nullabregelung geben, das können wir allerdings auf Leistungslimit ändern. Tatsächlich wäre LPC sogar nochmal ein gutes Incentive, das evtl. direkt ab Beginn zu tun.

[HWE70]

Hört sich gut an :-) Als zweiten Schritt nach der Nullabregelung wäre es auch erst einmal hinreichend, das von der Controlbox empfangene Leistungslimit per MQTT verfügbar zu machen. Das Setzen des Limits im WR könnte man ja erst einmal selber per Home Assistant o.ä. coden. Gleiches gilt aus meiner Sicht für den §14a mit Blick auf Speicher. (FIM = Feed-In Management)

[andig]

LPP = Limitation of Power Production

[Schwebebahn]

Ich würde auch gerne freiwillig in §14a wechseln um die pauschale Reduzierung, und im Modul 3 das reduzierte Netzentgelt, nutzen zu können. Durch den notwendigen Einbau des iMSys müssen aber auch meine beiden PVs nach §9 EEG steuerbar werden. Ich musste auf meiner Suche nach einem HEMS auch feststellen das es nicht eine Lösung gibt welches beides (Herstellerübergreifend) kann. §14a EnWG (Dimmen) und §9 EEG (Limit Power Production Use-Case), dabei können es meine beiden Wechselrichter über Modbus:

• SolarEdge Wechselrichter: Link
• Solax G4 Hybrid Wechselrichter: Link

Beides funktioniert schon über Home Assistant und den beiden HACS Integrationen, wo man sich sicher gut inspirieren lassen könnte.

[andig]

Es wäre Klasse, wenn wir dies als Sammelissue nutzen könnten. Bitte konkrete Registerangaben für die einzelnen PV Wechselrichter für den Case "Limitation of Power Production".

ACHTUNG uns interessiert nicht ob sich bei einem WR die abgegebene AC Leistung auf einen bestimmten Wert reduzieren lässt. Uns interessiert dabei, ob sich die Netzeinspeisung auf einen bestimmten Wert reduzieren lässt!

/cc @premultiply

[CiNcH83]

Ich habe jetzt noch die Implementierung in der HA huawei_solar Integration verlinkt.

Implementierung in HA huawei_solar Integration (set_maximum_feed_grid_power)

[malcolmx67]

@andig ich finde es ja super, dass Ihr den LPP Use-Case für diverse Wechselrichter umsetzen wollt. Allerdings fände ich es genauso toll, wenn Ihr LPP (und idealerweise auch LPC) Events per evcc im MQTT sichtbar machen könntet. Das eröffnet dann jedem zumindest die Möglichkeit, z.B. per ioBroker darauf zu reagieren und wäre eine generische Lösungsoption. Ggf. lassen sich damit dann auch Exoten auf unkonventionellem (aka unschönem) Wege limitieren (Stichwort Screenscraper).
Weniger 'unkonventionell' aber dafür zeitlich etwas entkoppelt von der Unterstützung von LPP beim Deye-WR durch evcc könnte ich die Einspeiselimitierung mit vermutlich weniger als 10 min Aufwand per ioBroker umsetzen. Bei vielen anderen Wechselrichtern wäre das vermutlich ähnlich einfach. Aber dazu brauche ich einen Trigger, der mir das Anliegen eines LPP Signals anzeigt. Wäre toll, wenn evcc das per MQTT bereitstellen könnte.

[andig]

@malcolmx67 das HEMS, in dem Fall EEbus, wirkt auf die Circuits. Über Circuits werden aktuell nur die Wallboxen gesteuert aber keine Speicher oder Erzeuger. Eine über das Konstrukt des Charger's hinaus gehende externe Integration gibt es dafür derzeit nicht.

Wenn wir Speicher/Erzeuger mit einbinden wird es aber auch die Möglichkeit geben, custom Meter zu implementieren über die Du dann natürlich auch eine externe Steuerung realisieren kannst genauso wie sich heute auch custom Meter einbinden lassen.

[akader61]

Modbusregister bei Growatt SPH7000 für Export Limit Settings:
Register: 122 ExportLimit_ En/dis -> 0/1
Register: 123 ExportLimitPowerRate 0-100% = 0 - 1000 (0,1% Schritte)

Für EW11 WiFi <-> RS485 Adapter mit Protokoll "Modbus"
modbus -s1 192.168.X.X:502 H@122=1 H@123=600

[MartB]

Für den Foxess H3

ExportLimit (min 0, max 100000)
Register 41012 + 41013 als u32 in Watt

Gibt es schon einen draft für das FeedIn Limit?

Sample für das lesen der Werte für (100000 W)

uint32_t u32(uint16_t low, uint16_t high)
{
  return (static_cast<uint32_t>(high) << 16) + static_cast<uint32_t>(low);
}

int main()
{
  // 41012 is high, 41013 is low
  std::cout << u32(34464,1);
}

[Doppellhelix]

Hier ein Link zum Prüfverfahren, wenn man alles technisch auf der Hausseite erledigt hat.
Schließlich muss man auch nachweisen, dass die Steuerung funktioniert.

[CiNcH83]

Fronius habe ich hinzugefügt, siehe hier.

Laut Fronius muss man einen eigenen Regelkreis implementieren, um die Leistung (WmaxLimPct) des Wechselrichters basierend auf der Total Real Power des Smart Meters zu ziehen. Schon komisch. Bei der 70% Abregelung ist es doch schon lange Uses, dass diese weich erfolgt und der Hausverbrauch on-top gerechnet wird...

[UMLAUTaxl]

Die Daten von/für Sungrow sind leider etwas widersprüchlich/veraltet(?):
Github Gist 2025-04-25
TI_20240924_Communication Protocol of Residential Hybrid Inverter-V1.1.5-1.pdf (422.0 KB) 2024-09-24
Stimmt aber angeblich nicht und man sitzt plötzlich "im Dunkeln": https://forum.iobroker.net/post/1008989 2023-06-27
13074/13087? 31222?
5122? (Obwohl es da wohl eher nur um die Hausakkuladung geht.)

Einmal hab ich gelesen, dass man wohl noch was in der iSolarCloud-App klicken muss ...

[D4Ci0]

Kann evcc parallel zu einem WR als EEBUS client lpp und lpc Kommandos empfangen?

Es geht um einen Kostal G3, dieser unterstützt nativ EEBUS und kann auf lpc und lpp reagieren, kommt es dann aber zum Konflikt mit evcc, die lpc für die Wallbox steuern würde?

Eine Einbindung von Kostal für lpp sehe ich nicht als möglich an mit den begrenzten Modbus-Registern.

Siehe: „ Leistungsbegrenzung nach §14 a EnWG und §9 EEG über EEBus aktivieren“ -> https://www.kostal-solar-electric.com/fileadmin/downloadcenter/kse/Fact_Sheets/FS_Paragraph_14a_v06-2025_PLENTICORE-G3.pdf

[premultiply]

Es geht um einen Kostal G3, dieser unterstützt nativ EEBUS und kann auf lpc und lpp reagieren

Das würde ich so lange bezweifeln bis es funktionsfähig nachgewiesen ist.
Rund um die Unterstützung von/mit/durch EEBus gibt es herstellerübergreifend leider fast nur irreführende Lügenmärchen.
Das Thema ist so komplex und umfangreich dass das niemand mal eben so aus dem Ärmel schütteln kann.
Immerhin sieht das bei Kostal zumindest schon mal UI-seitig recht fortgeschritten aus.
Ob das tatsächlich irgendwie funktioniert und (ggf. nur) mit welchen Gegenstellen bleibt abzuwarten.

[premultiply]

Theoretisch sollten sich via EEBus mehrere Geräte parallel betreiben lassen wenn das beim jeweiligen Use Case sinnvoll ist.
Inwiefern das dann im Zusammenspiel mit dem jeweiligen Messstellenbetreiber und Steuerbox auch tatsächlich praktisch so ist kann wohl bislang niemand so genau mit Sicherheit beantworten.

[D4Ci0]

Wenn nun aber z.B Kostal nativ lpc und lpp über EEBUS empfangen kann, würde es gut sein, wenn evcc hier nicht über EMS Befehle im circuit die entsprechende Dimmung/Nulleinspeisung vornimmt, sondern parallel zum Modbux-Proxy auch einen EEBUS-Proxy implementiert hätte, der den lpc und lpp use case dann an kompatible WR oder Wallboxen weiterleitet.
Dann könnte man die ganze Steuerbox vom LAN trennen und muss nicht extra VLANs erstellen. Fremde Hardware im LAN würde ich eher vermeiden wollen. Mit Evcc wäre das gut gelöst, da mehrere NICs.

Ob der Kostal das wirklich kann, könnte man mit zumindest versuchsweise dem Steuerbox-Simulator testen.