SMA - SHM Anlage und Kunbus RevPi Connect 4

Hallo Community,

ich lese schon einige Tage im Forum mit und mir gefällt die Idee eines Open Source EMS.

Ich habe eine private SMA Anlage mit Sunny Home Manager (SHM).
3 x SUNNY TRIPOWER 15000TL in Summe Module mit 45 kWp
1 x Sunny Island Cluster mit SI8.0H-13 - 18 kW Leistung
2 x Tesvolt TS48V in Summe 76,8 kWh
1 x SMA EV CHARGER 22
2 x SIEMENS 7KM PAC2200 Modbus RTU Zähler

Von den Möglichkeiten mit dem SHM bin ich nach 10 Monaten Betrieb eher enttäuscht, obwohl die Anlage sonst perfekt funktioniert. Zum Beispiel funktioniert das prognosbasierte Laden in meiner Anlagenkonfiguration gar nicht.
Das Laden des Speichers über die Zeitfenstereinstellung im Sunny Portal ist unflexibel und führt zu Lastspitzen am Beginn des Ladens. (Beginnt mit 18 kW zu Laden um dann mit einer Rampe auf den eingestellten Wert zu fahren).

Ich bin daher auf der Suche nach einer EMS Lösung zusätzlich zum SHM.

Ich habe einen Kunbus RevPi Connect 4 mit DIO und AIO.
Ich habe auch den Edge und UI Teil am PC in der Entwicklungsumgebung am Laufen und bereits mit der Simulation getestet bzw herumgespielt.

Im Forum habe ich auch einige Posts zu Kunbus gefunden.
Das board support package for the Kunbus Revolution Pi ist anscheinend noch nicht gemerged. Gibt es da eine Idee wann das passieren soll?

Gibt es vielleicht eine Anleitung wie ich openems von der Entwicklungsumgebung auf den RevPI deployen kann und dort zum laufen bringe?

Ich habe auch schon einige Tests mit den SMA Komponenten und Modbus gemacht. Einge SMA Beschreibungen sind widersprüchlich, oder das Verhalten ist anders als in der Beschreibung. Diese Themen sind beim SMA Support “in Bearbeitung” sowie das Thema vom Laden wie oben beschrieben.

Hat schon jemand openems mit dem Sunny Island SI8.0H-13 am Laufen?

Hatte schon jemand die Überlegung die Speedwire udp Multicasts mitzulesen und in openems zu implemetieren?
Da wären alle Zählerwerte enthalten, ohne das man Modbus Polls braucht.

Ich würde mich über Feedback freuen.

Mit besten Grüßen,
Peter

Hallo peter.platzer,

deine beschriebene Konfiguration sollte mit wenig Aufwand in OpenEMS laufen. Ich habe selbst eine sehr ähnliche Konfiguration in Betrieb. Hier ein paar Infos zu deinen Komponenten:

  • Kunbus - wir bei opernikus haben ein eigenen Clone des offiziellen OpenEMS Repositories. Dort gibt es Treiber für die wir noch keine Zeit hatten, diese zu säubern und in das offizielle Repository einzupflegen. In unserem Repository findest du eine aktualisierte Komponente für den Kunbus Connect+ und verschiedene Kunbus DATA IO Module. Du findest die Sourcen hier (in unserem Repo). Ich habe mir den Connect 4 noch nicht genau angeschaut, würde aber davon ausgehen, dass der OpenEMS Treiber für den Connect+ mit wenig Aufwand erweitert werden kann.
  • Sunny Tripower - die Sunny Tripower Inverter sprechen Sunspec und sind in OpenEMS voll unterstützt. Hier sollte es keine Probleme geben. Link zum offiziellen Repo.
  • Sunny Island (SI) - bei Sunny Island werden die Modelle 4.4M, 6.0H und auch 8.0H unterstützt. Die Konfiguration ist tricky und hat mich viel Zeit gekostet. Anfangs habe ich das System im Symmetric Mode betrieben (1 SI leader steuert 2 SI follower, OpenEMS steuert nur den leader). Das hat nicht gut funktioniert, da ein Bug im SMA die Leistung auf 1/3 der Leistung begrenzt, wenn das Gerät von aussen gesteuert wird. Daher habe ich die SI auf asymmetric konfiguriert und in OpenEMS einen cluster daraus gemacht. Somit kann ich die Anlage in OpenEMS auch asymmetrisch betrieben. Die Tesvolt Batterie ist für OpenEMS transparent, da keine Kommunikation mit der Batterie direkt stattfindet. Es benötigt Zeit die Parameter am SI einzustellen und hier musst du sehr vorsichtig sein. Die SI können so eingestellt werden, dass Sie anfragen auf Modbus ohne Verzögerung auf die Batterie geben, aber auch so, dass Sie Anfragen zeitlich verzögern und nur begrenzte Steigerungsraten zulassen. Für den Start würde ich diese “Sicherung” vermutlich aktiv lassen. Das wiederrum kann dazu führen, das die OpenEMS Controller “wild” herumregeln. Es benötigt Zeit, die richtige Einstellung für deinen Einsatzszweck zu finden.
  • SHM Meter - den SHM Meter kann man nicht direkt auslesen. Dieser wird immer über einen SMA Wechselrichter ausgelesen. Da du drei STP Wechselrichter hast, kannst du die Werte einfach über einen davon auslesen. Das geht relativ problemlos (ich glaube einfach die Default Modbus Unit ID in der Meterkonfiguration verwenden).
  • Siemens PAC - dieser Meter kann auch problemlos genutzt werden.

Sobald du diese Konfiguration am Laufen hast, steht dir die volle Welt aller Controller zur Steuerung der Batterie zur Verfügung, insbesondere auch die zeitvariablen Tarifen. Falls du es noch nicht gesehen hast, empfehle ich dir das Video dazu. Der von @stefan.feilmeier beschriebene Mechanismus funktioniert nämlich auch mit der Tesvolt Batterie und läuft stabil.

2 Likes

Danke c.lehne!

für die Tips und die Links. Bei den Anmerkung zum SI konnte ich Dir nicht ganz folgen:

Hast Du eine Ahnung welche Firmwareversion des SI Du hast?
Ich habe bei meinem SI-Cluster Firmware-Version 3.21.4.R.
Die letzte offizelle Firmware-Version ist 3.30.12.R
Wenn man über Modbus die Leistung des SI abfragt ist es meines Wissens 1/3 der Cluster Leistung, da die Leistung des Masters (= 1 Phase) zurückgeliefert wird.

Bei einem SI-Cluster ist doch nur der Master über Modbus erreichbar.
Die Slaves sind über einen eigenen CAN Bus verbunden wo auch der Tesvolt Speicher integriert ist.
Der Cluster ist standardmäßig in Eigenverbrauchsoptimierung und liefert die Leistungen gemäß den Lasten auf den Phasen.
Laut Modbus Beschreibung kann ich die Grenzen der Leistungsvorgabe im Netzparallelbetrieb in % begrenzen.
Auf Seite 16 Modbus Register:
44041: Minimale Wirkleistung in %
44039: Maximale Wirkleistung in %
Hier ist noch eine Unklarheit in der Registerbeschreibung da die Register als Flashwert und als Register für Netzsystemdienstleistungen gekennzeichnet sind.
Das habe ich beim SMA Support eingemeldet und es ist in Bearbeitung.


Die Implementierung in Openems verwendet die Modbus Register
40149 Active power setpoint
40153 Reactive power setpoint
Die Documentation die in Openems enthalten ist abweichend.
Das Handling der Tesvolt Batterie macht der SI selbst.

Danke ja die Rampeneinstellungen im SI habe ich gesehen.

Danke das war mir neu.
Man kann den SHM auch direkt auslesen wenn man die Schnittstelle für Netzsystemdienstleistungen aktiviert. Aber davon würde ich abraten. Ich hatte die Schnittstelle aktiviert und der SHM ist innerhalb einer Woche abgestürzt.
Nicht mal ein Reset hat funktioniert. Ich musste den SHM stromlos machen, daher habe ich
die Schnittstelle wieder deaktivert. Der Fall ist beim SMA Support in Bearbeitung.

Danke, ja ich habe das im Simulator schon getestet.
Ich muss aber erst die Prioritäten beim Scheduler begreifen.
Mit Scheduler All Alphabetically komme ich nicht immer auf das gewünschte Verhalten.
Ich muss mir den Scheduler Fixed Order anschauen.
Der SI hat auch Einstellungen zur Notstromreserve, ab da akzeptiert er die Befehle über Modbus nicht mehr.
Hast Du diese Einstellungen in OpenEMS nachgebildet?

Danke für Deine Hilfe!

Mit besten Grüßen,
Peter

Ich verwende die aktuelle Version 3.30.12R.

Es gibt in OpenEMS soweit mir bekannt, keine Controller um die Grenzen eines Sunny Island einzustellen. Das kann man machen. Aber warum? OpenEMS kann gleich die Eigenverbrauchsoptimierung übernehmen (ControllerEssBalancing), dann must du auch nichts am vorhandenen Code ändern.

Du kannst diesen Controller direkt mit dem SI-Master verbinden und dann sollte alles bereits laufen.

Viele ESS Controller greifen nur ein, wenn Sie ihren Job erledigen müssen. Z.B. der LimitTotalDischarge Controller. Dieser muss nur sicherstellen, dass die Batterie nicht tiefentladen wird. Ansonsten “schläft” der Controller. Damit das funktioniert, muss natürlich die Priorität stimmen. Das kannst du über die Scheduler vorgeben. Dazu gibt es eine ganz gute Doku. Vielleicht schaust du dir das Kapitel über den Scheduler noch mal an.
Bei mir läuft z.B. ein LimitTotalDischarge Controller und ein Ess Time-Of Use Tariff Controller. Damit die beiden sauber funktionieren, habe ich im “Scheduler All Alphabetically” die Komponenten IDs der Controller angegeben. Zuerst (oben) die Komponenten ID vom “LimitTotalDischarge” controller und danach die Komponenten ID vom “TimeOfUse”-Controller (weiter unten). Dadurch wird sichergestellt, dass der “LimitTotalDischarge” die höchste Priorität hat und als erstes ausgeführt wird.

Mit den Registern kann man eine Bandreite einstellen und einen fixen Arbeitspunkt für Laden und Entladen, das wäre eine Bandbreite von 0 und die gleiche Vorgabe für beide Register.

Bei der Bandreite fällt mir der Controller Ess Grid Optimized Charge, der eigentlich eine Bandbreite Min und Max Charge liefert, ein.
Eine Bandbreite macht auch Sinn um den SI in einem Band mit besserem Wirkungsgrad zu betreiben.

Damit würde die Regelung der SI selbst machen und man muss sich nicht mit dem Thema Regelung beschäftigen. Wie das mit den jetzigen Registern funktioniert habe ich mir noch nicht angeschaut.

Der Hintergrund ist folgender: Meine Anlage mit dem SHM und den 3 PV-Wechselrichtern hat ein Einspeiselimit von 29kW und ist in der jetzigen Konfiguration mit dem SHM vom Netzbetreiber (hier in Österreich) so abgenommen.

Das heißt der SHM sorgt über Speedwire mit den 3 Wechselrichtern dafür, dass die 29 kW nicht überschritten werden.

Daher soll die SHM Konfig so bleiben und das EMS die zusätzlichen Tasks übernehmen, die der SHM nicht kann oder nicht gut kann.

  • Damit soll der SHM das Einspeiselimit weiter machen.
  • Die Eigenverbrauchsoptimierung macht der SI solange der Speicher ausreichend gefüllt ist und nichts abweichendes am Sunny Portal eingestellt ist. Bei einem PV-Überschuss lädt er den gesamten Überschuss in den Speicher bis er voll ist.

Damit man zusätzlich über ein EMS den SI steuern kann:

  • Müssen die Batterieladefenster und das prognosebasierte Laden im Sunny Portal ausgeschaltet sein.
  • Die Eigenverbrauchsbandbreite oder einen fixen Wert (Lade- oder Enladewert) kann das EMS dem SI über Modbus vorgeben.

Interessant sind im ersten Schritt vorallem die Controller: Controller Ess Grid Optimized Charge und Controller Ess Time-Of-Use Tariff .

Das ist zumindest momentan meine Idee.

Danke für die Erklärung und den Link zur Doku.

Wie functioneert das? Ich versuche etwas ähnliches mit HA. Habe versucht die HM20 werte via ein SB1.5 VL40 aus su lesen via ID 2 , keine sinnvolle werte kommen zurück.

Hallo @peterbro,

anbei ein Beispiel für eine Felix Konfiguration mit SMA Sunny Tripower und SHM Meter.

  1. Bridge Modbus zum Sunny Tripower Wechselrichter anlegen

  2. PV Inverter SMA Sunny Tripower Wechselrichter konfigurieren

  3. Meter SMA Sunny Home Manager konfigurieren

Hinweise:

  • Bei mir ist im Sunny Tripower die Modbus Unit ID 3 hinterlegt. Damit verwende ich im Schritt 2 die Unit ID 126 (= 3+Offset von 123) und im Schritt 3 dann die Unit ID 3.
  • wenn ich es mir recht überlege, benötigst du die OpenEMS Komponente PV Inverter eigentlich gar nicht, du benötigst aber den Wechselrichter, weil über den der SHM ausgelesen wird.
  • ich habe im Moment leider keinen Zugriff auf ein System, wo der Meter über einen Sunny Island ausgelesen wird. Das Prinzip sollte aber dasselbe sein.

Hallo ,
Habe ich recht das die screenshots fur die ems sind? Seht so aus ob EMS ein bridge function gebracht um die SMA meter zu Tricken das est ein SMA inverter ist die the werten anfragt. Stimmt das? Ich versuche de HM werte aus zu lesen im Home Assistant . So keine bridge functionaliteit dort.

Nein, openEMS nutzt da die Modbus Register des SHM.

Wir lesen die Werte ja auch aus, um Sie im openEMS darzustellen, nicht zu “Bridgen”.

Es is correct das EMS die modbus register benutzt um aus zu lesen, aber nicht direct mit SHM zugriff . Meine frage is wie ist das gemacht im EMS?

Bitte lies hier:

[openems/io.openems.edge.meter.sma.shm20 at develop · OpenEMS/openems · GitHub](https://GitHub Link)

Diese Implementierung nutzt die Modbus Register des Wechselrichters:

	@Override
	protected ModbusProtocol defineModbusProtocol() throws OpenemsException {
		var modbusProtocol = new ModbusProtocol(this,
				// Consumption and Production Energy
				new FC3ReadRegistersTask(30581, Priority.HIGH, //
						m(ElectricityMeter.ChannelId.ACTIVE_PRODUCTION_ENERGY, new UnsignedDoublewordElement(30581)),
						m(ElectricityMeter.ChannelId.ACTIVE_CONSUMPTION_ENERGY, new UnsignedDoublewordElement(30583))),
				// Power Readings
				new FC3ReadRegistersTask(30865, Priority.HIGH, //
						m(MeterSmaShm20.ChannelId.ACTIVE_PRODUCTION_POWER, new SignedDoublewordElement(30865)),
						m(MeterSmaShm20.ChannelId.ACTIVE_CONSUMPTION_POWER, new SignedDoublewordElement(30867))),
				// Voltage, Power and Reactive Power
				new FC3ReadRegistersTask(31253, Priority.HIGH, //
						m(ElectricityMeter.ChannelId.VOLTAGE_L1, new UnsignedDoublewordElement(31253), SCALE_FACTOR_1),
						m(ElectricityMeter.ChannelId.VOLTAGE_L2, new UnsignedDoublewordElement(31255), SCALE_FACTOR_1),
						m(ElectricityMeter.ChannelId.VOLTAGE_L3, new UnsignedDoublewordElement(31257), SCALE_FACTOR_1),
						m(MeterSmaShm20.ChannelId.ACTIVE_CONSUMPTION_POWER_L1, new UnsignedDoublewordElement(31259)),
						m(MeterSmaShm20.ChannelId.ACTIVE_CONSUMPTION_POWER_L2, new UnsignedDoublewordElement(31261)),
						m(MeterSmaShm20.ChannelId.ACTIVE_CONSUMPTION_POWER_L3, new UnsignedDoublewordElement(31263)),
						m(MeterSmaShm20.ChannelId.ACTIVE_PRODUCTION_POWER_L1, new UnsignedDoublewordElement(31265)),
						m(MeterSmaShm20.ChannelId.ACTIVE_PRODUCTION_POWER_L2, new UnsignedDoublewordElement(31267)),
						m(MeterSmaShm20.ChannelId.ACTIVE_PRODUCTION_POWER_L3, new UnsignedDoublewordElement(31269)),
						m(ElectricityMeter.ChannelId.REACTIVE_POWER_L1, new SignedDoublewordElement(31271)),
						m(ElectricityMeter.ChannelId.REACTIVE_POWER_L2, new SignedDoublewordElement(31273)),
						m(ElectricityMeter.ChannelId.REACTIVE_POWER_L3, new SignedDoublewordElement(31275)),
						m(ElectricityMeter.ChannelId.REACTIVE_POWER, new SignedDoublewordElement(31277))),
				// Current
				new FC3ReadRegistersTask(31435, Priority.HIGH, //
						m(ElectricityMeter.ChannelId.CURRENT_L1, new SignedDoublewordElement(31435)),
						m(ElectricityMeter.ChannelId.CURRENT_L2, new SignedDoublewordElement(31437)),
						m(ElectricityMeter.ChannelId.CURRENT_L3, new SignedDoublewordElement(31439))),
				// Frequency
				new FC3ReadRegistersTask(31447, Priority.LOW, //
						m(ElectricityMeter.ChannelId.FREQUENCY, new UnsignedDoublewordElement(31447), SCALE_FACTOR_1)));

		// Calculates required Channels from other existing Channels.
		this.addCalculateChannelListeners();

		return modbusProtocol;
	}

Stimt nicht ganz, Die SMA Wechselrichters haben ihre eigne registers und das sind nicht die gleiche wie die im SHM registers, so es must ein art von proxy in die code geben. Die node id is auch nicht gleich.

nein, gibt es nicht… die “node id” also die Slave ID ist nicht die selbe, weil der SHM unter einer anderen Slave ID angesprochen werden muss (über die SMA Wechselrichter)

Feedback von SMA:
"Zunächst möchte ich mich für die Verwirrung entschulidigen. Offenbar gibt es einen Fehler in unserer Dokumentation.
Bezüglich des Parameters 41195 liegt der Wertebereich von 1sek bis 1800sek, wie in der Modbus Liste angegeben.

Zum zweiten Punkt: die Parametern WSptMax/MinNom sind ASO’s und können zyklisch beschrieben werden. auch hier liegt ein Fehler in der Dokumentation vor."

WSptMax/MinNom sind die Register 44041 und 44039.