Sungrow SH15 Batterie Ladung wird nicht erkannt.

[Bluppy]

Describe the bug

Hallo zusammen,

ich habe den Sungrow Wechselrichter wie in der Anleitung in meine Konfig übernommen und er wird auch was Stromverbrauch angeht sauber erkannt.

Es wird aber nicht die Batteriepower abgefragt.
Im Homeassistent via Modbus hat es sauber geklappt und funktioniert dort.

Ich weiß nicht ob es ggf. ein Fehler wegen der "neuen" Modelle 15T und 20T der Fehler kommt. Im Forum ließt man nur das einbinden top sonst klappt. Der 15T und 20T hat das Modbus direkt über den WiNet-S2 als Funktion und durch Homeassistent sehe ich ja das es läuft.

Weiß ehrlich gesagt nicht was ich noch machen soll um den Sungrow einzubinden.
Auch die Batterie über ID2 zu wählen habe ich schon versucht. Weil das im WiNet auch noch möglich wäre die Batterie einmal über den Wechselrichter oder eben über die ID2 abzufragen

Steps to reproduce

geht direkt nicht.

Configuration details

app # evcc dump --cfg
[main  ] INFO 2025/01/18 16:12:51 evcc 0.132.1
[main  ] INFO 2025/01/18 16:12:51 using config file: /etc/evcc.yaml
[db    ] INFO 2025/01/18 16:12:51 using sqlite database: /.evcc/evcc.db
[lp-1  ] DEBUG 2025/01/18 16:12:55 charge total import: 7.870kWh

Konfiguration (/etc/evcc.yaml):

# open evcc at http://evcc.local:7070
network:
  schema: http
  host: evcc******* # .local suffix announces the hostname on MDNS
  port: 7070

log: debug
levels:
  cache: debug 

# unique installation id
plant: *****

interval: 30s # control cycle interval

sponsortoken: *****

# sponsors can set telemetry: true to enable anonymous data aggregation
# see https://github.com/evcc-io/evcc/discussions/4554
telemetry: false

meters:
- type: template
  template: sungrow-hybrid 
  id: 1  
  host: 192.168.***.200  
  port: 502  
  usage: grid  
  modbus: tcpip  
  name: grid1
- type: template
  template: sungrow-hybrid 
  id: 1  
  host: 192.168.***.200  
  port: 502  
  usage: pv  
  modbus: tcpip  
  name: pv2
- type: template
  template: sungrow-hybrid 
  id: 1  
  host: 192.168.***.200  
  port: 502  
  usage: battery  
  modbus: tcpip  
  name: battery3

#chargers:
#  - name: wallbox4
#    type: template
#    template: ocpp

chargers:
  - name: wallbox4
    type: template
    template: easee
    user: *****
    password: *****
    charger: EM*******
    timeout: 20s # optional
    authorize: # Steuert ob evcc die Authentifizierung am Charger vornimmt. Vorteil ist ein kontrollierter Ladestart. Nicht kompatibel mit RFID Identifikation von Fahrzeugen. (optional)



vehicles:
- type: template
  template: audi 
  title: Audi Q4****** 
  icon: car  
  user: *****
  password: *****
  vin: *****
  capacity: 77  
  phases: 3  
  cache: 60m  
  mode: pv  
  minCurrent: 6  
  maxCurrent: 16  
  priority: 1  
  name: audi
- type: template
  template: offline 
  title: KIA Ceed SW  
  icon: car  
  capacity: 8  
  phases: 1  
  mode: minpv  
  minCurrent: 6  
  maxCurrent: 16  
  priority: 2  
  name: kia

loadpoints:
- title: Garage
  charger: wallbox4
  mode: off

site:
  title: BergZone
  meters:
    grid: grid1
    pv:
    - pv2
    battery:
    - battery3


Version: `0.132.1`

/app #

Log details

[site  ] DEBUG 2025/01/18 16:03:09 ----
[lp-1  ] DEBUG 2025/01/18 16:03:09 charge power: 0W
[lp-1  ] DEBUG 2025/01/18 16:03:09 charge currents: [0 0 0]A
[site  ] DEBUG 2025/01/18 16:03:09 grid power: 2059W
[site  ] DEBUG 2025/01/18 16:03:09 pv 1 power: 270W
[site  ] DEBUG 2025/01/18 16:03:09 battery 1 power: 0W
[site  ] DEBUG 2025/01/18 16:03:09 grid currents: [1.18 5.55 2.52]A
[site  ] DEBUG 2025/01/18 16:03:09 battery 1 soc: 1%
[site  ] DEBUG 2025/01/18 16:03:09 site power: 2159W
[lp-1  ] DEBUG 2025/01/18 16:03:09 charge total import: 7.870kWh
[lp-1  ] DEBUG 2025/01/18 16:03:09 charger status: A

What type of operating system or environment does evcc run on?

Docker container

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

0.132.1

[nekronomekron]

Kann ich mit meiner SH96 Batterie nachvollziehen. Das Register für den Betriebsstatus wird nicht mehr aktualisiert. Eine Lösung ist, die Werte für Battery Voltage und Batterie Current zu verwenden. Entgegen der Doku ist der Strom bei mir mit Vorzeichen, also int16be, nicht uint16be. Damit kann man das gewohnte Verhalten wieder herstellen.

[andig]

Das Register für den Betriebsstatus wird nicht mehr aktualisiert

Was heisst „nicht mehr“? Ging das mal? Was hast du geändert? Was sagt

evcc meter

und welcher der Werte ist falsch?

[nekronomekron]

EVCC liest den Betriebsstatus im Register 13000 aus. Hier wird mit einer Bitmaske der Status ermittelt, ob geladen oder entladen wird. Ich lese in einem privaten Projekt auch den Batteriestatus aus und hab mich an EVCC orientiert, das hat bisher funktioniert. Vor kurzem gab es anscheinend ein automatisches Update, seit dem wird das Betriebsstatus Register nicht mehr aktualisiert und bleibt auf 0.

power:
    source: calc
    mul:
    - source: calc
      abs:
        source: modbus
        {{- include "modbus" . | indent 6 }}
        timeout: {{ .timeout }}
        register:
          type: input
          address: 13021 # Battery power
          decode: int16
    - source: calc
      add:
      - source: modbus
        {{- include "modbus" . | indent 6 }}
        register:
          type: input
          address: 13000 # Battery running state
          decode: bool16
          bitmask: 2 # Charging
        scale: -1
      - source: modbus
        {{- include "modbus" . | indent 6 }}
        register:
          type: input
          address: 13000 # Battery running state
          decode: bool16
          bitmask: 4 # Discharging

Das heisst, das Ergebnis für die bool16 Werte ist IMMER 0 und multipliziert damit die aktuelle Leistung, EVCC liest also für die Leistung einfach 0.

Die Lösung ist, die aktuelle Spannung und den aktuellen Strom auszulesen und diese zu multiplizieren. Entgegen der Doku ist der Strom-Parameter Vorzeichenbehaftet, man muss also nicht auf den Betriebsstatus gehen.

{
    "modifier": "mul",
    "values": [
        {
            "address": 13019,
            "size": 1,
            "datatype": "uint16be",
            "scale": 0.1
        },

        {
            "address": 13020,
            "size": 1,
            "datatype": "int16be",
            "scale": -0.1
        }
    ]
}

[andig]

Ok, also von Sungrow kaputt gemacht. Wissen wir, ob das alle Modelle betrifft? Magst Du einen PR machen?

/cc @naltatis kannst Du das bestätigen?

[nekronomekron]

Ok, also von Sungrow kaputt gemacht. Wissen wir, ob das alle Modelle betrifft? Magst Du einen PR machen?

Ob das alle betrifft kann ich leider nicht zu 100% sagen, ich denke aber ja, da die Hybrid WR bei Sungrow von der Schnittstelle her bisher auch gleich waren. Die HV-Batterien von Sungrow sind im Kern auch nur das gleiche Modul, nur mal oder weniger oft gestapelt.

Klar, ich erstell einen PR (wird mein erster, ich hoffe ich mach nichts falsch)

[andig]

Tip: Du kannst die Tempaltedatei einfach hier in GH bearbeiten und daraus den PR erzeugen- dafür brauchts keine lokale Installation. Vielen Dank!

[Bluppy]

Das hört sich ja gut als lösung an. Doofe frage wo finde ich die EVCC Program Files im Dockercontainer? Würde gerne mal den Code Change der YAML datei bei mir ausprobieren und finde die sungrow-hybrid.yaml nicht.

[Funkymaddox]

Habe einen SH20T mit SBH150.
Das Thema Register 13000 (adressiert 13001) ist bei Sungrow leider groß. Im PV Forum gibts dazu in zwei Topics lange Posts von mir incl Fehlerbilder, Erklärung und co.

Bei mir lief bis vor 3 Tagen meistens das Reg 13000 noch, und der Fehler mit dem Wert "0" trat nur 3-4 mal am Tag für einige Minuten auf. Dass er komplett bei "0" blieb war nicht der fall!

Ende vom Lied: WiNet-S2 Dongle war bei mir der Flaschenhals. Ob die Hardware der Flaschenhals ist oder ein FW Update helfen kann bleibt offen. Wie du bei der Lösung unten nachlesen kannst: RS485toETH Adapter am Loggerport is the way to go!

Problem:
https://www.photovoltaikforum.com/thread/206458-sungrow-sammelthread-shxxt-15-25kva-mit-sbh100-400-batterie/?postID=4096709#post4096709

Doktorarbeit Vorbereitung:
https://www.photovoltaikforum.com/thread/166134-daten-lesen-vom-sungrow-wechselrichtern-modbus/?postID=4096908#post4096908
https://www.photovoltaikforum.com/thread/166134-daten-lesen-vom-sungrow-wechselrichtern-modbus/?postID=4097065#post4097065
https://www.photovoltaikforum.com/thread/166134-daten-lesen-vom-sungrow-wechselrichtern-modbus/?postID=4099248#post4099248

Fehlerbeweis:
https://www.photovoltaikforum.com/thread/166134-daten-lesen-vom-sungrow-wechselrichtern-modbus/?postID=4101906#post4101906

Lösung:
https://www.photovoltaikforum.com/thread/206458-sungrow-sammelthread-shxxt-15-25kva-mit-sbh100-400-batterie/?postID=4124036#post4124036

Erklärung Waveshare:
https://www.photovoltaikforum.com/thread/206458-sungrow-sammelthread-shxxt-15-25kva-mit-sbh100-400-batterie/?postID=4124625#post4124625

[andig]

Auf rs485 gelten also die alten Register?

[zachelnet]

@nekronomekron
bezüglich deine Änderung ist diese für die neue Hybrid Wechslrichter SHxT Serie oder funktioniert diese auf der alte SHxRT Serie. Zu not müssten wir zwei verschiede Templates bauen.

[Funkymaddox]

Bild von heute, 19.01.25 21:21
Entladung der Batterie wird normal angezeigt. Schätze also Ja, RS485 Output unverändert.
Oben steht leider nur "vor Kurzen geändert". Bis zum 16.01.25 hatte ich beides für ca. eine Woche parallel laufen.
EVCC via WiNet-S2 Dongle und ein Tablet mit ioBroker über RS485 Adapter zum Auslesen der Register.
Bei beiden war bis zum 16.01. nie permanent der Wert "0". Bei EVCC über den Dongle trat der Fehler mehrmals täglich für 10-25 Minuten auf, über RS485 nie die "0"! Heute, sprich seit 17.01. EVCC über RS485, keinerlei Probleme in den Anzeigen, auch bei Batterie Ladung!

EVCC 0.132.1
SH20T .28
WiNet-S2 .16

[zachelnet]

Das hört sich ja gut als lösung an. Doofe frage wo finde ich die EVCC Program Files im Dockercontainer? Würde gerne mal den Code Change der YAML datei bei mir ausprobieren und finde die sungrow-hybrid.yaml nicht.

um Änderung zu übernehmen muss du ein neuen Container bauen:

git clone https://github.com/evcc-io/evcc.git
cd evcc
make docker
#alternative
podman build . # -t evcc:build # mit t kannst du einen eigen Tag vergeben

fürs binary

make

Die yaml für sungrow-hybrid findes du unter templates/definition/meter/sungrow-hybrid.yaml

[nekronomekron]

@zachelnet Ich hab einen SH8.0RT mit Firmware Version SAPPHIRE-H_01011.95.03.

Ich hoffe dass die neuen Parameter auch mit dem neuen Wechselrichter funktionieren, dann müssen nicht zwei Templates her.
Den Weg über das native Interface hab ich auch schon gelesen, der ist bei meinem WR aber ne richtige Zicke (da bin ich auch nicht alleine..). Bei zuvielen Anfragen stürzt er ab, kappt einfach die Verbindung, ist im Netz nicht zu finden.. Winet-S hat da bis jetzt am stabilsten funktioniert. Die Register sollten aber direkt am WR und über Winet-S identisch sein. Wenn die Berechnung über V*A über Winet-S funktioniert, dann sollte es am WR klappen. Das wäre ideal.

[zachelnet]

@nekronomekron hab auch ein SH8.0RT,
ich test mal dein Change an beide Ports und gibt dann bescheid. Die Frage ist wie es mit ältern Firmware-Versionen aussieht.

hab selbst die aktuellste Firmware:
WINET: WINET-SV200.001.00.P030
MDSP: SAPPHIRE-H_03011.95.03

[zachelnet]

@nekronomekron also bei mir Klapps auch an beiden Ports, die frage ist wie es bei den WINETS2 und SH_T aussieht

[zachelnet]

@zachelnet Ich hab einen SH8.0RT mit Firmware Version SAPPHIRE-H_01011.95.03.

Ich hoffe dass die neuen Parameter auch mit dem neuen Wechselrichter funktionieren, dann müssen nicht zwei Templates her. Den Weg über das native Interface hab ich auch schon gelesen, der ist bei meinem WR aber ne richtige Zicke (da bin ich auch nicht alleine..). Bei zuvielen Anfragen stürzt er ab, kappt einfach die Verbindung, ist im Netz nicht zu finden.. Winet-S hat da bis jetzt am stabilsten funktioniert. Die Register sollten aber direkt am WR und über Winet-S identisch sein. Wenn die Berechnung über V*A über Winet-S funktioniert, dann sollte es am WR klappen. Das wäre ideal.

Die frage ist nur wie mit den alten Wechselricht umgehen, (einfach übergehen ist auch keine Lösung bevor noch weiter issues eröffnet werden). Dazu gabs auch eine discousion #17461 (comment), deswegen hatte ich es damals es mit abs gelöst, aber wenn bei der neuer Serie mit Registrie 13000 problem gibt, sollte wir uns überlegen wie wir diese lösen.

• per seperates template,
• per if else entsprech das template gestallten. Die Frage wäre wie die unterschiedliche Firmware-Versionen zu unterscheiden wäre.
• warte bis sungrow dies gepatch hat (kann ein bischen dauern) und eine neue Firmware für WiNetS2 rausgebracht hat

[nekronomekron]

Das kann leider sehr gut sein, dass die Änderung mit dem letzten Update kam und vor dem Update das Register für den Batteriestrom noch uint16 ist und damit für die Kalkulation unbrauchbar.

Leider kann ich das nicht testen, hier bräuchten wir kurz jemanden mit einer älteren Firmware (das Update kam erst vor ca. 1 Woche auf meinen WR).

Ich denke die Firmware Version wird man nicht automatisch ermitteln können. Sollten sich die Register unterscheiden, wird man 2 Templates benötigen die der User manuell wählen muss.

[wapman1979]

ich könnte ggf. testen.
meine fw sollte noch nicht aktualisiert sein:
MDSP-Softwareversion: PEARL-H_03011.01.21
und M_WiNet-S2_V01_V01_A

[naltatis]

@wapman1979 hier ist der PR mit der Änderung: #18284

[wapman1979]

@naltatis @andig @nekronomekron @zachelnet @Funkymaddox @Bluppy
tatütata es funktioniert (endlich) wunderbar auf meinem SH15T :-)

den "Scale" Wert in Zeile 130 hatte ich nicht geändert, also "0.1"

das ist ein issue, das seit einiger zeit immer wieder aufkommt:
bsp: #10690 oder hier von mir: #15915
Ich denke, da würden sich einige sungrow SHXXT user freuen, wenn man das stable bekommen könnte.

[premultiply]

Ich denke, da würden sich einige sungrow SHXXT user freuen, wenn man das stable bekommen könnte.

Da müsstest du dich wohl eher an Sungrow halten.

Es fällt hier schwer den Überblick zu behalten angesichts der sich stetig ändernden Firmwarefunktion hinsichtlich der Batterieleistung.

[Funkymaddox]

Ich bin ganz ehrlich: Habe den Überblick verloren. Keine Ahnung, wo das Problem lag, wie der Stand ist und warum überhaupt dieses Topic existiert.
Bei mir (SH20T, sollte identisch zu SH15T sein) lief die Batterie(ent)ladungserkennung seitens EVCC mit WiNetS2 Dongle und auch mit RS485 Adapter schon seit Inbetriebnahme Nov24. Bei WiNetS2 gab es nur temporäre, kurze selbst lösende, "Aufhänger" und der Adapter liefert einfach hochfrequenter, stabilere und fehlerfreie Werte.

Bei Issue #10690 gehts um den SHxxRT...
Eigentlich warte ich nun nur darauf, dass irgendwas an EVCC verändert wird und es dadurch bei mir am Sh20T nicht mehr geht... :D
Aber schön, dass es nun auch bei dir geht.

[wapman1979]

Mir scheint es so, als ob sungrow schon langezeit mit der modbus ausgabe, der doku dazu, etc murkst.
mit der shxxt serie haben sie winet-s2 ist ganz neu entwickelt, inkl. 3x modbus am lan.
wobei das mit dem Reg 13000 nicht mehr so wie bei den SHxxRTs geklappt hat. außer man ist über einen rs485 adpater gegangen. eigentlich stand das sogar in der doku, dass Reg 13000 am WiNet.S2 beim SHxxT anders konfiguriert sind.

evcc hat das nicht geändert, weil das sungrow-hybrid.yaml auch für die alte SHxxRT genutzt wird und auf den (sicherlich vielen installierten) SHxxRT Modellen hat es mit den Charge/discharge (über den LAN am WL) funktioniert.
Jetzt mit der latest Firmware, hat sungrow das Verhalten des WL LAN an den SHxxRT an den des WiNet-S2 für die SHxxT Serie angepasst.

Es wird sicherlich SHxxRT Nutzer geben, die bewusst die firmeware nicht upgraden, weil es aktuell stabil läuft.
@andig & @nekronomekron daher denke ich, sollte man in Erwägung ziehen, eine zweite Config Datei zu nutzen

• Die sungrow-hybrid.yaml mit der bisherigen Reg 13000, für die SHxxRT Geräte bis zur FW vor der aktuellsten.
• Eine sungrow-hybrid-new.yaml: mit den änderungen des PR Sungrow: fix battery charge/discharge power #18284 die gilt dann für alle SHxxT und die SHxxRTs mit der neuen FW.

Man muss selber aktiv werden, wenn man die neue Config nutzen muss/will.
Etwa wenn man das SHxxRTs Upgrade bekommen hat.
Ansonsten bleibt alles beim Alten.

[zachelnet]

@wapman1979 sehe ich genauso dass es auf ein zweites Template hinausläuft,

[nekronomekron]

"Das ist der Weg" würde ein berühmter Kopfgeldjäger jetzt sagen. Denke auch dass es nicht ohne 2 Templates gehen wird. Über Modbus hab ich keinen Weg gefunden, die FW Version auslesen zu können.

[naltatis]

Für den Fall, dass wir wirklich ein zweites Template machen (aus Nutzersicht immer echt doof) müssten wir ja erklären wie man rausfindet ob man das "alte" oder das "neue" Template nehmen muss. Mir ist das gerade noch nicht klar genug. Gerade weil hier ja der Anschluss und(!) die Firmware-Version eine Rolle spielt. Könnt ihr das einmal so konkret wie möglich zusammenfassen.

Altes Template nutzen, wenn ...

[zachelnet]

@naltatis denk folgendes würde es gut erklären:

• altes Template nur noch für SHxxRT WR bei ältere Firmware also (älter als WINET-SV200.001.00.P030)
• Neues Template für beide WR-Serien
  • SHxxT (neue Serie) WiNet-S2 Dongle
  • SHxxRT (alte Serie) mit der Firmware ab WINET-SV200.001.00.P030 (ca. Jan. 2025) aufwärts

@nekronomekron, @wapman1979, @Funkymaddox: Was haltet ihr von der Erklärung, habt ihr noch etwas hinzu zu fügen?

[andig]

fwiw: beim letzten Template-Gen-War kam am Ende -gen2 als neuer Name raus ohne Erläuterung wann es einzusetzen sei weil es schlicht niemand wusste...

[nekronomekron]

@nekronomekron, @wapman1979, @Funkymaddox: Was haltet ihr von der Erklärung, habt ihr noch etwas hinzu zu fügen?

Find ich gut. Man könnte in die Doku mit aufnehmen zuerst die neue Version zu verwenden und sollte die Batterie nicht ausgelesen werden können auf ein Firmwareupdate hinweise oder eben das "alte" Template zu verwenden. In diesem Fall kann man den Unterschied klar benennen: Wird die Batterie nicht ausgelesen, dann das andere Template verwenden und nochmal versuchen.

[zachelnet]

@andig ein Template-Gen-War will ich hier nicht anzetteln. Mit "-gen2" kann ich gut leben.

[wapman1979]

Das hört sich doch nach einen guten Plan an 👍 Lag mir quasi identisch auf der Zunge.
„- gen2“ hört sich auch gut an und bietet Spielraum nach oben.

Go for it!

[nekronomekron]

Ich hab das neue Template im PR ergänzt und das alte Template widerhergestellt. Gerne mal drüber sehen ob das so passt. Ich hoffe die Templates müssen nicht irgendwo "registriert" werden.

[wapman1979]

@nekronomekron
ich grübel gerade noch über einen alternativ vorschlag für die beschreibung:

" description:
de: Verbindungen über das WiNet-S-Dongle (WiFi oder LAN) funktionieren nur mit aktueller Firmware. Ältere Versionen liefern nicht alle benötigten Daten (Leistung, Ladestand)."

weiß nicht so recht ob das aus user sicht optimal formuliert ist...
da gibt es ja auch noch den "WiNet-S2-Dongle"
modbus an der SHxxRT serie war nur über den LAN am WL möglich, der ist doch auch betroffen, oder?

Das ist zum einen nur in der yaml zu sehen, und ggf. irgendwo & irgendwann in der GUI, oder?
Wird das auch als Info auf evcc.io genutzt?

[wapman1979]

@nekronomekron, @andig, @naltatis & @premultiply als Ergänzung zu oben:

Ich denke, diese Bereiche in der Doku müssten entsprechend angepasst werden.

Da hier die gleiche Description in der Doku, wie in der yaml verwendet wird, zielte meine Frage eben dahin, ob ihr den Content der Doku direkt aus der Codebase zieht oder ob der Doku Content separat gepflegt wird?

In jedem Fall, muss es umformuliert werden.
Hier heißt es ja "nur mit aktueller Firmware", was nicht stimmen kann, weil dafür braucht man ja jetzt "-gen2" ...

[premultiply]

Ja, wird aus dem Template generiert.

[wapman1979]

Ich fand die Description der syngrow-hybrid.yaml schon bei Config meines SH15T etwas verwirrend.
Ggf. hilft es anderen evcc Usern, wenn wir das klarer hinbekommen.

Da die syngrow-hybrid.yaml (ich nenne sie jetzt mal legacy) im Wesentlichen für die RT Serie mit der bisherigen FW relevant ist, bin ich mir nicht sicher, ob das so, wie das aktuell formuliert ist, wirklich stimmig ist.

Soweit ich in den Foren letztes Jahr noch gelesen habe, ist Modus nur am WL LAN, also nicht via WiFi, und RS485toETH Adapter verfügbar.
Siehe Darstellung unten @zachelnet du hast einen RT, soweit ich gelesen habe. Kannst du das verifizieren?

[nekronomekron]

@wapman1979 Ich schau mir heute Abend die Text mal an und überleg mir eine passendere Beschreibung.

Zu dem anderen Thema hat Sungrow aber anscheinend vorher schon einiges geändert ohne dass es aufgefallen ist. Bis zum Jahreswechsel hab ich ohne Probleme meinen SH8.0-RT über WiNet-S ausgelesen. Auch die Batterieinfos. Das wurde erst im Januar heuer mit der neuen Firmware gekippt. Zuvor ging es aber. Scheint als habe Sungrow vorher schon ein Update für die WiNet-S Dongles rausgebracht, da ich hier nie Probleme hatte.

Den nativen LAN Anschluss hab ich nicht verwendet, da der seeeeehr zickig war. Kamen zuviele/falsche Abfragen ist der oft einfach Abgestürzt und war bis zum Neustart des WR nicht mehr erreichbar. Der Zugang über WiNet-S ging aber problemlos und auch mit den Batterieladedaten bei mir von Beginn an (Ende 2023).

[zachelnet]

@wapman1979 Ja, ich habe ein RT, ich benutze derzeit den WiNet Dongle über WiFi (soweit ich weiß, macht es keinen Unterschied, ob LAN oder WiFi, solange die Verbindung gut ist), der native Port funktioniert auch, ich benutze ihn nur ungern, da er keine gleichzeitigen Zugriffe unterstützt.

[wapman1979]

danke @nekronomekron & @zachelnet für euer Feedback. Korrekt müsste es dann so dargestellt sein:

Welche Firmware ist denn eigentlich für den Switch zu Gen2 relevant?
Nur die WINET? Oder auch die für den WL?
Haben Benutzer, die über einen RS485toETH Adapter Modbus abfragen, die gleichen Issues?

[wapman1979]

Sorry, dass ich euch so zu spamme hier … habe heute etwas Zeit mich damit zu beschäftigen :-)

Ich habe jetzt im PV-Forum einen Beitrag gefunden, der die noch funktionierende Firmware-Version korrekt benennen sollte:
https://www.photovoltaikforum.com/thread/240017-sh10rt-20-probleme-nach-upate/?postID=4085024#post4085024

@nekronomekron auf Basis dessen habe ich jetzt folgenden Draft für die Description aufgesetzt:

Für Sungrow Hybrid Wechselrichter der RT-Serie (SHxxRT und SHxxRT-20) bis einschließlich WiNet-S Firmware-Version WINET-SV200.001.00.P027 mit SAPPHIRE-H_03011.95.01 (MDSP) und SAPPHIRE-H_01011.95.01 (LCD).
Modbus Verbindungen sind via WLAN am WiNet-S Dongle, dem LAN-Anschluss des Wechselrichters oder mittels eines RS485toETH Adapters möglich.
Benutzer der RT-Serie mit neuerer Firmware (Bsp. WINET-SV200.001.00.P030) müssen das Template sungrow-hybrid-gen2 verwenden.

Bei Sungrow Hybrid Wechselrichter der T-Serie (SHxxT) können die Werte zur Batterie Ladung bzw. Entladung unter Umständen nicht angezeigt werden. In diesem Fall kann die Verwendung des Templates sungrow-hybrid-gen2 getestet werden.
Wechselrichter der SHxxT Serie können Modbus Verbindungen mittels WiNet-S2 Dongle via WLAN und LAN oder über einen RS485toETH Adapter zu evcc herstellen.

Bei meiner Recherche bin ich im Übrigen auf einen CVE in der WINET-SV200.001.00.P027 gestoßen:
GHSA-gxmw-34m7-64r8
@andig daher vermute ich, wird Sungrow das Update auf die P030 auf allen Geräten pushen, die das nicht unterbinden.

[andig]

Könnt ihr bitte aufhören, mich hier ständig rein zu ziehen? Ich habe das Gerät nicht und kann dazu nichts beitragen. Danke.

[nekronomekron]

@wapman1979 Ich finde die Descriptions gut. Wenn das auch für die Maintainer so passt würde ich die so in den PR übernehmen und wir wären bei dem Thema ein gutes Stück weiter gekommen.

[wapman1979]

@nekronomekron
Soll die Gen2 auch gleich mit veröffentlicht werden?
Dann bräuchten wir da auch noch die Beschreibung.

[nekronomekron]

@wapman1979 Hier würde ich den gleichen Text nehmen, nur mit dem Hinweis dass diese AB der neuen Firmware Version verwendet werden kann. Und sollte die Batterieladeleistung nicht ausgelesen werden, das „alte“ Template verwendet werden soll.

[wapman1979]

@nekronomekron hier mal eine EN version für legacy.
For Sungrow RT series hybrid inverters (SHxxRT and SHxxRT-20) with WiNet-S firmware version WINET-SV200.001.00.P027 and SAPPHIRE-H_03011.95.01 (MDSP) and SAPPHIRE-H_01011.95.01 (LCD) and earlier.
Modbus connections are possible via WLAN on the WiNet-S dongle, the inverter's LAN connection or via an RS485toETH adapter.
Users of the RT series with newer firmware (e.g. WINET-SV200.001.00.P030) must use the sungrow-hybrid-gen2 template.
For Sungrow Hybrid inverters of the T-series (SHxxT), the values for battery charge and discharge may not be displayed under certain circumstances. In this case, the use of the template sungrow-hybrid-gen2 can be tested.
Inverters of the SHxxT series can establish Modbus connections to evcc using a WiNet-S2 dongle via WLAN and LAN or via an RS485toETH adapter.

[wapman1979]

@nekronomekron und das ist mein Vorschlag für die gen2 Beschreibungen:
DE
Für Sungrow Hybrid Wechselrichter der RT-Serie (SHxxRT und SHxxRT-20) mit der WiNet-S Firmware-Version WINET-SV200.001.00.P030 mit SAPPHIRE-H_03011.95.03 (MDSP) und SAPPHIRE-H_01011.95.03 (LCD) und ggf. auch später.
Modbus Verbindungen sind via WLAN und LAN am WiNet-S2 Dongle oder mittels eines RS485toETH Adapters möglich.
Sowie für Wechselrichter der SHxxT Serie, diese können Modbus Verbindungen mittels WiNet-S2 Dongle via WLAN und LAN oder über einen RS485toETH Adapter zu evcc herstellen.

EN
For Sungrow hybrid inverters of the RT series (SHxxRT and SHxxRT-20) with the WiNet-S firmware version WINET-SV200.001.00.P030 with SAPPHIRE-H_03011.95.03 (MDSP) and SAPPHIRE-H_01011.95.03 (LCD) and possibly also later.
Modbus connections are possible via WLAN and LAN on the WiNet-S2 dongle or using an RS485toETH adapter.
As well as for inverters of the SHxxT series, these can establish Modbus connections to evcc via WLAN and LAN using a WiNet-S2 dongle or via an RS485toETH adapter.

[zachelnet]

Ist das nicht etwas lang? Ich würde empfehlen, die Aussagen kurz und prägnant zusammenzufassen, sonst liest das keiner und ehrlich gesagt verwirren mich die komplexen Aussagen auch:

Im Großen und Ganzen kann man sagen
legacy:

Für älter Firmwarestand vor Nov./Dec 2024 beim Wechselrichter SHxxRT(-20) mit native Port.
SHxxT eingeschränkt über RS485toETH. -> würde ich weglassen da SHxxT über gen2 mit WiNeT Dongel machbar ist.
Verbindungen über das WiNet-S-Dongle (WiFi oder LAN) funktionieren nur mit aktueller Firmware V030P001 würde ich auch weglassen da bei der Auswahl auf gen2 gehen sollte

gen2:

Nutzbar bei aktuller Firmware. Insbesondere über die Verbindung mittels WiNET-S(2) Dongle
bei den Wechselrichter SHxxT (aktueller Firmware ist V016P001) und SHxxRT(-20) (ab oder neuer als Firmware V030P001) nutzbar. Nativer Port möglich aber nicht zu empfehlen.

[wapman1979]

@zachelnet ja, in der kürze liegt die würze...
Wobei ich mir hier wieder schwierig tue, weil du andere FW Bezeichnungen nutzt...
Das liegt aber vermutlich eher an dem kudelmudel von sungrow.

Ich denke, im Wesentlichen geht es um die WiNet FWs.
Nur für den nativen LAN-Port und die RS485-Schnittstelle sollte FW der Inverter eine Rolle spielen.
Vielleicht kann man bei der Angabe der FW-Versionen ggf mal. "getestet mit" schreiben, statt "bis" oder "ab".

Ein Entwurf für Legacy:

Für SHxxRT-Serie und Modbus via WLAN: Bis einschließlich WiNet-S Firmware-Version WINET-SV200.001.00.P027
Für SHxxRT-Serie und Modbus via nativen LAN oder RS485: bis SAPPHIRE-H_03011.95.01 (MDSP) und SAPPHIRE-H_01011.95.01 (LCD).

Benutzer der RT-Serie mit neuerer Firmware (Bsp. WINET-SV200.001.00.P030) müssen das Template sungrow-hybrid-gen2 verwenden.

Für SHxxT und Modbus via LAN/WLAN: getestet mit WINET-SV300.001.03.P0XXX
Für SHxxT und Modbus via RS485 bis PEARL-XXXXX (Hier müsste die aktuelle version rein, ich habe noch ältere bei mir drauf)

wobei ich meine, das wichtigste ist, dass das möglichst bald rausgeht. die wordings sollten hier nicht blocken.

[wapman1979]

@zachelnet hier noch mehr eingekürzt als entwurf für die gen2:

SHxxRT-Serie, Modbus via WLAN: ab WINET-SV200.001.00.P030
SHxxRT-Serie, Modbus via nativen LAN oder RS485: SAPPHIRE-H_03011.95.03 (MDSP) und SAPPHIRE-H_01011.95.03 (LCD)

SHxxT und Modbus via LAN/WLAN: getestet mit WINET-SV300.001.03.P016
SHxxT und Modbus via RS485: ab PEARL-XXXXX

[nekronomekron]

Ich finde das mit den ganzen Firmware Versionen leider viel zu verwirrend als User. Das liest keiner, das wäre meine Erfahrung.

Ich würde folgendes Vorschlagen:
Um was geht es? Wir wollen dem User möglichst kurz und prägnant mitteilen, dass es 2 Versionen gibt. Wenn nicht alle Features funktionieren soll er einfach die jeweils andere Version verwenden.

sungrow-hybrid.yaml
Nutzbar bei älterer Firmware. Insbesondere über die Verbindung mittels WiNET-S(2) Dongle
bei den Wechselrichter SHxxT und SHxxRT(-20) nutzbar mit Firmware bis 12.2024. Nativer Port möglich aber nicht zu empfehlen. Werden nicht alle Daten ausgelesen (Batterieladeleistung), das Template 'sungrow-hybrid-gen2' verwenden.

sungrow-hybrid-gen2.yaml
Nutzbar bei aktueller Firmware. Insbesondere über die Verbindung mittels WiNET-S(2) Dongle
bei den Wechselrichter SHxxT und SHxxRT(-20) nutzbar mit Firmware ab 01.2025. Nativer Port möglich aber nicht zu empfehlen. Werden nicht alle Daten ausgelesen (Batterieladeleistung), das Template 'sungrow-hybrid' verwenden.

[premultiply]

Ich hab unter #18473 ein Konzept erstellt, was theoretisch weiterhin mit einem Template funktionieren könnte.

Idee dahinter: Alle bekannten Vorzeichenquellen werden (je ein Bit) werden logisch ODER verknüpft und auf den Leistungswert angewendet.

[wapman1979]

@nekronomekron das sehe ich genauso wie du, das sollte Zielgruppen bzw. User orientiert formuliert sein.
Nur leider ist die Frage nach der relevanten Zielgruppe in der Regel gar nicht so klar zu beantworten.

• So wie ich es in Foren wahrnehme, sind da viele IT-interessierte dabei, die trauen sich zu einen Hub/etc ins Netzwerk zu bekommen und via YAML zu konfigurieren, auch wenn das die ersten Berührungspunkte damit sind.
• Dann gibt es sicherlich einen sehr relevanten Teil, die im IT-Business unterwegs sind, schon den einen oder anderen Raspberry Pi oder HA zu Hause haben und sich mit der Materie ordentlich auskennen.
• Dritte Zielgruppe sehe ich Installateure oder den professionellen Einsatz. 

Wie würdet ihr die evcc.io User grob clustern?

Ich glaube, über alle Zielgruppen hinweg sollte man klar referenzieren, welche Konfiguration im Prinzip funktionieren sollte. Hintergrund ist der, dass wenn etwas nicht wie geplant funktioniert und man auf Fehlersuche geht, dann ist es hilfreich, wenn man an einem Punkt möglichst klar weiß, dass eine gewisse Config funktioniert. Konkret auf diesen Case bezogen, hieße das für mich:
Sungrow SHxxRT, via WLAN und WiNet FW WINET-SV200.001.00.P027 mit der Legacy YAML ist erfolgreich getestet.

Klares Referenzieren bedeutet für mich, die FW zu benennen, wo möglich. Mit den Datumsangaben wäre ich vorsichtig. Da ist einfach Interpretationsspielraum drinnen, den kann ich in einer Doku nicht haben.

@premultiply natürlich ist der Ansatz, ein Eier legendes Wollmilchsau yaml für alle Sungrows zu haben verlockend.
Ich würde euch in der aktuellen Situation davon jedoch abraten.
Die aktuelle Config-Yaml funktioniert – ich vermute – auf einer mind. vierstelligen Anzahl an Invertern (weltweit).
Don't touch that running system!

Ich sehe ein generelles Risiko, bei der Codeänderung an der Legacy YAML, dass für Teile der Nutzer Probleme auftreten.
Dieses Risiko kann man m. E. zu 100 % mitigieren, indem man den Weg über die Gen2 geht.

[naltatis]

Wenn es Aussicht darauf gibt das Ganze weiterhin mit einem Template lösen zu können sollten wir das auf jeden Fall prüfen. Man merkt ja an der Diskussion hier schon, dass der 2-Templateweg alles andere als trivial zu erklären ist.

[wapman1979]

@naltatis Ich würde in einer Art Transition Phase, das Gen2 (in dem Fall dann ein yaml, das "beide" templates vereint) als "eperimental" zur Verfügung stellen und das legacy yaml zunächst so belassen, um kein risiko einzugehen, dass es bei aktiven installationen zu komplikationen kommt.
Dann erstmal schauen ob diese "Gen2" auf einem größeren Nutzerkreis Issues verursacht.

btw: ich habe mir die FW Versionen nochmal anders visualisiert. vielleicht hilft es jemanden ja mal ...

@Funkymaddox hast du vielleicht WINET-SV300.001.03.P014 als "ZIP" am Rechner liegen? Ich vermute mal nicht, zum Zeitpunkt des Releases waren die Firmwares schon nicht mehr auf GH verfügbar ... oder?
Mein Installteur kann mir nur die neueste laden. ich würde gerne noch mit der vorletzten version spielen
ich bin noch auf WINET-SV300.001.03.P012.
falls jemand PEARL-H_B000.V000.P028-20240427 braucht (das sollte PEARL-H_03011.01.28 sein), die habe ich noch in meinen downloads gefunden :-)