GoodWe ETT-Serie - GoodWe ET (15 - 30 kW)

Begonnen von Parallix, 08 August 2025, 13:37:28

Vorheriges Thema - Nächstes Thema

Parallix

Dieser Thread soll dazu dienen, sich innerhalb der FHEM-Community über Erfahrungen mit o.g. Goodwe-Wechselrichtern auszutauchen.

Starten möchte ich mit folgender Feststellung und  Frage:

Unter Verwendung des FHEM-Moduls SolarForecast (SF) lässt sich ja hervorragend eine Ladesteuerung implementieren. Bei den Wechselrichtern von Goodwe kann der maximale Ladestrom für BAT1 über das Modbus-Register 45353 und der für BAT2 über das Modbus-Register 45378 gesetzt werden.

Leider musste ich feststellen, dass trotz ausreichendem PV-Überschuss die Ladung nicht durchgängig erfolgt, sondern immer wieder pausiert. Nun frage mich, ob das ggf. an der Firmware meines Wechselrichters liegt oder dieses Verhalten auch bei anderen Firmware-Versionen auftritt und würde mich über ein entsprechendes Feedback hier aus der FHEM-Community freuen!
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

Parallix

#1
Nachtrag: Im Photovoltaikforum berichten einige User über ähnliche Beobachtungen. Dort herrscht aber die Meinung, dass das seltsame Ladeverhalten durch eine neue Firnware auf den BYDs ausgelöst wird. Da ich auf meinen BYD HVS-Systemen die Firmware nicht abgefasst habe, kann ich meinerseits die BYDs aus Ursache definitiv ausschließen. Den Effekt beobachte ich bei mir übrigens unabhängig vom Ladezustand der BAT-Systeme!
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

wowogiengen

Zitat von: Parallix am 08 August 2025, 13:37:28Leider musste ich feststellen, dass trotz ausreichendem PV-Überschuss die Ladung nicht durchgängig erfolgt, sondern immer wieder pausiert. Nun frage mich, ob das ggf. an der Firmware meines Wechselrichters liegt oder dieses Verhalten auch bei anderen Firmware-Versionen auftritt und würde mich über ein entsprechendes Feedback hier aus der FHEM-Community freuen!

Hallo Parallix,
ich würde das so nicht bestätigen wollen. Das einzige, was ich beobachten kann, ist bei genügend voller Batterie ( >80%?) wird die Ladeleistung zurückgenommen, und dann etwas sanfter vollgeladen.

Was mich an der ganzen WR-Geschichte aber stört, ist dass es manchmal dazu kommt, dass Strom aus dem Netz genommen wird, anstelle die Batterie zu bemühen, oder andersrum, das Netz Strom bekommt, obwohl die Batterie noch nicht voll ist - ausgenommen der Fall oben...

Ich werde heute auch noch das neue WLAN-Kit einbauen, da das alte wahrscheinlich öfters die Verbindung zum GoodWe-Server verliert.

Hängt das Problem aus dem anderen Thread (ModBus TCP https://forum.fhem.de/index.php?msg=1347443) vielleicht auch damit zusammen, dass ich die 5 anstelle der 247 verwendet habe?

Ich muss heute auch nochmal nachlesen, ob ich ModBus TCP oder RTU nehmen muss...

Viele Grüße
Wolfgang

wowogiengen

Auch von mir ein Nachtrag...
Auch mit der neuen Modbus-ID von 247 anstelle von 5 funktioniert das eine Device nicht zufriedenstellend. Das andere Device, welches nur die beiden Adresse 35138 und 35140 ausliest, bekommt seine Werte zyklisch...

Ich werde jetzt einmal alle group-Attribute von den Readings löschen, bei denen nur 1 Register ausgelesen wird...

Parallix

#4
Zitat von: wowogiengen am 05 September 2025, 14:59:13...
Das andere Device, welches nur die beiden Adresse 35138 und 35140 ausliest, bekommt seine Werte zyklisch...

Laufen beide Devices und dann noch die Anbindung zum Server von Goodwe gleichzeitig? Das jedenfalls könnte problematisch sein.

PS: Seit ich meinen Wechselrichter vollständig von Sems abgekoppelt habe und der Modbus-Zugriff nur noch (m)einen Waveshare "RS485 to ETH (B)"-Adapter erfolgt, sind fast alle vorherigen Modbus-Problemen verschwunden.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

wowogiengen

Hallo,
ich habe bisher noch keine Probleme feststellen können :-)

Mich wundert nur eines...
In der Doku von GoodWe stehen die Regist 35137 und 35139 drin, wenn ich die auslese, bekomme ich als Wert 0, lese ich aber 35138 und 35140 aus, stehen die korrekten Werte (annähernd dem was das Portal meldet) drin... Alle anderen Register sind entweder ok, oder ich habs noch nicht näher prüfen können...

Parallix

Zitat von: wowogiengen am 05 September 2025, 18:43:00Hallo,
ich habe bisher noch keine Probleme feststellen können :-)

Mich wundert nur eines...
In der Doku von GoodWe stehen die Regist 35137 und 35139 drin, wenn ich die auslese, bekomme ich als Wert 0, lese ich aber 35138 und 35140 aus, stehen die korrekten Werte (annähernd dem was das Portal meldet) drin... Alle anderen Register sind entweder ok, oder ich habs noch nicht näher prüfen können...


Vielleicht hast Du übersehen, dass die Register 35137 und 35139 32-Bit breite vorzeichenbehaftete Register (S32) sind.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

wowogiengen

Hallo,

jein... Im Originalbeitrag von Rampler (https://forum.fhem.de/index.php?topic=137857.msg1328107#msg1328107) ist das Register auch auf 35140, mit 16 Bit Länge :-)

In der Doku ist es in der Tat 32 Bit lang... ab 35139...

Mein Fehler... Dann stimmt aber "s>" nicht... brauch ich dann "n" bzw. "n>"?

Parallix

#8
Zitat von: wowogiengen am 05 September 2025, 20:20:46Hallo,

jein... Im Originalbeitrag von Rampler (https://forum.fhem.de/index.php?topic=137857.msg1328107#msg1328107) ist das Register auch auf 35140, mit 16 Bit Länge :-)

In der Doku ist es in der Tat 32 Bit lang... ab 35139...

Mein Fehler... Dann stimmt aber "s>" nicht... brauch ich dann "n" bzw. "n>"?


Irgendwo müsste hier doch eine Doku zu den Unpack-Codes zu finden sein, idealerweise im Wiki. Auf die schnelle finde ich sie nicht. Wenn ich mich nicht irre, so muss für big-endian S32 "l>" verwendet werden. Hier steht das "l" für "signed long" und das ">" für big-endian.

PS: Selber nutze ich in meiner Modbus-Konfigurationsdatei durchgängig eigene Typbeschreibungen via "dev-type-<name>-len" und "dev-type-<name>-unpack". Hierdurch wird die Konfiguration schneller und besser lesbar!

Bsp.:
dev-type-S32-len 2
dev-type-S32-unpack l>

und später dann z.B.

obj-h36025-reading meter_active_power_W
obj-h36025-type S32
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

wowogiengen

Zitat von: Parallix am 06 September 2025, 08:13:13Irgendwo müsste hier doch eine Doku zu den Unpack-Codes zu finden sein, idealerweise im Wiki. Auf die schnelle finde ich sie nicht. Wenn ich mich nicht irre, so muss für big-endian S32 "l>" verwendet werden. Hier steht das "l" für "signed long" und das ">" für big-endian.

Direkt in der Hilfe zum ModbusAttr steht ein bisschen was...
unsigned long bigunsigned long little
Damit habe ich es dann geschafft, den Wert anzuzeigen...

Gerade wundere ich mich aber über die Ausgabe des Web-Portals von GoodWe...
Für den großen 10kW Wechselrichter, dessen Module auf die Südseite schauen, bekomme ich angeblich nur 94 Watt Ausgangsleistung. Der kleine 5kW Wechselrichter, der halb/halb auf Ost und West ausgerichtet ist, bekommt aber 2060 Watt. Zusammen soll die Anlage aber 4549 Watt erzeugen.

Liegt aber vielleicht auch daran, dass es sich um  das bekannte Problem mit der mehrfachen Verbindung zum WR handelt :-)

Werde auf jeden Fall nachher mal das WLAN-Kit tauschen.


Parallix

Zitat von: wowogiengen am 06 September 2025, 09:55:03...
Gerade wundere ich mich aber über die Ausgabe des Web-Portals von GoodWe
...

Ganz ehrlich: Mit FHEM hast Du doch alle Möglichkeiten, um Dich unabhängig vom Webportal eines Hersteller, von unangekündigten Firmware-Updates sowie Modifikationen ohne Dein OK zu machen und Daten auch in hoher zeitlicher Auflösung zu bekommen. Sind das nicht genug Gründe, um sich aus einer Hersteller-Cloud zurückzuziehen?
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

wowogiengen

Hallo,
ist bisschen OT...,
Zitat von: Parallix am 06 September 2025, 21:27:15Ganz ehrlich: Mit FHEM hast Du doch alle Möglichkeiten, um Dich unabhängig vom Webportal eines Hersteller, von unangekündigten Firmware-Updates sowie Modifikationen ohne Dein OK zu machen und Daten auch in hoher zeitlicher Auflösung zu bekommen. Sind das nicht genug Gründe, um sich aus einer Hersteller-Cloud zurückzuziehen?

Das mag sein, aber ich bin nicht so fit, um mir FHEM nach meinen Wünschen so anzupassen, und es dann auch noch fail-safe hinzubekommen.
Bsp... Ich wollte mir eine FHEM-Instanz auf meinem Windows-PC installieren. Hab es nach der Anleitung gemacht, so dass Perl mit in das Verzeichnis installiert würde. Aber ich hab es nicht geschafft, fehlende Abhängigkeiten zu installieren - die Kompilierung brach immer wieder ab...

Dann gefällt mit der Plot nicht so toll, das was man mit plotly unter jupyter notebook zeichnen kann, sieht viel schöner aus, und lässt sich auch bequemer zoomen...

Eine eigene Web-UI hab ich mal angefangen zu machen, aber auch da muss man sich wieder erstmal einarbeiten...

Die vielen Stunden wo ich damit schon verbracht habe, verbringe ich lieber woanders :-)


Zurück zum Thema...
Ich habe zwei Wechselrichter:
  • GW10KN-ET, 10kW Peak
  • GW5000-ES-20, 5kW Peak, ist eigentlich ein 6kW (er meldet sich mit GW6000ES20) aber für DE wurde der gedrosselt und ist deswegen ein GW5000-ES-20...

Beim 10er bin ich mit dieser Definition ganz gut gefahren:
https://forum.fhem.de/index.php?topic=137857.msg1328107#msg1328107

Für den 5er passt das nicht so ganz, also hab ich Goodwe gefragt, welche Doku hierfür geeignet wäre.

Die ZIP-Dateien im Anhang sind das, was ich bekommen habe - PDF wäre bisschen zu groß gewesen, deshalb als ZIP gepackt...

Für den GW5000-ES-20 hat er mir die ARM_105_EM_ES_SBP_BP_Modbus_Protocol_Hybrid_EN_V2.8.pdf gesagt, aber wenn ich da nur das Modell und die Seriennummer auslese,
bekomme ich schon nichts.
Verwende ich die gleichen Register wie beim GW10KN-ET, stimmen die Werte...

Wer hat mit dem GW5000-ES-20 schon Erfahrungen gesammelt?

Viele Grüße
Wolfgang

Parallix

Zitat von: wowogiengen am 08 September 2025, 19:04:22Hallo,
ist bisschen OT...,
Zitat von: Parallix am 06 September 2025, 21:27:15Ganz ehrlich: Mit FHEM hast Du doch alle Möglichkeiten, um Dich unabhängig vom Webportal eines Hersteller, von unangekündigten Firmware-Updates sowie Modifikationen ohne Dein OK zu machen und Daten auch in hoher zeitlicher Auflösung zu bekommen. Sind das nicht genug Gründe, um sich aus einer Hersteller-Cloud zurückzuziehen?

Das mag sein, aber ich bin nicht so fit, um mir FHEM nach meinen Wünschen so anzupassen, und es dann auch noch fail-safe hinzubekommen.
Bsp... Ich wollte mir eine FHEM-Instanz auf meinem Windows-PC installieren.
...

Mein Tipp: Hol die für wenig Geld einen Banana- oder Raspberry und setze Dich ein wenig mit Linux und dessen Möglichkeiten auf Kommandozeilenebene auseinander. Wenn Du das hinter Dich gebracht hast, dann installierst Du FHEM auf dem System und spielst ein wenig mit unproblematischen Devices, die nur unidirektional betrieben werden können. Dann machst Du Dich langsam Deinen Goodwe via Modbus heran.
FHEM: Debian/Testing BananaPro - AVM: 7490 (7.60) und 7591 (8.20) - Goodwe: GW25K-ET (DSP V10 / ARM V12) - Trina TSM 405: (#East, #South, #West) = (12,16,12) - BYD: 2 x HVS 7.7 (BMS V3.31-B, BMU V3.26-B) - EnOcean - Z-Wave - FS20/HMS

wowogiengen

Ich mein,
grundsätzlich kenn ich mich mit raspy und Linux schon aus, aber trotzdem sind mir die Perl-, shell-, fhem- Sprachdialekte ein bisschen fremd.

Meine FHEM-Installation läuft ja jetzt auch schon seit einigen Jahren, aber eben nur die basics. Für die Creme de la creme müsste ich mich eben zu sehr
einarbeiten, und da weiß ich halt nicht, wie anfangen...

Ich hab mir schon mal gedacht, auf nem zweiten Raspy eine zweite FHEM-Instanz zu installieren, die sich dann mit fhem2fhem mit der Hauptinstanz verbindet.
Da müsste es ja dann möglich sein, Web-UI und andere Dinge (Daten akkumulieren, DB Wartung etc) damit auszuprobieren...