Sungrow Hybrid: "Lock Battery" broken during fast charging since 0.130.0

[andyhielscher]

Describe the bug

Enabling the setting "Verhindere Entladung im Schnell-Modus und bei geplantem Laden." does not lock the battery but it appears an error in the log:
[site ] ERROR 2024/09/09 18:45:02 battery mode: write tcp [ip EVCC]:55410->[ip sungrow SH inverter]:502: write: broken pipe

Steps to reproduce

1. Clean install of evcc
2. use Sungrow SH inverter
3. Start fast charging the car
4. switching the described setting causes error message

Configuration details

network:
  schema: http
  host: evcc.local
  port: 7070

log: debug

interval: 30s

levels:
  cache: error

plant: xxx

sponsortoken: xxx

meters:
- type: template
  template: sungrow-hybrid
  id: 1
  host: 192.168.1.14
  port: 502
  timeout: 10s
  usage: grid
  modbus: tcpip
  name: grid1
- type: template
  template: sungrow-hybrid
  id: 1
  host: 192.168.1.14
  port: 502
  timeout: 10s
  usage: pv
  modbus: tcpip
  name: pv1
- type: template
  template: sungrow-hybrid
  id: 1
  host: 192.168.1.14
  port: 502
  timeout: 10s
  usage: battery
  modbus: tcpip
  name: battery1
  capacity: 8.64

chargers:
- type: template
  template: go-e-v3
  host: 192.168.1.16
  name: wallbox1

loadpoints:
- title: Go-E Garage
  charger: wallbox1
  mode: pv
  enable:
    delay: 10m
  disable:
    delay: 2m

site:
  title: Zuhause
  meters:
    grid: grid1
    pv:
    - pv1
    battery:
    - battery1
  residualPower: 10

tariffs:
  currency: EUR
  grid:
    type: tibber
    token: xxx
  feedin:
    type: fixed
    price: 0.08

Log details

evcc meter --log trace,db:error --battery-mode hold --battery-mode-wait 1m battery1
[main  ] INFO 2024/09/09 18:38:47 evcc 0.130.8
[main  ] INFO 2024/09/09 18:38:47 using config file: /etc/evcc.yaml
[modbus] TRACE 2024/09/09 18:38:48 modbus: send 00 01 00 00 00 06 01 06 32 f9 00 02
[modbus] TRACE 2024/09/09 18:38:48 modbus: recv 00 01 00 00 00 06 01 06 32 f9 00 02
[modbus] TRACE 2024/09/09 18:38:48 modbus: send 00 01 00 00 00 06 01 06 32 fa 00 cc
[modbus] TRACE 2024/09/09 18:38:48 modbus: recv 00 01 00 00 00 06 01 06 32 fa 00 cc
[main  ] INFO 2024/09/09 18:38:48 waiting for: 1m0s
[modbus] TRACE 2024/09/09 18:39:48 modbus: closing connection due to idle timeout: 1m0.000584391s

evcc meter --log trace,db:error --battery-mode normal --battery-mode-wait 1m battery1
[main  ] INFO 2024/09/09 18:39:57 evcc 0.130.8
[main  ] INFO 2024/09/09 18:39:58 using config file: /etc/evcc.yaml
[modbus] TRACE 2024/09/09 18:39:58 modbus: send 00 01 00 00 00 06 01 06 32 f9 00 00
[modbus] TRACE 2024/09/09 18:39:58 modbus: recv 00 01 00 00 00 06 01 06 32 f9 00 00
[modbus] TRACE 2024/09/09 18:39:58 modbus: send 00 01 00 00 00 06 01 06 32 fa 00 cc
[modbus] TRACE 2024/09/09 18:39:58 modbus: recv 00 01 00 00 00 06 01 06 32 fa 00 cc
[main  ] INFO 2024/09/09 18:39:58 waiting for: 1m0s
[modbus] TRACE 2024/09/09 18:40:58 modbus: closing connection due to idle timeout: 1m0.000598163s

What type of operating system are you running?

Linux

Nightly build

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

Version

evcc version 0.130.8

[andig]

Hast Du das nicht schonmal gepostet?

[andig]

[site ] ERROR 2024/09/09 18:45:02 battery mode: write tcp [ip EVCC]:55410->[ip sungrow SH inverter]:502: write: broken pipe

Ich sehe keinen Fehler im Log?

[DarcDan]

Also ich habe ebenfalls dieses Verhalten @andyhielscher setzt du auch den SH15T mit SBRXXX ein?

[andyhielscher]

@andig Nein, ich hatte diesen Fehler noch nicht gepostet, das war jemand anders. Bitte schließe das Issue noch nicht, ich werde heute Nachmittag versuchen, bei dem Error auch mit loglevel: trace vielleicht mehr Informationen herauszubekommen. Dann werde ich das hier hinzufügen.

@DarcDan Ich setze einen SH5RT mit SBR096 ein. Jemand anders hatte das Problem mit SHxx und BYD Batterie.

[Dunkelgraf]

Das Verhalten tritt bei mir auch auf. Ich setze eine. Sungrow SH10RT mit SBR096 ein.

[andig]

"ich auch" hilft nicht. Hier fehlt weiter ein Logfile.

[premultiply]

trotzdem entnimmt er der Batterie den Saft.

[site ] DEBUG 2024/09/10 12:55:55 battery power: 0W

Irgendwie nicht nachvollziehbar.
Irgendwas scheint an den Meteringdaten auch nicht ganz zu stimmen.

Darüber hinaus wirkt die Batteriesperre ja nur im Modus "Sofort", nicht bei PV.

[Dunkelgraf]

"ich auch" hilft nicht. Hier fehlt weiter ein Logfile.

Hier ein Auszug aus dem Log:
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 00 2b 00 00 00 06 01 06 32 f9 00 02
[site ] ERROR 2024/09/10 11:06:58 battery mode: write tcp 172.18.0.2:45926->192.168.20.168:502: write: broken pipe
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 36 d8 00 00 00 06 01 04 13 98 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 36 d8 00 00 00 07 01 04 04 10 bb 00 00
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c0 00 00 00 06 01 04 32 ca 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c0 00 00 00 07 01 04 04 48 1a 00 01
[site ] DEBUG 2024/09/10 11:06:58 pv power: 4283W
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b d5 00 00 00 06 01 04 32 dd 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b d5 00 00 00 05 01 04 02 10 4e
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b d4 00 00 00 06 01 04 32 c8 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b d4 00 00 00 05 01 04 02 00 2d
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c1 00 00 00 06 01 04 32 c8 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c1 00 00 00 05 01 04 02 00 2d
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c0 00 00 00 06 01 04 32 e2 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c0 00 00 00 07 01 04 04 43 99 00 00
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c0 00 00 00 06 01 04 32 de 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c0 00 00 00 05 01 04 02 00 d2
[site ] DEBUG 2024/09/10 11:06:58 battery soc: 21%
[site ] DEBUG 2024/09/10 11:06:58 battery power: 4174W
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c3 00 00 00 06 01 04 32 d1 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c3 00 00 00 07 01 04 04 f2 e0 ff ff
[site ] DEBUG 2024/09/10 11:06:58 grid meter: 3360W
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c0 00 00 00 06 01 04 15 e2 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c0 00 00 00 07 01 04 04 06 30 00 00
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b 8b 00 00 00 06 01 04 13 9a 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b 8b 00 00 00 05 01 04 02 09 27
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b 8e 00 00 00 06 01 04 15 e4 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b 8e 00 00 00 07 01 04 04 01 be 00 00
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b 5d 00 00 00 06 01 04 13 9b 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b 5d 00 00 00 05 01 04 02 09 16
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b 8d 00 00 00 06 01 04 15 e6 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b 8d 00 00 00 07 01 04 04 01 e7 00 00
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b 55 00 00 00 06 01 04 13 9c 00 01
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b 55 00 00 00 05 01 04 02 09 31
[site ] DEBUG 2024/09/10 11:06:58 grid currents: [6.76 1.92 2.07]A
[modbus] TRACE 2024/09/10 11:06:58 modbus: send 1b c0 00 00 00 06 01 04 32 ec 00 02
[modbus] TRACE 2024/09/10 11:06:58 modbus: recv 1b c0 00 00 00 07 01 04 04 56 4f 00 00
[site ] DEBUG 2024/09/10 11:06:58 site power: 7734W
[lp-2 ] DEBUG 2024/09/10 11:06:58 charge total import: 274.636kWh
[lp-2 ] DEBUG 2024/09/10 11:06:58 charger status: A
[site ] DEBUG 2024/09/10 11:07:28 ----
[lp-1 ] DEBUG 2024/09/10 11:07:28 charge power: 10552W
[lp-1 ] DEBUG 2024/09/10 11:07:28 charge currents: [15.2 15.1 15.2]A
[lp-2 ] DEBUG 2024/09/10 11:07:28 charge power: 0W
[lp-2 ] DEBUG 2024/09/10 11:07:28 charge currents: [0 0 0]A
[site ] WARN 2024/09/10 11:07:28 planner: outdated
[modbus] TRACE 2024/09/10 11:07:28 modbus: send 00 2c 00 00 00 06 01 06 32 f9 00 02
[site ] ERROR 2024/09/10 11:07:28 battery mode: write tcp 172.18.0.2:37732->192.168.20.168:502: write: broken pipe
[modbus] TRACE 2024/09/10 11:07:28 modbus: send 36 d9 00 00 00 06 01 04 13 98 00 02
[modbus] TRACE 2024/09/10 11:07:28 modbus: recv 36 d9 00 00 00 07 01 04 04 1a 70 00 00
[modbus] TRACE 2024/09/10 11:07:28 modbus: send 1b c1 00 00 00 06 01 04 32 ca 00 02
[modbus] TRACE 2024/09/10 11:07:28 modbus: recv 1b c1 00 00 00 07 01 04 04 48 1b 00 01
[site ] DEBUG 2024/09/10 11:07:28 pv power: 6768W

Die Umschaltung hat nach ca. einer Stunde laden funktioniert, nach Beendigung des Ladevorgangs gab es beim freigeben der Batterie zum gleichen Problem. Ich kann die kompletten Logs hier anhängen wenn das gewünscht ist.
Der Sungrow WR ist über den zweiten Anschluß angebunden, nicht über das WiNet-Dongle.

[andig]

Das Log ist nutzlos, s.u.

[andyhielscher]

hier auch mein Auszug aus dem Log mit dem identischen Fehler von Dunkelgraf. Der Fehler tritt an der gleichen Stelle auf, laut TRACE wird per Modbus 00 02 00 00 00 06 01 06 32 f9 00 02 gesendet und danach kommt die ERROR-message write: broken pipe. Dies geschieht dann, wenn ich den Schalter "Verhindere Entladung im Schnell-Modus und bei geplantem Laden." aktiviere.
Auch bei mir ist der Sungrow WR über den zweiten LAN-Anschluss angebunden und nicht über das WiNet-Dongle.

[site ] DEBUG 2024/09/10 14:31:39 ----
[go-e ] TRACE 2024/09/10 14:31:39 GET http://192.168.1.16/api/status?filter=alw,car,eto,nrg,wh,trx,cards
[go-e ] TRACE 2024/09/10 14:31:39 {"alw":true,"eto":2076040,"car":2,"wh":53.06165821,"trx":null,"nrg":[232.5,234.0500031,233.1199951,3.720000029,10.06999969,0,0,2334.180908,0,0,0,2334.180908,99.6969986,0,0,100],"cards":[{"name":"n/a","energy":0,"cardId":true},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false},{"name":"n/a","energy":0,"cardId":false}]}
[lp-1 ] DEBUG 2024/09/10 14:31:39 charge power: 2334W
[lp-1 ] DEBUG 2024/09/10 14:31:39 charge currents: [10.1 0 0]A
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 00 02 00 00 00 06 01 06 32 f9 00 02
[site ] ERROR 2024/09/10 14:31:39 battery mode: write tcp 192.168.1.15:53034->192.168.1.14:502: write: broken pipe
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 03 46 00 00 00 06 01 04 13 98 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 03 46 00 00 00 07 01 04 04 07 d9 00 00
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 ca 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 e5 3d 00 00
[site ] DEBUG 2024/09/10 14:31:39 pv power: 2009W
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 dd 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 05 01 04 02 03 05
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 c8 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 05 01 04 02 00 0d
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 c8 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 05 01 04 02 00 0d
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 e2 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 4d 3e 00 00
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 de 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 05 01 04 02 02 f3
[site ] DEBUG 2024/09/10 14:31:39 battery soc: 76%
[site ] DEBUG 2024/09/10 14:31:39 battery power: 773W
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 d1 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 ff fd ff ff
[site ] DEBUG 2024/09/10 14:31:39 grid meter: 3W
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 15 e2 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 05 b7 00 00
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 95 00 00 00 06 01 04 13 9a 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 95 00 00 00 05 01 04 02 09 1c
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 15 e4 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 fc cd ff ff
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 95 00 00 00 06 01 04 13 9b 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 95 00 00 00 05 01 04 02 09 3e
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 15 e6 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 fc 8e ff ff
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 93 00 00 00 06 01 04 13 9c 00 01
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 93 00 00 00 05 01 04 02 09 39
[site ] DEBUG 2024/09/10 14:31:39 grid currents: [6.27 -3.46 -3.74]A
[modbus] TRACE 2024/09/10 14:31:39 modbus: send 01 a5 00 00 00 06 01 04 32 ec 00 02
[modbus] TRACE 2024/09/10 14:31:39 modbus: recv 01 a5 00 00 00 07 01 04 04 ac d5 00 00
[site ] DEBUG 2024/09/10 14:31:39 site power: 786W
[lp-1 ] DEBUG 2024/09/10 14:31:39 detected active phases: 1p
[lp-1 ] DEBUG 2024/09/10 14:31:39 !! session: chargeRater.chargedEnergy=0.1 - chargedAtStartup=0.0
[lp-1 ] DEBUG 2024/09/10 14:31:39 charge total import: 2076.040kWh
[lp-1 ] DEBUG 2024/09/10 14:31:39 charger status: C
[lp-1 ] DEBUG 2024/09/10 14:31:39 soc estimated: 70.06% (vehicle: 70.00%)
[lp-1 ] DEBUG 2024/09/10 14:31:39 vehicle soc: 70%
[lp-1 ] DEBUG 2024/09/10 14:31:39 vehicle soc limit: 100%
[lp-1 ] DEBUG 2024/09/10 14:31:39 vehicle range: 353km
[site ] TRACE 2024/09/10 14:31:39 telemetry: charge: Δ40/40Wh @ 2334W
[site ] TRACE 2024/09/10 14:31:39 POST https://api.evcc.io/v1/charge

[andig]

Das Log ist nutzlos, s.u.

[andig]

Der Fehler tritt an der gleichen Stelle auf, laut TRACE wird per Modbus 00 02 00 00 00 06 01 06 32 f9 00 02 gesendet und danach kommt die ERROR-message write: broken pipe. Dies geschieht dann, wenn ich den Schalter "Verhindere Entladung im Schnell-Modus und bei geplantem Laden." aktiviere.

Es wäre doch prima, das Problem ein wenig einzugrenzen. Dann müssen auch keine Screeshots gepostet werden. Das lässt sich ganz einfach hinsichtlich Ursache testen:

evcc meter --log trace,db:error --battery-mode hold --battery-wait 1m

Und falls der Befehl dazu führt, dass der WR die Verbindung trennt stellen sich ein paar Fragen:

• ist das schlimm?
• was sagt der Herstellersupport dazu?
• welche Register müssten stattdessen genutzt werden?
• was war vor 0.130.0 anders (Logfile)?

[andyhielscher]

Ich habe den Befehl evcc meter --log trace,db:error --battery-mode hold --battery-mode-wait 1m ausgeführt und folgende Logfile erhalten:

[main  ] INFO 2024/09/11 13:33:37 evcc 0.130.8
[main  ] INFO 2024/09/11 13:33:37 using config file: /etc/evcc.yaml
[modbus] TRACE 2024/09/11 13:33:37 modbus: send 00 01 00 00 00 06 01 06 32 f9 00 02
[modbus] TRACE 2024/09/11 13:33:37 modbus: recv 00 01 00 00 00 06 01 06 32 f9 00 02
[modbus] TRACE 2024/09/11 13:33:37 modbus: send 00 01 00 00 00 06 01 06 32 fa 00 cc
[modbus] TRACE 2024/09/11 13:33:37 modbus: recv 00 01 00 00 00 06 01 06 32 fa 00 cc
[main  ] INFO 2024/09/11 13:33:37 waiting for: 1m0s
[modbus] TRACE 2024/09/11 13:34:37 modbus: closing connection due to idle timeout: 1m0.000132066s

Mir fällt auf, dass das ein anderes Register ist. Hier wird 00 01 00 00 00 06 01 06 32 f9 00 02 benutzt und bei der Fehlermeldung im Log 00 02 00 00 00 06 01 06 32 f9 00 02. Ist das ggf die Ursache?

VG

[andig]

Das ist bei Modbus TCP die transaction id. Ich wundere mich eher, wieso die hier konstant 01 bleiben kann. Aber das tut vmtl. nix zur Sache.

[Dunkelgraf]

• was war vor 0.130.0 anders (Logfile)?

Ich habe mal ein Testsystem mit 0.128.4 aufgesetzt und die Bereiche "site", "modbus" und "lp-2" für einen Ladevorgang mitgeloggt. Das Sperren der Batterie funktioniert in dieser Version.

Anbei das anomysierte Logfile
evcc-20240911-Session-trace.log

Falls mehr benötigt wird, bitte Bescheid geben.

[andig]

Falls Modbus Proxy die Lösung ist dann besteht das Problem darin dass ihr vorher mit mehreren Clients gleichzeitig auf den Sungrow zugegriffen habt. Anderenfalls kann der Proxy keinen Einfluss haben.

Abschließend nochmal der Hinweis: es fehlt weiterhin ein trace Log in dem sich nachvollziehen ließe, was die letzten Modbus Kommandos vor dem "broken pipe" waren. Falls es an der Reihenfolge mehrere Abfragen liegen sollte- in dem Log wären die nachvollziehbar...

[koch86]

Falls Modbus Proxy die Lösung ist dann besteht das Problem darin dass ihr vorher mit mehreren Clients gleichzeitig auf den Sungrow zugegriffen habt. Anderenfalls kann der Proxy keinen Einfluss haben.

Das ist so - bei mir war es Home Assistant selbst per modbus-Anbindung sowie EVCC welches als AddOn läuft.
Spannend daran ist, dass es fast ein Jahr lang ohne Probleme lief und seitdem nur HA und EVCC Updates bekommen haben - es hat anfangs also wohl nur „gerade so“ funktioniert.
Wie auch immer - danke für die Unterstützung!

[lenny884]

Die Vermutung mit "doppeltem" Zugriff hatte ich auch und habe daher vor einigen Tagen in der Home Assistant Konfiguration die IP des Wechselrichters auskommentiert. Home Assistant danach zwei mal neugestartet. EVCC läuft ebenfalls als Add-On.

Leider hat das bei mir nicht den gewünschten Erfolg gebracht. Weiterhin beim Netzladen als auch beim Batterie sperren die bekannte "broken pipe" Meldung. Kann mir jemand mal seine Modbus Proxy Konfiguration in EVCC posten mit kurzer Erläuterung welche Zeile was darstellt? Ich komme mit der Doku von EVCC leider nicht klar.

[jks1981]

Ich wollte es unabhängig von evcc machen und habe dieses Home Assistent AddOn verwendet: https://github.com/Akulatraxas/ha-modbusproxy

Dann in der evcc Konfiguration statt der IP des Wechselrichters die von Home Assistant eintragen.

[No23D]

Danke für den Hinweis. Funktioniert bei mir super!

[koch86]

Eigentlich ganz einfach:

modbusproxy:
  - port: 5021 # Der lokale Port, auf den sich die Clients verbinden
    uri: 10.2.0.162:502 # IP und Port des modbus Master - also in meinem Fall der Wechselrichter

Den Block musst du in der evcc.yaml hinzufügen und danach in evcc sowie HA alle IP-Adressen und Ports des Sungrow-Wechselrichter mit dem neuen Port und der passenden IP ersetzen. Bei mir waren dies:

• In der evcc.yaml insgesamt 3x unter meters
• In der configuration.yaml von Home Assistant (oder wo auch immer du Modbus in Home Assistant konfiguriert hast)

Konkret habe ich hier (da alles auf einem Rechner läuft) überall IP 127.0.0.1 und Port 5021 konfiguriert.

[lenny884]

oh man. Wirklich total einfach. Auf den ersten Blick war das mit dem Modbus Proxy auch bei mir erfolgreich! Auch das "günstige Netzladen" scheint nun zu funktionieren.

Tausend Dank!

[HunZ83]

Eigentlich ganz einfach:

modbusproxy:
  - port: 5021 # Der lokale Port, auf den sich die Clients verbinden
    uri: 10.2.0.162:502 # IP und Port des modbus Master - also in meinem Fall der Wechselrichter

Den Block musst du in der evcc.yaml hinzufügen und danach in evcc sowie HA alle IP-Adressen und Ports des Sungrow-Wechselrichter mit dem neuen Port und der passenden IP ersetzen. Bei mir waren dies:

• In der evcc.yaml insgesamt 3x unter meters
• In der configuration.yaml von Home Assistant (oder wo auch immer du Modbus in Home Assistant konfiguriert hast)

Konkret habe ich hier (da alles auf einem Rechner läuft) überall IP 127.0.0.1 und Port 5021 konfiguriert.

Hallo in die Runde! Ich lese jetzt schon einige Zeit gespannt mit, weil ich dasselbe Problem habe.
An dieser Stelle danke ich Euch für die eifrige Suche nach einer Lösung und bin begeistert darüber, dass der Knoten nun anscheinend geplatzt ist - toll und tausend Dank!!

Jetzt frage ich mich, wie die Anpassung bei mir aussehen muss und wäre Euch dankbar für einen kleinen Hinweis.

Ich habe auch alles auf einem Raspi laufen (HomeAssistant, evcc und modbus)

Ich habe meine modbus-Konfig in einer eigenen yaml ("/homeassistant/integrations/modbus_sungrow.yaml")

Darin steht bei mir dieser Abschnitt:
sungrow_modbus_host_ip: 192.168.178.149
sungrow_modbus_port: 502 # TODO update with the Modbus port of your inverter. Default is '502'
sungrow_modbus_slave: 1 #TODO update with the slave address of your inverter. Default is '1'

Soll ich dort jetzt Port und host-IP jetzt anpassen auf 5021 und 127.0.0.1?

Danke Euch!!!

[andig]

Auf den ersten Blick war das mit dem Modbus Proxy auch bei mir erfolgreich!

@lenny884 wenn das bei Dir funktioniert dann müssen vorher mehrere Clients zugegriffen haben. Lesson learned: als evcc Team müssen wir darauf hinwirken, dass bei derartigen Problemen jegliche externen Anwendungen wie HA, ioBroker etc. zur Fehlersuche deaktiviert werden. Anderenfalls vergeuden wir kostbare Zeit mit der Suche nach Phantomfehlern.

[jks1981]

Nochmal für alle, die mehrere Wechselrichter in evcc haben (ich habe einen Sungrow Hybrid und einen SMA), da vor kurzem der Fehler auch beim 2. Wechselrichter in evcc hochkam. Ich habe ein Homeassitant-AddOn für mehrere modbus-proxies gefunden und nutze jetzt das:

https://github.com/TCzerny/ha-modbusproxy

Damit konnte ich für beide Wechselrichter einen seperaten modbus-proxy anlegen.

[JuMa1967]

Sorry das ich nachfrage ich bin kein Spezialist.
Ich habe weder HomeAssistand noch habe ich zwei Wechselrichter. Ich habe aber das Problem um das es in diesem Fall geht das meine Batterie nicht sperrt wenn ich schnelllade und die Fehlermeldung kommt. Dies habe ich auch bei der aktuellen Version 133.5 Das hat bei älteren Versionen von evcc aber bereits funktioniert.
Muss ich dennoch modbusproxy eirichten? Kommt hier ein Update des Templates und ich muss nur warten?

[DiDu0815]

Jetzt funktioniert auch Modbus über den WiNet-S Dongle einwandfrei.
Habe das testweise nun zwar auch so laufen. Bei mir wird jedoch der SoC der Batterie anfangs mit 100%, nun jedoch immer mit 0% angezeigt. Gibt es dadurch keine Nachteile im Hinblick auf Funktionen, die sich auf den aktuellen SoC beziehen (bspw. Einstellungen in Zusammenhang mit battery supported charging)?

[JuMa1967]

Batterie sperren funktioniert mit evcc 132.0 und dem Lan am WiNet-Dongel!

Ich habe wie empfohlen einen Kaltstart des WR durchgeführt, den Rooter neu gestartet aber die broken pipe blieb. Nun habe ich vom Netzwerkanschluss des Wechselrichters (hinterer Anschluss) zurück auf den Netzkabelanschluss des WiNet-Dongels gewechselt. Zudem habe ich evcc auf die neuste Version 132.0 aktualisiert.
Bis jetzt scheint alles einwandfrei zu funktionieren.
Vielen Dank für Eure Unterstützung.

[Dunkelgraf]

Was bei mir das Problem gelöst hat ist also:

• Update des Sungrow WR auf aktuelle Firmware (incl. WiNet-S!)
• den Netzwerkport am WiNet-S nutzen.

Ich beobachte das noch ein paar Tage.

Läuft einwandfrei, für mich ist das Problem damit gelöst.

[Dunkelgraf]

@DiDu0815 hast Du die aktuelle Firmware auf dem WiNet-S? Ich hatte bei meinen Tests auch Probleme mit der Batterieanzeige, nach dem Firmware-Update ist das behoben.

[JuMa1967]

Mein Solateur hat mir im November die Version: WINET-SV200.001.00.P026 installiert, angeblich war das die neuste. Wie ich jetzt sehe gibt es aber eine neuere Version WINET-SV200.001.00.P030.
Kannst du mir sagen welche bei dir installiert ist?
Wenn du mir bestätigst das ich die WINET-SV200.001.00.P030 benötige werde ich mich gleich mit dem Solateur in Verbindung setzen.

[DiDu0815]

@Dunkelgraf FW WINET-SV200.001.00.P030 ist schon installiert. Auch der SH10-RT an sich ist auf aktuellster FW und evcc auf aktueller 0.132.0.
Weitergehende Tests per Modbus-Tool: Der Hausbatterie-SoC kommt beim Auslesen aus Register 13023 genau dann korrekt, wenn ich ihn via hinteren LAN-Port auslese. Via Winet-S kommt da momentan nichts. Alles andere funktioniert aber so weit. Leider kann ich die evcc-Konfiguration - meines Wissens - ja nicht so ändern, dass nur der SoC via hinterem LAN-Port ausgelesen wird und alles andere via Winet-S läuft.
-> Ich werde morgen noch mal den WR kompett powercyclen und schauen ob es dann vielleicht funktioniert. An irgendwas muss es ja liegen, dass es bei euch anders ist.

[DiDu0815]

Der SoC wird dort ebenfalls falsch angezeigt:

ABER der Wert in iSolarCloud - dorthin durchgereicht via Winet-S - ist ja korrekt...

Ich habe exakt dieselben FW-Versionen - außer BAT, da ich nicht eine Sungrow- sondern eine Axitec AXIstorage Li SV2 als Hausakku habe (ist in Wirklichkeit eine PylonTech Batterie). Im bisherigen Verlauf war die aber total unauffällig.

Ist als Workaround denkbar sich eine Art Custom Battery Meter zu bauen, das ausschließlich den SoC via LAN-Port holt und alles andere via Winet-S erledigt?

[zachelnet]

@DiDu0815 uff, ich würde dir empfehlen an den Support von Axitec/Sungrow anzuschreiben, gebenfalls liegt hier ein Bug in der Firmware von deinere Battery vor. Da kann ich dir wenig weiterhelfen.

Als Workaround könntest du dir Modbus Proxy anschauen, alternative den hinteren Port für Modbus verwenden.

[DiDu0815]

Recht unwahrscheinlich für mich, dass es die Batteriefirmware ist. Denn der Batterie-SoC wird seit jeher in iSolarCloud korrekt angezeigt und auch per Modbus via LAN-Port korrekt zurückgegeben. Über den LAN-Port würde alles funktionieren - wäre da nicht das mit 0.130.0 entstandene "broken pipe" Problem.
Will ich den hinteren Port für Modbus verwenden dann muss ich, um "broken pipe" zu vermeiden, auf 0.129.0 zurückgehen - und somit auf die Netzlademöglichkeit des Akkus verzichten. Vielleicht akzeptabel im Sommer, im Winter eher nicht. Eine 0.129.0 inkl. Netzladen-Option wäre aktuell ideal für mich.
Ich habe inzwischen Sungrow angeschrieben.

[zachelnet]

Dann sollten die SoC werte im WiNet Portal auch passen, general sind iSolarCloud und WiNet Modbus unterschiedliche Protokolle. Werte die im iSolarCloud Vorhanden sind mussen nicht im WiNet Modbus enthalten sein.

Bezüglich broken pipe kommt diese nach folgende "modbus: send 00 2b 00 00 00 06 01 06 32 f9 00 02"? Hier wird laut Template auf batterymode und den Entsprechen Case wie normal, hold, charge(Netzlademöglichkeit) verwalttet.

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

In meine Augen sieht es aus als Klappt die umsetztung vom Canbus (Axitec) Richtung Modbus nicht richtig oder mit eingeschränkter Funktionumfang und das ist ein Thema von der Firmware und da können dir nur die Herrsteller Axitec/Sungrow weiterhelfen.

Aus Erfahrung kommt "broken pipe" zustande wenn Werte gesetzt werden und der WR dies Verhindert/Blockiert.

[DiDu0815]

Ich habe inzwischen (mit @VolkerK62's Hilfe) ein custom meter als Workaround für mein spezielles Problem implementiert. Mal sehen ob der Workaround hält. Als Kollateraleffekt kam auch heraus, dass der Wert des interval: ein Rolle spielen kann, ob "broken pipe" am LAN-Port des WR auftritt oder nicht. In meinem Fall hat dem ersten Anschein nach das Herabsetzen von 30s auf 10s das Problem beseitigt.

[JuMa1967]

Ich kann es jetzt reproduzieren.

Wenn ich am Netwerkport des Wechselrichters einstecke funktioniert die Darstellung/Auswertung des Überschusses und deren Verwendung korrekt und es wird alles korrekt angezeigt. Der Überschuss geht korrekt in die Batterie. Beim Schnell-Laden erhalte ich jedoch die Fehlermeldung mit der broken Pipe und die Batterie sperrt das entladen nicht.
Wenn ich den Netzwerkstecker den WINET-Dongel einstecke funktioniert beim Schnellladen das sperren der Batterie korrekt, auch beim Laden nach Zeitplan. Dann funktioniert jedoch die Darstellung/Auswertung des Überschusses nicht mehr. Die Grafik zeigt an als ob ich den kompletten Solarertrag im Haus verbrauche, Batterie läd aber korrekt, wird aber nicht als Empfänger des Überschusses angezeigt:

Darstellung mit Anschluss am WINET

Darstellung mit Anschluss am WR SH6.ORT

Hier die Bios-Versionen meiner Sungrow-Komponenten: evcc verwende ich die v0.132.0

Sungrow Battery: SBRBCU-S_22011.01.24
Communication Module: WINET-SV200.001.00.P026
Wechselrichter SH6.ORT
MDSP SAPPHIRE-H_03011.95.03
LCD SAPPHIRE-H_01011.95.03

Ich lasse mir kommende Woche das WINET-Modul mal auf die Version WINET-SV200.001.00.P030 aktualisieren

[zachelnet]

Hi @JuMa1967
ja das Fehlverhalte vom WINET mit der Firmware Version WINET-SV200.001.00.P026 ist bekannt, mit der Version WINET-SV200.001.00.P030 passt die Darstellung wieder.

[HunZ83]

Ich bekomme es leider nicht ohne Eure Hilfe hin, Modbus auf den WiNet zu wechseln. Bzw. kann ich das machen, und dann ist in EVCC auch auf einmal alles perfekt, aber ich verliere dann alle Entitäten im HomeAssistant. Ich habe das Addon "Modbus-Proxy" und damit in Verbindung die Integration von Martin Kaiser (https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant). Das war damals die einzige Variante, den Sungrow zu integrieren. scheint aber nicht mit dem WiNet zu klappen.
Muss ich den WR irgendwie anders in HA integrieren? Im EVCC (läuft ebenfalls als Add-On im HA) kann ich alle Daten vom WR verarbeiten (Batteriestand, Leistung, etc...alles da).
Habt Ihr eine Idee, was ich falsch mache?

[zachelnet]

Hi @HunZ83
ich würde es so lösen das HomeAssistance / mkaiser Plugin mittels Modbusproxy aufs Native Modbus gehts, und im Evcc auf port vom WINET Modbus, dann sollte alles beim alten bleiben.

Alternative kannst du den WR auch über evcc und mqtt in HomeAssistance integrieren. Mittels folgenden HACS plugin https://github.com/marq24/ha-evcc hab ich dies gemacht.

[JuMa1967]

Jetzt passt es! Danke !
Nach dem Update des Sungrow WINET auf die Version SV200.001.00.P030 in Verbindung mit evcc v0.132.0 funktioniert das Sperren der Batterie beim Schnellladen und beim Zeitgesteuerten Laden einwandfrei.
Mein Aktualisierungsintervall ist 30s wie empfohlen.
Vielen Dank an alle für die Unterstützung

[DiDu0815]

Ich habe in den letzten zwei Wochen eine Reihe ganz verschiedener Konfigurationsvarianten (über Winet-S, über LAN-Port, oder auch beides gemischt) ausprobiert. Ich habe nun eine letztlich sehr einfache Lösung für mich gefunden, die möglicherweise auch für andere relevant ist. Man kann damit evtl. wieder den LAN-Port des Sungrow-WR benutzen - auch bei Nutzung von evcc-Versionen neuer als 0.129.0. Deshalb möchte ich das hier einmal vorstellen.

Das seit v0.130.0 bestehende broken pipe Problem bei direktem Betrieb über den LAN-Port (egal ob mit oder ohne Umweg über modproxy:) ist abhängig vom Wert von interval:.

Bei mir stellte sich das wie folgt dar:

• Wenn interval: einen Wert zwischen 15s und ca. 60s hatte, dann gab es broken pipe Fehler.
• An den genannten Grenzwerten trat broken pipe unregelmäßig bis sporadisch auf.
• Weiter innerhalb des Intervalls regelmäßig bei exakt jedem zweiten Verbindungsversuch.
• Bei Werten außerhalb des Intervalls (d.h. darunter oder darüber) gab es keine Fehler.

Meine Hypothese:

• Mit einem zeitgleich mitlaufenden Portmonitor konnte ich feststellen, dass bei Werten kleiner gleich 14s dieselbe Modbus-Session zum WR aufrecht erhalten wurde (erkennbar an der konstant bleibenden TCP-Portnummer der ausgehenden Modbus-Verbindung). Das Wiederverwenden derselben TCP-Session scheint dem WR zu behagen.
• Bei interval: Werten über 14s wurde für jede Modbus-Verbindung eine neue TCP-Session aufgebaut (->neue ausgehende Port-Nummer), was der WR übelnimmt und mit broken pipe quittiert.
• Im Falle abgebrochener TCP-Sessions benötigt der WR eine gewisse Zeit für eine Art internes Recovery, bevor er die nächste Session zulässt, d.h. ohne sie mit broken pipe abzuweisen. Die Recovery-Zeit reicht aus bei interval: Werten über ca. 60s.

Ich betreibe evcc v0.132.x nun seit dem 3. Januar mit interval: 14s am LAN-Port des WR und habe seitdem keine broken pipe Fehler mehr gesehen. Es ist denkbar, dass die konkreten Grenzen des Intervalls je nach Gegebenheiten der Infrastruktur eines Nutzers abweichen können. Möglicherweise ist das auch firmware-versionsabhängig. Auf meinem WR (SH10RT) und Winet-S läuft die jeweils aktuelle Firmware.

Tipp:
Starten mit interval: 10s (oder weniger) und sukzessive Erhöhen in Schritten von 1s - so lange bis broken pipe passiert. Dann ein, zwei Sekunden wieder abziehen und den resultierenden Wert ab sofort in der evcc.yaml als interval: benutzen.

Sofern andere Sungrow-Nutzer das verifizieren und bestätigen können besteht aus meiner Sicht nun die Chance, diesen Topic endlich mal zu schließen. In diesem Fall könnte auch in der Doku des Sungrow WR Templates auf den Sachverhalt hingewiesen werden.

cc/ @andig @naltatis @VolkerK62

[HunZ83]

Der outgoing Session Port ändert sich bei Dir auch jedes Mal. Das belegt, dass - im Gegensatz zu uns - die 10s bei Dir nicht reichen damit immer dieselbe Session weiterbenutzt wird. Du könntest testweise mal interval: 70s versuchen, ob es wenigstens dann funktioniert (ob ein so großes Intervall auf Dauer wünschenswert ist, ist jedoch eine andere Frage...).

Leider auch bei 70sec kein Erfolg.

[HunZ83]

Nur zur Sicherheit: Hab weiter oben gesehen, dass Du auch Home Assistant benutzt. Dafür wäre dann ja aber immer noch der Umweg über modbusproxy: nötig. Ich nutze das nicht, weil evcc bei mir als einziges den WR abfragt. Nicht auszuschließen, dass der Proxy das Timing etwas verändert.

Leider komme ich mit meiner scheinbaren Sonderlösung und dem modbusproxy über die Marin-Kaiser-Integration nicht weiter. Und den WR zukünftig anders anzubinden scheue ich, weil ich befürchte, dann alle Statistiken zu verlieren.
Echt blöd, im Frühjahr muss ich das spätestens wieder am Laufen haben, wenn ich das Auto laden muss, ohne den Ausakku zu leeren (derzeit ist der ja sowieso immer leer).

[andig]

Nochmal: der richtige Parameter ist das timeout, nicht interval.

[DiDu0815]

Ich denke, das haben die meisten auch schon verstanden. Gebetsmühlenartige Wiederholung desselben Sachverhalts hilft aber nicht weiter, wenn jedesmal die Details fehlen wie timeout: genau zu verwenden ist. Insofern wäre hilfreich gewesen, wenn Du stattdessen meine Frage unten beantwortet hättest.

[andig]

Dito. Es nutzt halt auch nix mangels Antwort die gleichen Dinge wieder zu probieren. Parameter setzen wie alle anderen Parameter such.

[andig]

Das Wiederverwenden derselben TCP-Session scheint dem WR zu behagen.
Im Falle abgebrochener TCP-Sessions benötigt der WR eine gewisse Zeit für eine Art internes Recovery, bevor er die nächste Session zulässt, d.h. ohne sie mit broken pipe abzuweisen.

Ist also ein Defizit des WR und sollte vom Hersteller gelöst werden. evcc Modbus hat den timeout Parameter, eigentlich idle timeout nach dem die Verbindung geschlossen wird. Habt ihr den mal ausprobiert? Das wäre deutlich besser, als in das Regelintervall einzugreifen.

[DiDu0815]

@andig Ist mein Verständnis korrekt, dass ich zum Testen das Template sungrow-hybrid.yaml vorübergehend bei mir lokal anpassen müsste? Falls ja, wo finde ich das?

[Tornado1907]

Hallo miteinander, ich muss leider DiDu Recht geben. Es ist nirgendwo erklärt, wo man diesen Parameter setzen kann. @andig du kennst wahrscheinlich den Code von evvc auswendig, aber der Rest hier sind mehr oder minder User.

was DiDo meint und ich auch schon gefragt habe:

• müssen wir zum Testen ein Custom Wechselrichter mit Modbus anlegen ?
• Oder kann man das Template für den Hybrid Sungrow testweise editieren, um dort den timeout Parameter einzufügen?
• Wenn ja, wo finden wir das template und müssen wir dafür dann den Code kompilieren oder reicht es die Datei zu editieren und dann evcc zu starten?

Das mag für einen GO Entwickler alles selbsterklärend sein, für den Laien aber nicht. Und ja ich komme aus der IT und habe oft mit Entwicklern zu tun und kenne diese Diskussionen. Ich mache da ganz oft den Dolmetscher zwischen Nutzern und der Scrum Fraktion, wo ich die User Stories schreibe…

[andig]

Soweit ixh sehe steht der in der Doku: https://docs.evcc.io/docs/devices/meters#sh-series-hybrid-inverter. Was fehlt hier konkret?

[VolkerK62]

@andig Das timeout im Template ist (leider) nur im batterymode definiert.

@Tornado1907

müssen wir zum Testen ein Custom Wechselrichter mit Modbus anlegen ?

Wäre einen Versuch wert und dort dann ein timeout bei jedem Register hinzufügen.

evcc/templates/definition/meter/sungrow-hybrid.yaml

Line 26 in 961968e

type: custom

Die "include modbus" Übersetzung gibt es hier
https://docs.evcc.io/docs/reference/modbus

[andig]

Schön wäre doch, es nach mittlerweile 3 Tagen Diskussion einfach mal auszuprobieren (Nike: Just do it :). Da die Verbindung geshared ist sollte es reichen das in battery zu tun. Zur Sicherheit 28f74c9.