EVCC - Sungrow SHxx Hybrid Inverter - Batterie- Werte werden nicht vollständig gelesen

[ApophisXX]

Hallo an alle Leser,
ich habe das Problem, dass an meinem Sungrow SH20 Hybrid WR, einige Werte der angeschlossenen Batterie nicht im Web Interface von EVCC angezeigt werden.

Ich bekomme von der Batterie nur den SoC, aber keinen Ladestrom oder Entladestrom. Wenn die PV Anlage die Hausbatterie lädt, wird das im Web Interface als Hausverbrauch angezeigt, ohne aufgeschlüsselt zu werden.
Wie schon hundertfach beschrieben, ist der WR via LAN Port angeschlossen. (Nicht der WiNET Dongle).

Es gibt ein sungrow-hybrid template in GitHub, dass das Problem eigentlich angehen soll, bekomme es aber nicht zum laufen.

https://github.com/evcc-io/evcc/blob/ed6e6bbecc461be5a9ada5d0d7c67166c917acaf/templates/definition/meter/sungrow-hybrid.yaml

Meine funktionierende config sieht aktuell so aus:

meters:
- type: template
  template: sungrow-hybrid 
  id: 1  
  host: 192.168.178.169  
  port: 502  
  usage: grid  
  modbus: tcpip  
  timeout: 30s  
  name: grid1
- type: template
  template: sungrow-hybrid 
  id: 1  
  host: 192.168.178.169  
  port: 502  
  usage: pv  
  modbus: tcpip  
  timeout: 30s  
  name: pv2

- name: Hausbatterie
  type: template
  template: sungrow-hybrid
  usage: battery 
  modbus: tcpip 
  id: 1  
  host: 192.168.178.169  
  port: 502      
  timeout: 30s
  capacity: 16 # Akkukapazität in kWh (optional)  
  

chargers:
- type: template
  template: sungrow 
  id: 3  
  host: 192.168.178.169  
  port: 502  
  modbus: tcpip  
  name: wallbox4

loadpoints:
- title: Sungrow Wallbox
  charger: wallbox4
  mode: pv

vehicles:
- name: ev1
  type: template
  template: bmw
  user: xxx
  password: xxx
  vin: Wxxx
  title: BMWi3
  icon: car
  capacity: 42
  phases: 3
  mode: pv
  minCurrent: 3
  maxCurrent: 16
  cache: 15m
  region: EU
  hcaptcha: xxx
  welcomecharge: true
  

site:
  title: PV Haus
  residualPower: 400
  meters:
    grid: grid1
    pv:
    - pv2
    battery:
    - Hausbatterie

[zachelnet]

Hi,
ich geh mal davon aus das du einer der neueren SH20T hast? Das Template hatte ich damals für den Fehler bei meinen SH8.0RT behoben und geteste.

Laut Dokumentation von Sungrow sollten im großen und ganzen die Registry von den SH5.0RT/SH6.0RT/SH8.0RT/SH10RT und SH5-25T identisch sein.

Könntest du schauen welche Bits im Register 13000 beim laden und Entladen der Battery gesetzt sind, am besten von beiden ports. Da die Bits für die Berechnung des Vorzeichen verwendet wird.
bitmask 2 wird genutzt fürs Charging ( -1)
bitmask 4 wird genutzt fürs Discharging ( +1) (laut doku steht dies für "Load is active" macht aber sinn)

(persönlich nutzte ich dazu das Java Program Modbus Mechanic)

(bitte beachte Bit1 == bitmask: 2 )

Gebenfalls wer es auch noch hilfreich zu schreiben welche Firmware der WR und WiNET Dongle hat.

[ApophisXX]

Hi @ApophisXX

könntest du folgendes testen, https://github.com/evcc-io/evcc/pull/18284/files

ob bei der neuere Wechselrichter Serie auch "Battery current" mit vorzeichen ausgeliefer wird?

Bist du dir sicher mit der Adressierung der Register?

Register 13000 ist bei meinem WR immer 0

13001 liefert aber BITs. Konnte noch nicht testen ob die auch plausibel sind.

https://www.photovoltaikforum.com/core/attachment/235914-ti-20211231-communication-protocol-of-residential-hybrid-inverter-v1-0-23-en-pdf/

[zachelnet]

Hi @ApophisXX
könntest du folgendes testen, https://github.com/evcc-io/evcc/pull/18284/files
ob bei der neuere Wechselrichter Serie auch "Battery current" mit vorzeichen ausgeliefer wird?

Ja, morgen, sobald ich Zeit finde.

Kannst du mir den Gefallen tun und meine letzte konfig so abändern, dass das mit dem skalierten Vorzeichen (multipliziere 1/-1) funktioniert? Also die Batterie-Power richtig angezeigt wird.

Brauchst du nicht fürs testen sollte folgendes reichen:

- type: custom
  name: Batterie
  power:
    source: calc
    mul:
    - source: modbus
      id: 1
      uri: 192.168.178.169:502
      register:
        type: input
        address: 13019 # Battery voltage
        decode: uint16
      scale: 0.1
    - source: modbus
      id: 1
      uri: 192.168.178.169:502
      register:
        type: input
        address: 13020 # Battery current
        decode: int16
      scale: 0.1

  soc:
    source: modbus
    id: 1
    uri: 192.168.178.169:502
    register:
      address: 13022 # Battery level
      type: input
      decode: uint16
    scale: 0.1
  capacity: 16

Komme aktuell auf keinen grünen Zweig. Die YAML Syntax bricht mir das Genick. Komme eigentlich aus der SPS und C/C++ Welt.

kenn ich.

Bezüglich Doku zum Modbus, würde ich dir die aktuell Dokumentation vorschlagen:
https://github.com/Gnarfoz/Sungrow-Inverter/blob/main/Modbus%20Information/TI_20240924_Communication%20Protocol%20of%20Residential%20Hybrid%20Inverter-V1.1.5.pdf

[zachelnet]

Folgende Präsentation von sungrow ist da auch noch intresant zum Thema Modbus

https://www.icloud.com/iclouddrive/0f6S3RiBYKFLsFX4ETzeEOVPQ
#17461 (comment)

[ApophisXX]

Also, Battery Current (13020) wird mit Vorzeichen ausgegeben.
Aktuell wird die Batterie geladen und die Werte sind negativ. Die Werte sind per se auch plausibel.

[zachelnet]

dann würde ich sage das es passt

[Funkymaddox]

Im Photovolaik Forum gibt es ein Modbus SH20T Topic, in dem ich auf das Modbus vs. WiNet-S2 Dongle via LAN Problem sehr genau unter die Lupe genommen habe. Der S2 Dongle verschluckt sich ab und an für mehrere Minuten beim Register 13000, oder zumindest beim Senden dieses Registers. Während in iSolarCLoud die Batterie abends konstant mit 300wh entläd, kann es passieren, dass in EVCC alles auf 0 springt für ein paar Minuten, so als ob es keinen Stromfluss mehr gibt. Wenn ich gleichzeitig in ioBroker aber nachschaue, zeigt ioBroker mir die selben 300wh wie in iSC an, aber beim 13000 Register steht in der Zeit, in der EVCC keinen Stromfluss darstellt "0", anstelle der "12". Sobald der Dongle wieder den richtigen Wert, zB 12 sendet, springt in EVCC alles wieder auf normal und auch hier werden die 300wh angezeigt.

Dieses Phänomen habe ich gut mit bildern nachweisen können und Sungrow gemeldet. Allerdings bezweifle ich, dass dies großartig mit einem FW Update gefixt werden kann. Habe selbst einen SH20T+SBH150 (FW.28 und .16)
Der Dongle läuft am Limit. Zwar kann EVCC leider nichts mit dem Wert "0" bei Register 13000 (adressiert 13001) anfangen (dieser Wert ist per se nicht falsch), aber Sungrow/Dongle sollte erst gar nicht von 12 auf 0 springen beim Modbus senden, obwohl im WR Status 12 weiterläuft.

Ich habe aktuell einen Waveshare RS485toLAN Adapter eingebaut und teste die nächsten Tage (durch den Schnee ist der Speicher 5 Tage leer gewesen, womit ich keinen Vergleich in meinen Tests hatte). Was aber trotzdem schon auffällt ist die Datenraten in ioBroker. Es werden so viel Schneller und hochfrequenter Modbus Register empfangen, als über den WiNet-S2, das ist schon krass.
Ab morgen wird es dann endlich spannend und der Test kann anlaufen. Falls die nächsten Tage dieser Bug nicht mehr auftritt, lag es tatsächlich am S2 Dongle und einem Register 13000 Problem.

Grüße

[ApophisXX]

Und, hast du schon Erkenntnisse sammeln können?
Zuletzt war ich doch sehr zuversichtlich, aber im Moment sehe ich keine Logik hinter den Registern. Der Wechsel zwischen den Register Adressen ist schon sehr seltsam.
Die einen sprechen von 12999 reale Adresse um das 13000er auszulesen, in einer der Anleitungen steht 13000 für "Running State" in einer anderen (auch von SUNGROW) steht Adresse 13001 für "Running State".

[Funkymaddox]

Im Modbus Dok 1.1.5 von Sungrow ist das relativ eindeutig beschrieben.
13000 Running State (adressiert 12999)
13001 Power Flow Status (adressiert 13000)
Ich schätze durch den -1 Kuddelmuddel bei der Abfrage gibt es oft Verwechslungen.

Running State abfragen -> 12999 (war bei mir immer schon "0" in ioBroker und EVCC lief trotzdem (abgesehen von dem Fehler, der aber durch Power Flow Status kommt)
Power Flow Status abfragen -> 13000 (Hier gibt es versch. Werte, je nach Stromfluss. Oft zb "12" wenn Batt. sich ins Haus entlädt und kein Netzbezug da ist. Hier ist oft anstelle von "12" die "0" gesendet worden vom WiNet-S2 für einige Minuten fälschlicherweise, obwohl sich, auch laut iSolarCloud, nichts am Flow geändert hat)

Ich bitte vor Anpassungen in EVCC um genaues Nachforschen derjendnigen, die einen Fehler haben. Nicht, dass das EVCC Team nun Register anpasst/anders berechnen lässt, obwohl der Fehler ganz woanders steckt.

Ob meine Erfahrungen auch auf die SHxxRT Serie passen, kann ich nicht sagen.
Bei der SHxxT Serie würde ich es einfach so lassen und jedem für 100% Fehlerfreiheit einen RS485 Adapter am Loggerport empfehlen.

[zachelnet]

Ich bitte vor Anpassungen in EVCC um genaues Nachforschen derjendnigen, die einen Fehler haben. Nicht, dass das EVCC Team nun Register anpasst/anders berechnen lässt, obwohl der Fehler ganz woanders steckt.

seh ich genauso, da template für verschieden Firmware Version und Model genutzt werden, und ich denke nicht das das EVCC Team begeister ist wenn ständig was geändert wird und dadurch neue Issue erstell werden....

Ob meine Erfahrungen auch auf die SHxxRT Serie passen, kann ich nicht sagen.

Aus meiner eigene erfahrung ist die SHxxRT Serie soweit stabil mit der Letzten Firmware Version vom WiNetS (nicht die S2), bis auf ein paar kleinigkeiten mit Batterien die nicht von sungrow kommen.

Bei der SHxxT Serie würde ich es einfach so lassen und jedem für 100% Fehlerfreiheit einen RS485 Adapter am Loggerport empfehlen.

Denk bis Sungrow ihre Firmware entsprechend gepatch hat sollte dies eine gute Möglichkeit sein.

[ApophisXX]

Also ich hab's heute oft genug kontrollieren können und so wie es aussieht passen alle Werte zusammen.

Laden/Entladen wird sauber angezeigt.
Danke für die Unterstützung.

Wenn ich morgen die Zeit habe, lad ich nochmal meinen Konfig hoch falls jemand nochmal auf ähnliche Probleme stößt.

Markiere dann morgen eine Antwort, für Leute die auf der Suche sind.

Danke euch.