Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden

[Carsten Sauermann]

@mcbeath ich glaube das ist für die Einstellung ob zueinem gewissen Zeitpunkt der Akku geladen werden soll. Was man auch in der App einstellen kann

13083 sollte auch auf 0 stehen..

[McBeath]

@carsten-sauermann

@carsten-sauermann said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

@mcbeath ich glaube das ist für die Einstellung ob zueinem gewissen Zeitpunkt der Akku geladen werden soll. Was man auch in der App einstellen kann

13083 sollte auch auf 0 stehen..

13083 hat 65535
13084 hat 0
Die standen aber glaube ich schon immer so

Laut Sungrow (Register -1)
55 Start Charging Power13084 U16 70~10000 W
56 Start Discharging Power 13085 U16 70~3000 W

Bin verwirrt

[GombersIOB]

@mcbeath

Wenn alles wieder so steht wie am Anfang würde ich mal einen Neustart probieren. Nach dem Motto: „Ein Reboot tut immer gut“..ich meine, das ist Software. Und es ist nicht immer sicher, ob sie unter allen Umständen immer alle notwendigen Fallunterscheidungen macht.
Ansonsten bleibt die Möglichkeit, bevor man sich direkt an Sungrow wendet, im Photovoltaikforum zu fragen. Den Hinweis Inhaber ich hier schon ein paarmal gegeben und mindestens. Einmal hat’s auch geholfen.
Sungrow liest da mit.

[McBeath]

@gombersiob said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

@mcbeath

Wenn alles wieder so steht wie am Anfang würde ich mal einen Neustart probieren. Nach dem Motto: „Ein Reboot tut immer gut“..ich meine, das ist Software. Und es ist nicht immer sicher, ob sie unter allen Umständen immer alle notwendigen Fallunterscheidungen macht.
Ansonsten bleibt die Möglichkeit, bevor man sich direkt an Sungrow wendet, im Photovoltaikforum zu fragen. Den Hinweis Inhaber ich hier schon ein paarmal gegeben und mindestens. Einmal hat’s auch geholfen.
Sungrow liest da mit.

Das habe ich auch eben gemacht....
Und siehe da...
Batterie läuft wieder, nur der wi-net wollte sich nicht automatisch neu verbinden.
Aber jetzt ist alles wieder gut

Der Hausfrauen-Reset hilft doch immer wieder Wunder.
Besten Dank für die Unterstützung

[CaH]

@atlantis , Forum, Danke für die viele Vorarbeit - jetzt gebe ich was zurück.

Da der Wechsel zum Stromanbieter mit dynamischen Tarifen ansteht, habe ich mich mit der Zwangsladung der Batterie durch den WR (SH8.0RT) beschäftigt. Und siehe da, per Web lässt sich das konfigurieren. Mithilfe von SunGather hab ich die entsprechenden Holding-Register gefunden.
Bisher habe ich die Register nur gelesen, nicht per ioBroker geschrieben; dazu fehlt mir noch zuviel vom ioBroker-drumherum. Aber vielleicht hilft das hier ja schon mal anderen.
Gerne reviewen und wenn für gut befunden in die von Atlantis bereitgestellten Configs integrieren. Das Format des folgenden Snippets orientiert sich an der SunGather-Config.

Danke für kurzen Hinweis, falls meine Erkenntnis nicht so neu sein sollte wie von mir empfunden

Alaaf! CaH

- name: "forced_batt_charge"
  level: 2
  address: 13140
  datatype: "U16"
  models: ["SH8.0RT"]
  datarange:
    - response: 0xAA
      value: "Enable"
    - response: 0x55
      value: "Disable"
- name: "forced_batt_charge_day"
  level: 2
  address: 13141
  datatype: "U16"
  models: ["SH8.0RT"]
  datarange:
    - response: 1
      value: "AllDaysOfWeek"
    - response: 0
      value: "WorkingDaysOnly"
- name: "forced_batt_charge_1_start_hour"
  level: 0
  address: 13142
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_1_start_minute"
  level: 0
  address: 13143
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_1_end_hour"
  level: 0
  address: 13144
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_1_end_minute"
  level: 0
  address: 13145
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_1_SOC_perc"
  level: 2
  address: 13146
  datatype: "U16"
  models: ["SH8.0RT"]
  accuracy: 1
  unit: "%"
- name: "forced_batt_charge_2_start_hour"
  level: 0
  address: 13147
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_2_start_minute"
  level: 0
  address: 13148
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_2_end_hour"
  level: 0
  address: 13149
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_2_end_minute"
  level: 0
  address: 13150
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_2_SOC_perc"
  level: 2
  address: 13151
  datatype: "U16"
  models: ["SH8.0RT"]
  accuracy: 1
  unit: "%"

[halsi82]

@cah
Dankeschön, das habe ich schon lange gesucht.
Habe mir selbst blocklys gebaut gehabt um diese Funktion nachzubauen.

So ist es viel einfacher.

Super Arbeit, danke fürs teilen.

[CaH]

@cah said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

@atlantis , Forum, Danke für die viele Vorarbeit - jetzt gebe ich was zurück.

Da der Wechsel zum Stromanbieter mit dynamischen Tarifen ansteht, habe ich mich mit der Zwangsladung der Batterie durch den WR (SH8.0RT) beschäftigt. Und siehe da, per Web lässt sich das konfigurieren. Mithilfe von SunGather hab ich die entsprechenden Holding-Register gefunden.
Bisher habe ich die Register nur gelesen, nicht per ioBroker geschrieben; dazu fehlt mir noch zuviel vom ioBroker-drumherum. Aber vielleicht hilft das hier ja schon mal anderen.
Gerne reviewen und wenn für gut befunden in die von Atlantis bereitgestellten Configs integrieren. Das Format des folgenden Snippets orientiert sich an der SunGather-Config.

Danke für kurzen Hinweis, falls meine Erkenntnis nicht so neu sein sollte wie von mir empfunden

Alaaf! CaH

- name: "forced_batt_charge"
  level: 2
  address: 13140
  datatype: "U16"
  models: ["SH8.0RT"]
  datarange:
    - response: 0xAA
      value: "Enable"
    - response: 0x55
      value: "Disable"
- name: "forced_batt_charge_day"
  level: 2
  address: 13141
  datatype: "U16"
  models: ["SH8.0RT"]
  datarange:
    - response: 1
      value: "AllDaysOfWeek"
    - response: 0
      value: "WorkingDaysOnly"
- name: "forced_batt_charge_1_start_hour"
  level: 0
  address: 13142
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_1_start_minute"
  level: 0
  address: 13143
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_1_end_hour"
  level: 0
  address: 13144
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_1_end_minute"
  level: 0
  address: 13145
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_1_SOC_perc"
  level: 2
  address: 13146
  datatype: "U16"
  models: ["SH8.0RT"]
  accuracy: 1
  unit: "%"
- name: "forced_batt_charge_2_start_hour"
  level: 0
  address: 13147
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_2_start_minute"
  level: 0
  address: 13148
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_2_end_hour"
  level: 0
  address: 13149
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "HH"
- name: "forced_batt_charge_2_end_minute"
  level: 0
  address: 13150
  datatype: "U16"
  models: ["SH8.0RT"]
  unit: "MM"
- name: "forced_batt_charge_2_SOC_perc"
  level: 2
  address: 13151
  datatype: "U16"
  models: ["SH8.0RT"]
  accuracy: 1
  unit: "%"

Hei nochmal, eben bin ich auf der Suche nach weiteren bestätigenden Quellen auf diesen Link im Photovoltaikforum gestoßen. Hier sind andere Register angegeben - aber es ist die offizielle Spec.

Also bitte meine Angaben kritisch checken.
Zu Schade, dass die SunGrow-Modbus-Spec so verteilt im Netz vorliegt und nicht einfach zu finden ist.

[ostseeskipper]

Moin Zusammen,

da mich inzwischen einige per PM angefragt haben hier ein Script das den SH10RT dazu bringt heute Nacht zwangsweise zu laden.
Ab um 02 Uhr nimmt der nix mehr aus dem Speicher
ab 03 Uhr lädt er mit 4,99kW bis 04:29
ab 06:59 nimmt er dann wieder aus dem Speicher

// Automode beenden = Entladen beenden
schedule('{"time":{"exactTime":true,"start":"02:00"},"period":{"once":"17.11.2023"}}', async () => {
  setState('modbus.0.holdingRegisters.1.13049_EMS_mode_selection' /* EMS mode selection */, 2);
});
// PV Speicher Laden Starten
schedule('{"time":{"exactTime":true,"start":"03:01"},"period":{"once":"17.11.2023"}}', async () => {
  // 170 = AA (Laden)
  setState('modbus.0.holdingRegisters.1.13050_Charge/discharge_command' /* Charge/discharge command */, 170);
});
// PV Speicher Laden beenden
schedule('{"time":{"exactTime":true,"start":"04:29"},"period":{"once":"17.11.2023"}}', async () => {
  // 204 = CC (Stop)
  setState('modbus.0.holdingRegisters.1.13050_Charge/discharge_command' /* Charge/discharge command */, 204);
});
// zurück in AutoMode
schedule('{"time":{"exactTime":true,"start":"06:59"},"period":{"once":"17.11.2023"}}', async () => {
  setState('modbus.0.holdingRegisters.1.13049_EMS_mode_selection' /* EMS mode selection */, 0);
});

Blockly dann so

die Objekte sind diese

Mit 13051 wird die Ladestärke gesteuert. ACHTUNG geht nicht über 5000 !

Viel Spaß beim ausprobieren.
Natürlich macht das jeder auf eigenes Risiko

[Carsten Sauermann]

@ostseeskipper nach meiner Erfahrung kann man auch 7000 einstellen aber der macht einfach nicht mehr als 5000. Will damit nur sagen es ist nicht schlimm wenn man einen größeren Wert eingibt.

[ostseeskipper]

@carsten-sauermann said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

@ostseeskipper nach meiner Erfahrung kann man auch 7000 einstellen aber der macht einfach nicht mehr als 5000. Will damit nur sagen es ist nicht schlimm wenn man einen größeren Wert eingibt.

Das sagst du nur weil dir deshalb noch keiner kaputt(mit alter Firmware) gegangen ist.
Wie gesagt auf eigene Gefahr und in der Sungrow Modbus Spec steht halt max 5000 drin.

[Carsten Sauermann]

@ostseeskipper stimmt noch ist er ganz aber ich stelle den auch nur auf 5000 hatte aber mal beim eingeben eine 0 zu viel eingetragen. Hat trotzdem nur mit 5000 geladen...

[blacksheep587]

@ostseeskipper
Danke für das Skript. Noch eine Frage: Warum beendest du die Entnahme 1h vorher? Gibts da eine Vorgabe von Sungrow?

[ostseeskipper]

@blacksheep587 said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

@ostseeskipper
Danke für das Skript. Noch eine Frage: Warum beendest du die Entnahme 1h vorher? Gibts da eine Vorgabe von Sungrow?

Nein keine Vorgabe von Sungrow.
Wenn der Strombezug aus dem Netz günstiger ist, als hochgerechnet später (wenn wieder teuer) aus dem Speicher nimmst ist das reine Mathematik. Daher lass ich noch was im Speicher was du sonst nachladen müsstet für teurere Zeiten. Denk dran der Speicher hat ungefähr 92% Wirkungsgrad (Verhältnis zw "total charge" und "total discharge")
heisst bei 30ct in den Speicher ist wie ungefähr 33 ct in echt.

[markus397]

Wenn ich den Speicher lade und meine Verbindung zum System irgendwie abreißt, schützt das BMS das System auch wenn ich falsche Signale/Vorgaben an den Akku sende? Habe es so eingestellt das bei 90% das laden beendet wird, aber wenn Modbus ausfallen sollte kann ich das Signal ja nicht senden.

[ahnungsloshoffnungsvoll]

Hallo,
herzlichen Dank für all die tollen Postings hier, ich habe soweit alle gelesen. Leider hat es mich nicht dazu in die Lage versetzt, die modbus Abfrage hinzubekommen.

Hardware
Raspi 4 mit iobroker

SH10RT WR, Winter: SH10RT(COM1-001)
Sungrow Akku: WiNet: SBR160(COM1-200)
WLAN aktiv für Cloud. 192.168.188.107
LAN am WiNet zu Router: 192.168.188.108, 100 Mbit
LAN am WG: 192.168.188.113, 100 Mbit

Settings
Die Einstellungen habe ich von @Atlantis übernommen, vielen Dank dafür. Ich habe auch mit den unterschiedlichen Zeiten mal gespielt, welche oben diskutiert wurden.

Register & Co
Übernommen von Github

Resultat

1. Anschluss am LAN Winet: Verbindung kommt nicht zustande.
   ja: Verbunden mit Host
   ja: Lebenszeichen
   nein: Verbunden mit Gerät oder Dienst

Log:

	2023-12-06 18:48:20.476	debug	Closing client on purpose.

modbus.0
2023-12-06 18:48:19.475	debug	Cleaning up request fifo.
modbus.0
2023-12-06 18:48:19.474	debug	Socket closed with error
modbus.0
2023-12-06 18:48:19.468	info	Disconnected from slave 192.168.188.108
modbus.0
2023-12-06 18:48:19.467	debug	Closing client on purpose.
modbus.0
2023-12-06 18:48:19.465	info	Connected to slave 192.168.188.108
modbus.0
2023-12-06 18:48:19.080	info	starting. Version 5.0.11 in /opt/iobroker/node_modules/iobroker.modbus, node: v18.19.0, js-controller: 5.0.16
modbus.0
2023-12-06 18:48:18.638	debug	Plugin sentry Initialize Plugin (enabled=true)
modbus.0
2023-12-06 18:48:18.599	debug	States connected to redis: 127.0.0.1:9000
modbus.0
2023-12-06 18:48:18.539	debug	States create User PubSub Client
modbus.0
2023-12-06 18:48:18.538	debug	States create System PubSub Client
modbus.0
2023-12-06 18:48:18.525	debug	Redis States: Use Redis connection: 127.0.0.1:9000
modbus.0
2023-12-06 18:48:18.485	debug	Objects connected to redis: 127.0.0.1:9001
modbus.0
2023-12-06 18:48:18.477	debug	Objects client initialize lua scripts
modbus.0
2023-12-06 18:48:18.436	debug	Objects create User PubSub Client
modbus.0
2023-12-06 18:48:18.435	debug	Objects create System PubSub Client
modbus.0
2023-12-06 18:48:18.432	debug	Objects client ready ... initialize now
modbus.0
2023-12-06 18:48:18.395	debug	Redis Objects: Use Redis connection: 127.0.0.1:9001

2. Anschluss am WLAN Winet: Verbindung kommt nicht zustande.
   ja: Verbunden mit Host
   ja: Lebenszeichen
   nein: Verbunden mit Gerät oder Dienst

Log:

2023-12-06 18:50:47.766	debug	Closing client on purpose.
modbus.0
2023-12-06 18:50:46.764	debug	Cleaning up request fifo.
modbus.0
2023-12-06 18:50:46.763	debug	Socket closed with error
modbus.0
2023-12-06 18:50:46.755	info	Disconnected from slave 192.168.188.107
modbus.0
2023-12-06 18:50:46.753	debug	Closing client on purpose.
modbus.0
2023-12-06 18:50:46.752	info	Connected to slave 192.168.188.107

3. LAN Anschluss
   Resultat das gleiche, wie bei 1 und 2. Erhalte den bereits im Form gemosteten Socket Error.

Winet
Unter Betriebs - > weiterleiten von Daten -> MODBUS-TCP IP1 erschien früher mal die iobroker IP. Mittlerweile auch nicht mehr.

Verzweiflungstaten

• Neustart Router
• Neustart ioBroker
• Neustart WR nach jedem Wechsel
• Tischkante gebissen
• mehr Posts gelesen
• Tischkante gebissen
• wiederholtes Löschen und neu installieren des Adapters in iobroker

Ich wäre für Hilfe sehr dankbar.
LG & einen schönen Nikolaus-Abend.

[McBeath]

@ahnungsloshoffnungsvoll
Die Einstellungen im Adapter wären ja noch recht interessant gewesen, sei es drum.

Verbindung: TCP
Partner IP: IP des Wechselrichters LAN oder WINet
Port: 502 (im Wechselrichter kontrollieren)

• IP des WR aufrufen
  

• mit admin und pw8888 anmelden
  

• System/Weitergabekonfiguration/Modbus
  

• Port 502 Aktivieren
  

Geräte ID: 1 (im Wechselrichter kontrollieren)

• Gerät/Geräteliste
  

• Geräteadresse sollte auf "1" stehen
  

Dann sollte die Verbindung stehen, notfalls kann ein Update des WR helfen.

Mit dem ModbusMaster kann man dann mal versuchen einzelen Register zu lesen.
Dann kann man die Input und Holdings im IOB anpassen.

[Carsten Sauermann]

@ahnungsloshoffnungsvoll du musst an den hintern LAN Port nicht an dem vom Dongel

[McBeath]

@carsten-sauermann sagte in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

@ahnungsloshoffnungsvoll du musst an den hintern LAN Port nicht an dem vom Dongel

Stimmt so nicht ganz, mein SH8.0 läuft bei mir mit dem WiNet ohne Probleme seit 1,5 Jahren.
Es kann nur sein, das nicht alle Register Abfragbar sind.

[ahnungsloshoffnungsvoll]

@mcbeath Vielen Dank. Das Passwort kannte ich noch nicht.

Ich habe festgestellt, dass der Port 502 auch eingeschaltet ist, per Terminal konnte ich den auch vorher anpingen, habe ich nicht erwähnt. Die Geräteadresse lautet 1, für den Akku 200, wie oben in den Posts auch schon bei anderen so beschrieben.

Der WR wurde bei Installation vor 2 Wochen auf das neuste Update gebracht, wobei ich keine Versionsnummer kenne oder finde.

@carsten-sauermann Leider funktioniert das gar nicht bei mir, es kann eine Verbindung zum LAN Port nicht aufgebaut werden.

[GombersIOB]

@ahnungsloshoffnungsvoll

Mit der Liste von Atlantis habe ich auch begonnen. Bei mir hat sie nach einer Weile auch zu Abbrüchen geführt. Der Sungrow Wechselrichter verzeiht fehlerhafte Abfragen nicht (vielleicht ist es auch ein Problem des Protokolls, ich bin nicht sicher). Sicher bin ich nicht, aber ich glaube Atlantis fragt mehr Register ab als abfragbar sind. Da laufen dann Fehler auf bis die Verbindung abbricht.

Die späteren Registerlisten sind besser.