Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden
-
@markus397
manchmal kanns so einfach sein, dass man nicht drauf kommt.
Läuft, danke dir -
so, dann bin ich einen Schritt weiter, aber irgendwie doch nicht.
ich konnte jetzt überprüfen, dass der Modbus an ist und die Geräteadresse vom WR 1 ist.
allerdings bekomme ich weder mit Modbus-Adapter ne Verbindung hin, noch mit dem QModMaster.
Der QModMAster scheint wohl eine Verbindung aufbauen zu können, aber der Abruf der Daten funktioniert nicht, siehe Screenshot
-
Auf die Adresse 0 kann man auch nicht zugreifen. Gib doch mal 12999 ein.
btw: Ich nutze den VagaModbusAnalyzer, den QModMaster kenne ich nicht. Wenn ich bei meiner App die 0 auswähle, bekomme ich auch irgendwann Read Timeout.
-
Hi, Danke für die Info.
Bei mir stellt es sich folgend dar:
Verbindung mit hinteren Port; dauerndes verbinden und trennen, ich erhalte jedoch Daten.
Verbindung mit Winet-S Port; stabile Verbindung (im Adapter alles grün), aber kein Datenempfang. -
@gombersiob
bringt leider keine Verbesserung. wenn ch mit dem QModMaster die Verbindung überprüfe (siehe Spoiler), kann er die IP anpingen und der Port ist auch offen. Aber an Daten komme weiterhin nicht ran
-
ich habe jetzt nochmal den hinteren LAN-Anschluss versucht. Der hat sich jetzt hierfür nochmal eine neue IP-Adresse gezogen.
Erstaunlicherweise funktioniert es jetzt. Wahrscheinlich hatte ich heute mittag bei meinem ersten Versuch mit dem hinteren LAN-Anschluss nicht lange genug gewartet, sodass die Fritzbox die neue IP-Adresse angezeigt hatte. -
@trapper
Die Daten kommen auch bei mir nur über den hinteren Port.
Versuche ich eine Verbindung des modbus-Adapters über Winet-S, kommt es dort zu dem von Dir beschriebenen dauernden verbinden und trennen.
Hier mal meine Einstellungen des Adapters, vielleicht liegt es ja am Timing:
-
@saarlanduhu
Um zu verhindern, dass über DHCP neue IP-Adressen zugewiesen werden, kannst Du in der FB die Adresse reservieren.
Unter Heimnetz/Netzwerk/Netzverbindungen geht Du bei dem betroffenen links auf das Bleistift:
dort dann das Häkchen setzen:
Oben auf der Seite kannst Du auch einen eindeutigen Gerätenamen vergeben:
-
Steck den Stecker doch nochmal zurück auf den WiNet-S Steckplatz. Das Abziehen des Kabels führt auch zu einem Reset auf den Modbus-Adapter. Wenn eine fehlerhafte Sequenz in der Abfrage die Ursache war (was ich bisher immer noch glaube), sollte es jetzt auch da wieder funktionieren. Würde mich wirklich interessieren.
-
Hi Pezi,
hatte ähnliche Einstellungen. Unterschied war Wartezeit bis zum erneuten Verbinden. Da hatte ich 60000 ms. Ein Ändern auf 4000ms hat wie erwartet zu einem schnelleren Verbinden und Trennen geführt.
-
Ich habe mal versucht die einzelnen Leistungsdaten der Sungrow-App aus den verfügbaren Registern nachzubilden, komme dabei allerdings nicht wirklich weiter.
Verfügbar sind ja zu den Leistungen folgende Informationen:Register:
5016 Total DC power
5600 DTSU666
13007 Load power
13009 Export power
13021 Battery power
13033 Total activ powersowie die Status-Bits aus Register 13000
Bit 0 PV power
Bit 1 Battery charging
Bit 2 Battery discharging
Bit 3 Positiv load power
Bit 4 Feed in power
Bit 5 Import power from grid
Bit 6 Reserved
Bit 7 Negativ load powerPhysikalisch stellt sich das dann so dar:
und wird in der App wie folgt angezeigt:
Wie zu sehen ist, passen die beiden Varianten hinsichtlich ihrer Daten nicht wirklich zusammen.
Direkt zugeordnet werden können nur die Register 5016, 5600 und 13021.
Die übrigen Register und Werte scheint der WR irgendwie intern zu ermitteln.
Wichtig wäre zu wissen, wo die Werte 7 und 8 aus der ersten Zeichnung zu finden sind. Evtl. werden die ja in einem der anderen Register (13007, 13009 und 13033) ausgegeben. Aus den Namen dieser Register sind deren Inhalte, zumindest für mich, nicht eindeutig verständlich.Ich habe meinen bisherigen Erkenntnisstand mal in folgender Tabelle zusammengefasst und hoffe darauf, dass Ihr da etwas Licht in Dunkle bringen könnt und die noch leeren Feldern in den beiden unteren Tabellen entsprechend füllen könnt.
Hier...
https://noegel.io/posts/2022-10-09-sungrow/
... wurde bereits intensiv auf das Thema eingegangen. Das dort veröffentliche Skript habe ich auch im Einsatz, die angezeigten Werte sind teilweise nicht plausibel. Gerade der Bereich zwischen Batterie und Netz (Werte F und G) passt nicht. -
@pezi
In dem Script der von Dir verlinkten Seite wird doch die Kalkulation durchgeführt:Wenn PV-Load (Reg 5016) größer als Hausverbrauch (Reg 13007) ist, dann kommt der Strom fürs Haus von der PV-Anlage, der Rest geht in die Batterie (wenn Batterie geladen wird) uns/oder den Export.
Das stimmt zwar nicht ganz, denn es kann auch sein, dass Strom importiert wird (fürs Haus) und die PV-Anlage nur die Batterie lädt. -
@gombersiob
Zurückstecken war leider nicht erfolgreich. LAN-Kabel steckt jetzt wieder am hinteren Port. -
@saarlanduhu
Danke. Ich nutze beide Anschlüsse gleichzeitig, problemlos. Die Probleme, auch die Abbrüche, hatte ich bis die Liste der Ports stimmte. Seit einem Jahr ist aber alles in Ordnung.
Über den WiNet-S-Anschluss habe ich den ioBroker angebunden, über den anderen frage mit einem eigenen Programm zyklisch die Register ab und schreibe sie als XML File weg - für spätere Auswertungen. -
@gombersiob
Wenn Register 13007 den tatsächlichen Hausverbrauch darstellt, kann es sich dabei nur um einen berechneten Wert aus Daten des Wechselrichters und des Smartmeters handeln, da der im oberen Schema dargestellte Pfad 4 nicht direkt gemessen wird. Vielleicht ist es ja so, eine Bestätigung dazu habe ich jedoch nicht gefunden
Was der WR aber wirklich messen könnte wären die Pfade 7 und 8 des Schemas.
Die Pfade 5 und 6 stehen vorzeichenbehaftet im Register 13021, Pfade 9 und 10 ebenfalls vorzeichenbehaftet in Register 5600.
Physikalisch betrachtet sind die logisch doppelt dargestellten Pfade 5/6, 7/8 und 9/10 jeweils nur ein Weg der die Leistung entweder nur in die eine oder andere Richtung transportiert.
Wechselt man vom physikalischen Schema 1 ins logische Schema 2, können die dort dargestellten Werte der Pfade A bis K überwiegend nur aus den Registern und den Status-Bits berechnet werden.
Mathematisch kein Problem wenn man die Werte der Pfade 1 bis 3 und 5 bis 10 kennt.Wenn die fehlenden Werte in den Registern 13009 und 13033 stecken bzw. daraus mit Hilfe der Statusbits ermittelt werden können, wären alle erforderlichen Daten verfügbar. (Die genaue Aussage der Bits 3 und 7 ist mit auch nicht klar...)
Und genau darum geht es mit in meinen Posting: Was genau die Register 13007, 13009 und 13033 enthalten habe ich in keiner offiziellen Dokumentation von Sungrow gefunden.
Da sich die Werte der Register schnell ändern und aufgrund der linearen Messabfolge keine zeitgleichen Messwerte ermitteln lassen, ist eine Herleitung auf Grundlage von Beobachtungen nicht sicher möglich.Auch bei leerer Batterie und ohne Einspeisung von den Panels (DC Seite also "stromlos") zeigen die Register 13007 positive und 13009 negative Werte, die hinsichtlich ihres Betrags etwa dem Wert aus Register 5600 entsprechen. Da der WR offensichtlich die Daten vom Smartmeter bei der Berechnung der Daten seiner eigenen Register berücksichtigt, waren die Daten von Register 5600 für eine eigene Auswertung ggf. nicht erforderlich und sollten auch aufgrund nicht-synchroner Messung nicht verwendet werden.
Hier mal eine Momentaufnahme der o.g. Register (Der Wert von "Zähler" kommt von der Messeinrichtung des Versorgers):
Speziell Register 13033 zeigt nicht nachvollziehbare Werte (Gleiche Bedingungen wie wie oben, DC =0, gleiches Bitt-Setting):
Das würde nur Sinn machen, wenn im Haus eine weiter Stromquelle vorhanden ist (z.B. Balkonkraftwerk)
-
Habe es hier beim Überfliegen nicht gefunden, daher mal für alle die es eventuell interessiert: es gibt inzwischen auch die Möglichkeit, die Batteriewerte über Modbus auszulesen, speziell den tatsächlichen (nicht den unter Berücksichtigung von Min/Max berechneten) SOC und vor allem die VMin/VMax Werte der einzelnen Batteriemodule.
Die Batterie taucht (mit aktueller Firmware) aber als eigenes Modbus device auf (bei mir ID 200), im Modbus Adapter müsst ihr also "Multiple device IDs" angehakt haben. VORSICHT, dadurch ändern sich die Adressen der Datenpunkte, falls ihr das bisher nicht getan habt.
Was vorher also zum Beispiel "modbus.2.holdingRegisters.13057_Max__SOC" war, wird dann zu "modbus.2.holdingRegisters.1.13057_Max__SOC" - mit allen entsprechenden Konsequenzen (Scripte müssen angepasst werden etc.).
Eine Alternative wäre, eine zusätzliche Modbus Adapter Instanz für die Batterie zu erstellen, aber nach dem was man hört, mag der Sungrow mehrere Modbus Clients nicht so sehr.Eine tsv mit den entsprechenden Modbus Registern der Batterie findet ihr zum Beispiel hier - Batterieregister am Ende der Datei.
-
Vielleicht ist es ja so, eine Bestätigung dazu habe ich jedoch nicht gefunden
Ich habe die Interpretation für die Register weitgehend von @Atlantis übernommen. Das Register 5601 (Offset 5600) sagt mir auch gar nichts.
In der Dokumentation steht zu 13008 (Offset 13007) "Power consumed by loads". Wer soll den Strom denn konsumieren anstatt der Verbraucher ds Hauses?
Zu Register 13010 (Offset 13009) steht eindeutig: "Power delivered by the inverter to power grid". Ich denke, das ist es.
Dass Zähler und Register nicht übereinstimmen ist vermutlich erwartbar. Das sind halt Anzeigen zu einer bestimmten Zeit und mit der jeweiligen Messgenauigkeit und Messmethode. Ob das Alles immer gleich ist würde ich doch bezweifeln wollen.Auch bei leerer Batterie und ohne Einspeisung von den Panels (DC Seite also "stromlos") zeigen die Register 13007 positive und 13009 negative Werte
Das stimmt doch wohl auch so. Das Haus speist nie ein, sondern verbraucht nur (könnte vielleicht mit einem zusätzlichen Balkonkraftwerk anders sein? Keine Ahnung. Aber es ist ein signed value, das bringt mich auf die Idee). Und 13009 wird negativ bei Import (was bei Dunkelflaute wohl notwendig ist) und ist positiv bei Export (wenn die Panels arbeiten).
-
@gombersiob said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:
Das Register 5601 (Offset 5600) sagt mir auch gar nichts.
Kannst Du mir einen Link auf die Beschreibung geben?
-
Ich habe jetzt zumindest die Erklärung gefunden. Register 13008 und 5601 (immer Offset -1) zeigen bei einem WR immer "dass gleiche an" (innerhalb technicher Toleranzen) nämlich den Hausverbrauch. Die unterscheiden sich erst be mehreren WRs - dann zeigt 13007 nur die Werte des aktuellen WRs an, während 5601 (das Modbus-Register der EVU) die Gesamtleistung anzeigt.
Das habe ich der Diskussion im Photovoltaikforum entnommen.
-
@gombersiob
Die Quelle finde für die Register finde ich nicht mehr. Aber hier sind die Einträge aus meiner Modbus-Instanz zum DTSU666:
Die von Sungrow ausgelieferten DTSU666 haben wohl eine Sungrow-spezifische Firmware, sodass die entsprechenden Register direkt über den Modbus verfügbar sind. Es gibt zum DTSU noch mehr Register, die z.B. die Ströme der einzelnen Phasen anzeigen.
Näheres dazu hier:
https://www.photovoltaikforum.com/thread/158136-sungrow-sammelthread-produktmanagement/?postID=2697060#post2697060Nur um Missverständnisse zu vermeiden: Nach meinem Verständnis beschreibt der Hausverbrauch die Leistung, die im Haus "verbraucht" wird. Der Wert ist daher immer positiv. Der Hausverbrauch kann mit dem Standardaufbau des Systems nicht direkt gemessen werden (Pfad 4 in der physikalischen Darstellung). Register 13007 könnte einen entsprechend berechneten Wert haben.
Register 5600 zeigt eindeutig den vorzeichenbehafteten Leistungsfluss vom/zum Netz (Pfad 3)
Die in meinen System angezeigten Regsiterwerte lassen den Schluss zu, dass Register 5600 eher 13009 mit umgekehrten Vorzeichen entspricht.Wenn Register 13009 negativ ist (5600 positiv), entspräche das Strompfad 10, positive Werte von 13009 (5600 negativ) dementsprechend Strompfad 9. Der jeweils andere ist dann natürlich 0.
Bleiben immer noch die Strompfade 7 und 8 zu klären, für die es ja eine Messung im WR geben müsste...
Hast Du eine verständliche Erklärung zu den Bits 4 und 7?
