Sungrow - Speicherleistung und Steuerung

[seaspotter]

Hallo zusammen,

ich nehme nochmal die Diskussion aus dem 2.1.7 Alpha 1 Thread auf viewtopic.php?p=122414#p122414 zum Thema Sungrow und der Thematik der Speicherleistung.

In der Alpha bzw Beta ist es aktuell ja so umgesetzt das für die neue Firmware (ab Nov 24) und den SHxxRT Wechselrichter mit dem LAN Port die Auslesung sauber funktioniert, aber für die anderen Versionen gibt es meines Erachtens noch ein paar Probleme. Das sieht man vor allem hier bei einer Zwangsladung, siehe diesen Beitrag: viewtopic.php?p=121271. Liegt u.A. an den verschiedenen Registern die teilweise verfügbar sind und teilweise nicht.

Ich hab mir jetzt mal eine Alternative angesehen. Statt dem Register 13021 was die Speicherleistung enthält und leider nicht in allen Auslesemöglichkeiten identisch ist (mit oder ohne Vorzeichen) wäre eventuell das Produkt aus Batteriespannung (Register 13019) und Batteriestrom (Register 13020) möglich. Dies wird u.A. im SMA Hybrid WR für die Auslesung der Batterieleistung ebenfalls so umgesetzt.

Die Registerübersicht von Sungrow (Version 1.1.5):

sungrow_battery_register.png (31.73 KiB) 385 mal betrachtet

Ich habe da mal einen Test gemacht mit meiner aktuellen Konfiguration: SHxxRT mit aktuellster Firmware und WinetS ebenfalls mit aktueller Firmware (.030). Der Batteriestrom Register 13020 ist bei mir sowohl über LAN als auch über WinetS vorzeichenbehaftet, ich kann also zwischen Ladung und Entladung sauber unterscheiden. Eine Batterieladung ist negativ und eine Batterieentladung ist positiv.

Hier eine Übersicht wo ich aus dem LAN Port die Batterieleistung auslese und das Produkt aus Spannung und Strom bilde und aus dem WinetS ebenfalls. Die gelbe Kurve ist die Batterieleistung (13021) aus dem WinetS und hat kein Vorzeichen, eine Unterscheidung ist hier nicht mögich, aber alle anderen 3 Fälle geben den nahezu identischen Wert:

sungrow_vergleich.png

(60.63 KiB) Noch nie heruntergeladen

Es wäre jetzt nur interessant ob es noch Leute gibt die das mit anderen Konfigurationen testen können. Interessant wäre:
- SHxxRT mit alter Firmware und Auslesung über LAN und WinetS
- SHxxT (also die großen neuen WR) mit WinetS2 oder RS485 Auslesung

Ideal wäre wenn jemand die WR parallel auch über iobroker oder Homeassistant auslesen und sich da vllt mal die Register 13019 und 13020 ansehen können, ob das Register 13020 bei Entladung ein Vorzeichen haben und bei Ladung keins.

Wenn das gegeben wäre dann könnte man sich die Firmware Unterscheidung sparen die kürzlich reingekommen ist und hat immer die gleiche Batterieleistung als Produkt von Spannung und Strom und bräuchte auch kein Register 13000 mehr wo die Entladung und Ladung auch als Bit rauskommt.

Würde mich freuen wenn da jemand mal mittesten könnte

[Heavendenied]

Also ich hab bei mir auf dem Sungrow SH10RT noch die .51.04/.51.03 FW drauf und habe auch vor die so zu lassen (da meiner Ansicht nach immer noch die mit den wenigsten Fehlern.
openWb läuft bei mir auf 2.1.5-Patch.2
Die Anzeigen (außer bei Zwangsladung, das wird dann als PV Leistung angezeigt) stimmen bei mir alle.

Habe eben mal mit dem Modbus Testtool die entsprechenden Register ausgelesen und fürchte der Plan wird so nicht klappen, weil die leider alle ohne Vorzeichen kommen.
Beispiel:
Bei z.B. 2,5 kW Ladeleistung bekomme ich:
13020: 2651
13021: 93
13022: 2505
Bei 2,5 kW Entladeleistung bekomme ich:
13020: 2608
13021: 95
13022: 2497

[seaspotter]

Also ich hab bei mir auf dem Sungrow SH10RT noch die .51.04/.51.03 FW drauf und habe auch vor die so zu lassen (da meiner Ansicht nach immer noch die mit den wenigsten Fehlern.
openWb läuft bei mir auf 2.1.5-Patch.2
Die Anzeigen (außer bei Zwangsladung, das wird dann als PV Leistung angezeigt) stimmen bei mir alle.

Habe eben mal mit dem Modbus Testtool die entsprechenden Register ausgelesen und fürchte der Plan wird so nicht klappen, weil die leider alle ohne Vorzeichen kommen.
Beispiel:
Bei z.B. 2,5 kW Ladeleistung bekomme ich:
13020: 2651
13021: 93
13022: 2505
Bei 2,5 kW Entladeleistung bekomme ich:
13020: 2608
13021: 95
13022: 2497

Danke dir vielmals fürs nachsehen. Habs übersehen, dass mit dem .95.03. Update erst 13021 und 13022 das Vorzeichen bekommen haben und alles davor noch ohne. Dann gibts afaik keine andere Möglichkeit weil ja auch in einigen WinetS Firmwares das Problem war das das 13000 Register teilweise nix angezeigt hat, sprich eine Unterscheidung nach dem Lade- und Entladebit aus dem Register ist auch wieder fehlerbehaftet.
Dann muss es wohl so bleiben und mit eventuell falscher Darstellung bei Zwangsladen gelebt werden Oder irgendwann harter Cut - wie es anderswo auch gemacht wird - das es nur noch mit einem FW Update auf eine aktuelle Version geht, ansonsten Pech gehabt?

Würde mich trotzdem noch interessieren wie es am SHxxT ausschaut.

[Tidur]

Danke dir vielmals fürs nachsehen. Habs übersehen, dass mit dem .95.03. Update erst 13021 und 13022 das Vorzeichen bekommen haben und alles davor noch ohne. Dann gibts afaik keine andere Möglichkeit weil ja auch in einigen WinetS Firmwares das Problem war das das 13000 Register teilweise nix angezeigt hat, sprich eine Unterscheidung nach dem Lade- und Entladebit aus dem Register ist auch wieder fehlerbehaftet.
Dann muss es wohl so bleiben und mit eventuell falscher Darstellung bei Zwangsladen gelebt werden Oder irgendwann harter Cut - wie es anderswo auch gemacht wird - das es nur noch mit einem FW Update auf eine aktuelle Version geht, ansonsten Pech gehabt?

Die ursprüngliche Variante des Moduls war einheitlich und hat mit Register 13000 gearbeitet. Das hat allerdings nicht gereicht (da es nicht überall verfügbar ist).
Alles danach ist eine abenteuerliche Entdeckungsreise teils undokumentierter Sonderfälle.
Hier mal ein paar:

• Die Ströme einzelner Phasen lassen sich nicht bei allen Sungrows auslesen. Versucht man es dennoch, liefert der Wechselrichter gar keine Daten mehr.

• Register 13000 ist über LAN-Port verfügbar, über WiNet-S (nach deiner Aussage) je nach Firmwarestand, am WiNet-S2 nicht.

• Bei einigen Firmwareversionen des WiNet-S2 stürzt die Modbus Kommunikation alle 7-24 Std ab und der Dongle ist dann gar nicht mehr im Netzwerk erreichbar. (Sollte ab Firmware WINET-SV300.001.03.P014 gefixt sein.)

Selbst wenn wir uns auf den Standpunkt stellen, dass nur aktuelle Firmware unterstützt wird bleiben genug Sonderfälle für schlaflose Nächte übrig.

[seaspotter]

Die ursprüngliche Variante des Moduls war einheitlich und hat mit Register 13000 gearbeitet. Das hat allerdings nicht gereicht (da es nicht überall verfügbar ist).
Alles danach ist eine abenteuerliche Entdeckungsreise teils undokumentierter Sonderfälle.
Hier mal ein paar:

• Die Ströme einzelner Phasen lassen sich nicht bei allen Sungrows auslesen. Versucht man es dennoch, liefert der Wechselrichter gar keine Daten mehr.

• Register 13000 ist über LAN-Port verfügbar, über WiNet-S (nach deiner Aussage) je nach Firmwarestand, am WiNet-S2 nicht.

• Bei einigen Firmwareversionen des WiNet-S2 stürzt die Modbus Kommunikation alle 7-24 Std ab und der Dongle ist dann gar nicht mehr im Netzwerk erreichbar. (Sollte ab Firmware WINET-SV300.001.03.P014 gefixt sein.)

Selbst wenn wir uns auf den Standpunkt stellen, dass nur aktuelle Firmware unterstützt wird bleiben genug Sonderfälle für schlaflose Nächte übrig.

Richtig ja, es fehlt leider eine saubere Dokumentation die schon wieder Wochen und Monate auf sich warten lässt. Das letzte Update für den SHxxRT ist nun schon 2 Monate her und die Änderungen sind noch nicht dokumentiert.
Aber was man - meine ich - erkennt, ist das Sungrow versucht die Modbus Register langsam mit den FW Updates anzugleichen. Vielleicht gibt es Hoffnung das in ein paar Monaten alle Register auf allen Varianten (Lan, WinetS, WinetS2, RS485) gleich sind, da wäre sicher geholfen alle Sonderfälle zu erschlagen und zu sagen: "Geht nur noch mit neuer FW, bitte Updaten (lassen)"?

Ich bin da optimistisch Beim SHxxRT ist es zumindest jetzt aktuell mit neuer Firmware so das Register (die für openWB relevant sind) bis auf die Batterieleistung alle identisch sind und eine Ausnahme die Skalierung der Netzfrequenz ist anders. Alle anderen Daten bekomme ich gleich aus WinetS und LAN.

Vielleicht kann man dann irgendwann die Firmwareunterscheidung rausnehmen und nur noch zwischen SG, SHxxRT und SHxxT unterscheiden und auch nicht mehr zwischen LAN, WinetS und ggf RS485. Würde es für Anwender, Support und die Programmierer erleichtern

[aiole]

@seaspotter
Kannst du dich mit den gefundenen Erkenntnissen bitte auch an Sungrow-DE wenden und dort die teils chaotischen Zustände darlegen? Mach' ihnen klar, dass etliche Installateure mittlerweile weg von Sungrow gehen, weil die Datenbereitstellung an der Schnittstelle nicht sauber läuft und vor allem nicht oder nur unvollständig dokumentiert ist. Die "Nachwehen" generieren deutlich höhere Kosten als die Einsparung, die der WR-Hersteller verantwortet.

[seaspotter]

@seaspotter
Kannst du dich mit den gefundenen Erkenntnissen bitte auch an Sungrow-DE wenden und dort die teils chaotischen Zustände darlegen? Mach' ihnen klar, dass etliche Installateure mittlerweile weg von Sungrow gehen, weil die Datenbereitstellung an der Schnittstelle nicht sauber läuft und vor allem nicht oder nur unvollständig dokumentiert ist. Die "Nachwehen" generieren deutlich höhere Kosten als die Einsparung, die der WR-Hersteller verantwortet.

Deine Meinung teile ich nicht und kann das auch nicht bestätigen das sich viele Installateure aus diesen Gründen von Sungrow abwenden, eher das Gegenteil ist der Fall das Sungrow auf dem Markt immer mehr wird. Ich weiß nicht woher du diese Annahme nimmst? Ich beobachte den Markt schon sehr lang und es wird immer mehr seitdem sie halt auch viel in den deutschen und EU Markt pushen.
Im Sungrow eigenen Universum (iSolarcloud) ohne externe Anbindung funktioniert es ja auch auch, da bekommt der "normale" User gar nichts mit davon das die Modbusregister nicht passen. Viele Fehler werden von den Installateuren gemacht (falsche Einstellungen, nicht sauber angeklemmtes Smartmeter etc) weil sie die Schulungen nicht besuchen. Daher kommt viel Unmut, was aber nix mit dem Hersteller zu tun hat.
Ich weiß auch nicht woher du die Annahme nimmst das das irgendwo Kosten und Einsparungen verursacht, da bist du glaube ich mit deiner Aussage eher auf dem Holzweg.

Meine Meinung: Fakt ist Sungrow-DE kennt die Thematik der Dokumentation und der Modbus-Register und die sind auch sehr aktiv im PV Forum und versuchen ihr Möglichstes (mein Eindruck). Aber auch die sind von der finalen Software und der Dokumentation aus dem Headquarter abhängig, da Sungrow ja nicht nur den deutschen Markt bedient sondern einer der großen Player auf dem globalen Markt ist und damit alle Märkte gleich bedient und auch Firmwares entsprechend ausrollt.

Wenn du anderer Meinung, Ansicht bist und die darlegen kannst, kannst du dich ja gerne diesbezüglich an Sungrow-DE wenden?

[aiole]

Deine Meinung teile ich nicht und kann das auch nicht bestätigen das sich viele Installateure aus diesen Gründen von Sungrow abwenden, eher das Gegenteil ist der Fall das Sungrow auf dem Markt immer mehr wird. Ich weiß nicht woher du diese Annahme nimmst? Ich beobachte den Markt schon sehr lang und es wird immer mehr seitdem sie halt auch viel in den deutschen und EU Markt pushen.

Diese Aussage bezieht sich auf Installateure, die mit übergeordneten HEMS-Systemen arbeiten. Im Sungrow-internen Kosmos mag das anders aussehen.

Fakt ist, dass es Welten zwischen z.B. Fronius-WR-FW mit zugehöriger Schnittstellen-Doku und Sungrow sind. Da mittlerweile alle WR-Marken wieder ausreichend liefern können, ist es aus Installateurs- und Kundensicht einfach, auf Qualitätsprodukte zu wechseln, zumal diese nur unwesentlich teurer sind. Gute Firmware gehört einfach zur Hardware dazu. Ansonsten nützt die beste HW nichts.

Es war auch nur ein Bitte, deine Erkenntnisse beim Verursacher zu platzieren, um den Prozess zu besseren Sungrow-FW zu beschleunigen. Fundierte Endkundenhinweise werden nach meiner Erfahrung auch in headquarters ernst genommen. Sie müssen nur sauber aufbereitet sein. Messen bieten sich bei Sungrow eher nicht an. Da rennen nur Verkäufer herum, die Karten sammeln.
Ich selbst kann leider nicht helfen, da ich keine Sungrow-WR verwende, schätze deine Einsatz aber sehr. Letztlich wollen wir alle nur, dass die Buden laufen.

[seaspotter]

Es war auch nur ein Bitte, deine Erkenntnisse beim Verursacher zu platzieren, um den Prozess zu besseren Sungrow-FW zu beschleunigen. Fundierte Endkundenhinweise werden nach meiner Erfahrung auch in headquarters ernst genommen. Sie müssen nur sauber aufbereitet sein. Messen bieten sich bei Sungrow eher nicht an. Da rennen nur Verkäufer herum, die Karten sammeln.
Ich selbst kann leider nicht helfen, da ich keine Sungrow-WR verwende, schätze deine Einsatz aber sehr. Letztlich wollen wir alle nur, dass die Buden laufen.

Okay angekommen, aber ich weiß aus dem PV Forum das es dort genug und teils fundierte Rückmeldungen gibt und der Sungrow-DE Produktmanager der dort stellvertretend auch ziemlich aktiv ist, kennt m.E. diese Themen alle. Sie sind angebracht, daher habe ich ja auch schon meinen Optimismus angebracht, dass ich denke das es dort sicher noch wieder Updates zum Besseren geben wird, es wird vermutlich nur aus vorher genannten Gründen dauern. Die User dort löchern ja auch regelmäßig wann die neue Doku kommt etc.

Ich könnte mich auch zurücklehnen und sagen bei mir läuft ja alles, ich hab Glück. Aber mir ist ja auch daran gelegen das auch alle Sonderfälle sauber irgendwann abgebildet werden, daher auch dieser Thread. Ich beobachte auf jeden Fall weiter (und bin damit nicht allein) und wenn sich wieder etwas ändert reporte ich das gern auch und trage gerne weiter dazu bei

[aiole]

Perfekt. Es braucht bei solchen Themen eine gute Aufbereitung, damit das openWB-Team die Sungrow-FW-Änderungen leicht implementieren kann.

Ich selbst empfehle Sungrow dennoch nicht, weil das noch immer zu "bananig" ist und zum Glück Alternativen verfügbar sind. Die meisten Leute haben einfach keine Zeit für Testing und sind schnell auf 180, wenn's nicht geht. Das kann sich allerdings ändern, wenn Sungrow die vielen Hinweise ernst nimmt.