Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden
-
@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?
-
@pezi
Die Registerbelegung ist bei meinem DTSU666 mit Sicherheit völlig anders. Die Adressen 5746 und 5748 lassen sich gar nicht abfragen, die anderen lieferen meist negative Werte und völlig unplausibel. Muss mal schauen, es scheint, dass unterschiedliche Typen verbaut wurden.Nach meinem Verständnis beschreibt der Hausverbrauch die Leistung, die im Haus "verbraucht" wird. Der Wert ist daher immer positiv.
das sagte ich doch
Die in meinen System angezeigten Registerwerte lassen den Schluss zu, dass Register 5600 eher 13009 mit umgekehrten Vorzeichen entspricht
Es ist halt die Frage, ob die von Dir angenommene Registerbelegung der DTSU666 tatsächlich stimmt. Das würde ich annehemn, bevor ich die Dokumentation von Sungrow in Frage stellen würde. Ihre Annahme scheint aber auch für mich zu stimmen.
Habe mal diesen Screenshot gerade von meinen Werten gezogen:
Bleiben immer noch die Strompfade 7 und 8 zu klären, für die es ja eine Messung im WR geben müsste.
Dieser aktuelle Strom interessiert mich selber nicht wirklich. Ich schau mal drauf und versuche, meist erfolgreich, zu verstehen, wieso der Wert gerade wieder so hoch ist. Mir reicht die Annahme, dass Sungrow versteht, wie die Daten in 13007 und 13009 zustande kommen. Zusammen bilden sie die Strecke vom Vertreiler zum Wechselrichter ab. Ich könnte mir vorstellen, dass sie dazu sogar die DTSU666 abfragen. Aber es ist mir eigentlich auch egal. Denn sobald ich sie sehe, sind sie ja auch schon Vergangenheit. Wesentlich sind mir die statistischen Werte, weil die mir bei der Planung helfen.
So sieht meine Auswertung durch ioBroker aus:
Hast Du eine verständliche Erklärung zu den Bits 4 und 7?
Die habe ich bisher nicht wirklich beachtet.
Bit4: Feed-in power -> ist ja semantisch klar. Aber was mir das bringt, leuchtet mir nich unmittelbar ein. Ich schau mir das mal genauer an.
Bit7; load power - Das könnte die Abriegelung der PV-Anlage anzeigen. Zum Beispiel durfte sie ja bis 2023 nur 70% der möglichen Kapazität einspeisen, musste also abscalten -
@gombersiob
Hab mich technisch nicht richtig ausgedrückt und meinte natürlich die Leistungspfade 7 und 8. Wenn die Daten in 13007 und 13009 diese Werte abbilden würden, wären alle Werte im physikalischen Schema mit Ausnahme des Hausverbrauchs definiert, da man diesen ja aus den anderen Werten berechnen kann.
Leider ist es aber nicht so, beide Register sind vorzeichenbehaftet und ergeben in Summe den Inhalt von Register 13033.
Ich werde jetzt mal alle Daten einige Zeit loggen und visualisieren. Dann sollten die Beziehungen sichtbar werden... -
Kurzer Zwischenstand:
Ich habe die Register für verschiedene Betriebsstati geloggt und eine Auswertung gemacht. Damit sind die Werte der Register eindeutig erkennbar.
Auf die Werte des DTSU (Register 5600) kann und sollte man verzichten, da diese zwar im Mittelwert recht genau passen, für Momentaufnahmen der Leistungswerte aber zu sehr abweichen.
Ich werde für die Ermittlung meiner Verbrauchswerte (Einspeise- und Bezugsarbeit) die Werte des EVU-Zählers verwenden, da diese abrechnungstechnisch die Wahrheit sind.Ergebnisse in nachstehendem Dokument...
-
mittlerweile sind die Berechnungen fast fertig, der Teufel steckt aber wie immer im Detail.
Ich habe auch festgestellt, dass einige meiner früheren Annahmen falsch waren
Hier schon mal eine Animation, wie sich die Leistungsverläufe im physikalischen und im logischen Schema darstellen:
Ein paar kleinere Fehler sind im logischen Schema noch drin, die gehe ich aber in den nächsten Tagen auch noch an.
Ggf. sind es auch nur Rundungsfehler, wie das eine Watt, dass da immer mal zwischen Batterie und Netz angezeigt wird. -
Ich habe den WR soweit erfolgreich eingebunden und er läuft auch über Modbus fehlerfrei. Jedoch gelingt es mir nicht die beiden Register 12999 und 13029 zum Leben zu erwecken (es kommt nur einmalig
0und danach wird der DP nicht mehr aktualisiert). Mit einem von beiden könnte ich den Netzausfall erkennen und im Backup-Betrieb unnötige Verbraucher wegschalten, doch leider klappt's bei keinemHat jemand von euch die Register in Verwendung? Falls ja, sieht die Definition bei euch auch so aus?
_address name description unit type len factor offset formula role room cw isScale 12999 System_state Systemzustand uint16be 1 1 0 value false false 13029 Grid_state Netzstatus uint16be 1 1 0 value false falseFür sachdienliche Hinweise wäre ich äußerst dankbar
-
Keine direkte Antwort, aber ich benutze dafür die 5035 - Grid Frequency.
-
@berlinerbolle
cool, Danke! Welchen Wert nimmt der DP bei Netzausfall an? -
Gibt es eigentlich einen schreibbaren datenpunkt um den Backupmodus ein und auszuschalten? Die Backup Reserve kann man ja ändern.
-
Ich meine dass es "0" ist, bin mir aber nicht mehr sicher. Ich prüfe auf einfach auf <45 Hz.
Das geht über 13074 - Off grid option. Wert 170 = Netzunabhängig ja (also Backup ein), Wert 85 = Netzunabhängig nein.
P.S.: Ich habe hier meine Modbus Register abgelegt (frage aber nicht alle ab, und ein paar funktionieren nicht - muss mal aufräumen):
https://github.com/c0ldtech/sungrow
Ist aber mit "Multiple device IDs" um den Chint Stromzähler abfragen zu können. Also nicht einfach importieren, falls ihr nicht "Multiple device IDs" im Modbus Adapter angehakt habt.
-
View und Skript zur Animation sind jetzt fertig. Ich stelle sie hier mal ein, vielleicht kann ja jemand etwas davon nutzen.
Im linken Schema ist der WR an das Netz angebunden. Hintergrund dafür: Wenn der WR eingeschaltet ist (blaues Dauerlicht), die Batterie leer ist und die PV wenig oder kein Strom liefert, wird die Verlustleistung des WR aus dem Netz gezogen. Hier sind u.a. morgens nach dem Hochfahren Leistungen > 50W zu beobachten. Sichtbar sind diese Leistungen dann im Register 13033 (Zeigt den Leistungsfluss zwischen Verteilung und Wechselrichter).
Das blaue Quadrat im WR zeigt einige der möglichen Betriebszustände auf Basis des Registers 12999.
Realisiert ist die Anzeige mit einem basic-HTML Widget und folgendem Binding in der CSS Klasse:{wert:modbus.0.inputRegisters.12999_System_State; wert==32? "blinkingtext": wert==16? "blinkingtext": wert==8? "blinkingtext": ""}Hier die View:
und das Skript:
'use strict' //strikten Modus aktivieren // Änderung: Berechnung nicht über on() starten sondern über setIntervall // siehe hier: https://www.javascript-kurs.de/javascript-window-setInterval.htm function bitsDecodieren(dec, bitPosition) { return (dec & (1 << bitPosition)) === 0 ? false : true; } //on({id: 'modbus.0.inputRegisters.13007_Load_Power', change: 'any'}, function(obj) { //Bei jedem Zugriff auf das Register // on({id: 'smartmeter.0.1-0:16_7_0__255.value', change: 'any'}, function(obj) { //Bei jedem Zugriff auf das Register setInterval( //alle 3 Sekunden function(){ // Aktuelle Leistungen Laden let RegisterInhalt = (getState('modbus.0.inputRegisters.13000_Running_State')).val; let Z_LeistungVonPV = bitsDecodieren(RegisterInhalt, 0); let Z_BatterieLaden = bitsDecodieren(RegisterInhalt, 1); // ("Z" wie Zustand) let Z_BatterieEntladen = bitsDecodieren(RegisterInhalt, 2); // ("Z" wie Zustand) let Z_LastAktiv = bitsDecodieren(RegisterInhalt, 3); let Z_Stromeinspeisung = bitsDecodieren(RegisterInhalt, 4); let Z_Strombezug = bitsDecodieren(RegisterInhalt, 5); let Z_StromAusLastErzeugen = bitsDecodieren(RegisterInhalt, 7); let LadestandBatterie = getState("modbus.0.inputRegisters.13022_Batterie_level").val; let P_PV = getState("modbus.0.inputRegisters.5016_Total_DC-Power").val; // Pfad "H" im logischen Schema let P_Haus = getState("modbus.0.inputRegisters.13007_Load_Power").val; // Pfad "I" im logischen Schema let P_Netz = getState("modbus.0.inputRegisters.13009_Export_Power").val; // Pfad "K" im logischen Schema let P_BatterieABS = getState("modbus.0.inputRegisters.13021_Battery_Power").val; //Absolutwert des Batteiestroms (Vorzeichenlos) let P_AktivGesamt = getState("modbus.0.inputRegisters.13033_Total_Active_Power").val; let P_Batterie = (Z_BatterieLaden ? P_BatterieABS * -1 : P_BatterieABS); // Pfad "J" im logischen Schema Vorzeichenbehafteter Batteriestrom (+für Laden, - für Entladen) let P_BatterieEntladen = (Z_BatterieEntladen ? P_BatterieABS : 0); // Absoluter BatterieENTLADEstrom (Pfad "e" im physikalischen Schema) let P_BatterieLaden = (Z_BatterieLaden ? P_BatterieABS : 0); // Absoluter BatterieLADEstrom (Pfad "f" im phsikalischen Schema) let P_UVZuWR = ((P_AktivGesamt < 0) ? P_AktivGesamt * -1 : 0); // (Pfad "h" im physikalischen Schema), Achtung: h ist negativ! let P_PVZuBatterie = 0; if (P_PV > 0) { P_PVZuBatterie = P_UVZuWR + P_BatterieLaden; }; let P_NetzZuUV = ((P_Netz < 0) ? P_Netz * -1 : 0); // (Pfad "j" im physikalischen Schema) let P_WRVerlust = 0; if (P_PV == 0 && P_BatterieABS == 0) { P_WRVerlust = -P_AktivGesamt; }; let P_NetzZuHaus = (P_NetzZuUV - P_UVZuWR); // Leistung vom Netz zum Haus (Pfad "E" im logischen Schema) let P_NetzZuBatterie = (Z_BatterieLaden ? P_UVZuWR : 0); // Batterie Laden aus Netz (Pfad "G" im logischen Schema) let P_PVZuHaus = 0; let P_PVZuNetz = 0; let P_BatterieZuHaus = 0; let Rest = 0; if (P_PV > P_Haus) { P_PVZuHaus = P_Haus-P_NetzZuHaus; // Wenn PV-Leistung größer als Hausbedarf, wird der Hausbedarf abzüglich der Ausgleichsleistungen aus dem Netz vollständig aus der PV gedeckt Rest = (P_PV - P_PVZuHaus); // Der Rest wird weiter verteilt if (Rest > P_PVZuBatterie) { P_PVZuNetz = Rest - P_PVZuBatterie; } // Diese IF- Abfragen müssen noch überprüft werden... } else { if (P_PV > 0) { P_PVZuHaus = P_PV; } else{ P_PVZuHaus=0; } } if ((P_PVZuHaus + P_NetzZuHaus) < P_Haus) { if (P_BatterieEntladen > 0){ P_BatterieZuHaus = P_Haus - P_PVZuHaus-P_NetzZuHaus; } else { P_BatterieZuHaus = 0; } } else{ P_BatterieZuHaus = 0; } let P_BatterieZuNetz = 0; if ((P_BatterieEntladen>1) && (P_AktivGesamt>P_Haus)){ P_BatterieZuNetz = -P_Netz; } else { P_BatterieZuNetz = (P_BatterieEntladen - P_BatterieZuHaus); //Pfad "F" im logischen Schema } setState("0_userdata.0.PV.P_PV.LadestandBatterie", LadestandBatterie, true); setState("0_userdata.0.PV.P_PV.P_13033", P_AktivGesamt, true); setState("0_userdata.0.PV.P_PV.P_BatterieEntladen", P_BatterieEntladen, true); // Pfad "e" im physikalischen Schema setState("0_userdata.0.PV.P_PV.P_BatterieLaden", P_BatterieLaden, true); // Pfad "f" im physikalischen Schema setState("0_userdata.0.PV.P_PV.P_PVZuBatterie", P_PVZuBatterie, true); // Pfad "A" im logischen Schema setState("0_userdata.0.PV.P_PV.P_PVZuHaus", P_PVZuHaus, true); // Pfad "B" im logischen Schema setState("0_userdata.0.PV.P_PV.P_PVZuNetz", P_PVZuNetz, true); // Pfad "C" im logischen Schema setState("0_userdata.0.PV.P_PV.P_BatterieZuHaus", P_BatterieZuHaus, true); // Pfad "D" im logischen Schema setState("0_userdata.0.PV.P_PV.P_NetzZuHaus", P_NetzZuHaus, true); // Pfad "E" im logischen Schema setState("0_userdata.0.PV.P_PV.P_BatterieZuNetz", P_BatterieZuNetz, true); // Pfad "F" im logischen Schema setState("0_userdata.0.PV.P_PV.P_NetzZuBatterie", P_NetzZuBatterie, true); // Pfad "G" im logischen Schema setState("0_userdata.0.PV.P_PV.P_PV", P_PV, true); // Pfad "H" im logischen Schema setState("0_userdata.0.PV.P_PV.P_Haus", P_Haus, true); // Pfad "I" im logischen Schema setState("0_userdata.0.PV.P_PV.P_Batterie", P_Batterie, true); // Pfad "J" im logischen Schema //Vorzeichenbehaftet setState("0_userdata.0.PV.P_PV.P_Netz", P_Netz, true); // Pfad "K" im logischen Schema setState("0_userdata.0.PV.P_PV.P_WRVerlust", P_WRVerlust, true); // Verlustleistung des Wechselrichters }, 3000) -
Und schon sind die ersten Fehler aufgetaucht: Die Energieflüsse zwischen Netz und Batterie liefen in die falsche Richtung.
Hier die beiden betroffenen Widgets in korrigierter Version:[{"tpl":"tplHtml","data":{"g_fixed":true,"g_visibility":true,"g_css_font_text":false,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":false,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":">","visibility-val":"0","visibility-groups-action":"hide","refreshInterval":"0","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"html":"<svg viewBox=\"0 0 420 420\">\n <g stroke=\"#e000e0\" \n fill=\"none\" \n stroke-Width=\"12\" \n stroke-dasharray=\"30 10\"\n >\n <path class=\"Rechts\" d=\"M 33 6 A 205 205 0 0 0 387 6\" />\n </g>\n <style>\n\t .Rechts {\n \t animation: Animation .7s infinite linear;\n \t animation-direction: reverse;\n\t }\n @keyframes Animation {\n\t 0% {\n\t\t stroke-dashoffset: 40;\n \t}\n\t 100% {\n\t\t stroke-dashoffset: 0;\n \t }\n }\n </style>\n</svg>","class":"","comment":"","visibility-oid":"0_userdata.0.PV.P_PV.P_NetzZuBatterie","name":"Energiefluss NetzZuBatterie","locked":false},"style":{"left":"52px","top":"362px","width":"420px","height":"120px","z-index":"10"},"widgetSet":"basic"},{"tpl":"tplHtml","data":{"g_fixed":true,"g_visibility":true,"g_css_font_text":false,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":false,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"<","visibility-val":"-1","visibility-groups-action":"hide","refreshInterval":"0","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"html":"<svg viewBox=\"0 0 420 420\">\n <g stroke=\"#e000e0\" \n fill=\"none\" \n stroke-Width=\"12\" \n stroke-dasharray=\"30 10\"\n >\n <path class=\"Links\" d=\"M 33 6 A 205 205 0 0 0 387 6\" />\n </g>\n <style>\n\t .Links {\n \t animation: Animation .7s infinite linear;\n \t animation-direction: normal;\n\t }\n @keyframes Animation {\n\t 0% {\n\t\t stroke-dashoffset: 40;\n \t}\n\t 100% {\n\t\t stroke-dashoffset: 0;\n \t }\n }\n </style>\n</svg>","class":"","comment":"","visibility-oid":"0_userdata.0.PV.P_PV.P_BatterieZuNetz","name":"Energiefluss BatterieZuNetz","locked":false},"style":{"left":"52px","top":"362px","width":"420px","height":"120px","z-index":"10"},"widgetSet":"basic"}] -
Hier mal die aktuellen Leistungsverläufe mit WR-Verlusten:
Im Skript war auch noch ein Fehler:
P_WRVerlust = -P_AktivGesamt; <- Hier hat das "-" vor "P_AktivGesamt" gefehlt...
Hab's oben bereits korrigiert.
-
Ich verstehe nicht ganz, wie du den Verlust des WR ausrechnest. Bei mir ist in 13033 immer die (vom WR errechnete) Gesamtlast des Hauses. Ist das bei dir ein anderer Wert?
-
@berlinerbolle
Die Gesamtlast des Hauses steht in Register 13007. Register 13033 zeigt den Leistungsfluss zwischen Wechselrichter und Elektroverteilung. Wenn weder von der Batterie noch von den Panels Leistung kommt, wird die Verlustleistung des WR aus dem Netz gedeckt. Register 13033 zeigt dann negative Werte.
Wenn es morgens dämmert, beginnen die Panels Leistung zu liefern. Der WR schaltet dann vom Standby (in dem er nahezu keine Leistung benötigt) in den Betriebsmodus (Schütz zieht an, die Leistungselektronik wird aktiviert). Unmittelbar nach dem Einschalten wird die Verlustleistung komplett aus dem Netz gedeckt (sofern auch die Batterie leer ist)
Mit steigender Leistungslieferung der Panels reduziert diese den Leistungsfluss aus dem Netz bis dass die Verlustleistung vollständig aus den Panels gedeckt wird. Der Wert in Register 13033 steigt in dieser Zeit von negativen Werten über 0 in den positiven Bereich. Erst wenn von den Panels genügend Leistung kommt um die Verlustleistung des WR zu decken, zeigt Register 5016 einen Wert. Und zwar den Wert, der über der Verlustleistung liegt. Ich habe diesen Zeitbereich mal geloggt:
Da Register 13033 auch dann negativ wird, wenn die Batterie aus dem Netz geladen wird, muss man diesen Fall natürlich bei der Ermittlung der Verlustleistung berücksichtigen. Letztendlich ist meine Bezeichnung "Verlustleistung" nicht ganz korrekt. Vielmehr zeigt dieser Wert nur den aus dem Netz bezogenen Anteil. Der von der DC-Seite (Batterie und Panels) kommende Anteil wird vom System einfach unterschlagen.
Die Verlustleistung der Batterie und der aus der Batterie kommende Anteil der WR-Verluste kann nicht direkt ermittelt werde. Die Verlustarbeit ergibt sich aber aus der Different der Register 13012 (in die Batterie eingespeiste Arbeit) und 13026 (aus der Batterie entnommene, oder besser, ins Haus exportierte Arbeit).
In meinem Fall (2180,4 kWh - 2019,3 kWh).
Seit die Batterie in Betrieb ist, wurden also 161kWh "verheizt". -
Gibt es hier jemand, der die Wallbox von Sungrow über Modbus mit abfragt?
Ich habe am SH10RT noch eine Wallbox von Sungrow AC011E-01 mit angebunden. In der isolarcloud sehe ich die Wallbox auch. Mir fehlen aber die Modbus Register zum auslesen.
Oder hat jemand eine Idee, wie ich an die fehlenden Register komme?
Grüße Lars
--- EDIT ---
Ich antworte mir mal selbst. Hier ist die Lösung dazu: sungrow-wallbox-ac011e-01-erfolgreich-mit-modbus-eingebunden
-
Guten Tag,
Ich habe Versucht mit dem Energieflussadapter im IOBroker mir folgende Daten über Modbus zu holen:
Einmal von dem Sungrow Hybrid WR SH10RT und
einmal vom Sungrow String WRSG8.0RTBeide habe ich über den Modbus Adapter in den IOBroker erfolgreich integrieren können.
Sungrow String WR SG8.0RT über den LAN Port vom WiNet-S
Sungrow Hybrid WR SH10RT über den LAN Port direkt am WRDie Register konnten gestern Abend von beiden WR ausgelesen werden.
Allerdings hat die IP Adresse des SH10RT im Protokoll des IOBrokers immer folgende Meldung gebracht:
Connected to slave
disconnected to slave
Die Register wurden aber trotzdem ausgelesen. Heute Morgen aber kamen keine aktuellen Registerwerte mehr an vom SH10RT. Der SG8.0RT liefert aktuell weiterhin Werte an den IOBroker.Habe dann den SH10RT mal über den LAN Port vom WiNet-S bzw auch über WLAN des WiNet-S (Witeliste mit der IP vom IOBroker erweitert) in den Modbus Adapter integriert, aber keine Daten werden gesendet. Nur einmalig, wenn ich den Modbus Adapter starte, werden die Register gelesen, wenn Zustand „Verbunden mit Gerät oder Dienst“ kurz nach dem Modbus Adapterstart grün anzeigt. Dann springt er in den Zustand siehe Bild.
Dachte mir ich ändere die Standartwerte Mal auf folgende Werte, aber kein Erfolg
Habe hier auf der Seite schon alles Mögliche über das Problem gelesen aber ich komme leider nicht zu einer Lösung.
Zusammengefasst: Der String WR liefert die Registerdaten ohne Probleme. Der Hybrid WR leider seit heute Morgen nur einmalig bei jedem Modbus Start. Gestern Abend lieferte er noch ständig neue Daten. Es scheint so, als dass er zu beschäftigt ist um den Modbus zu bedienen. Gibt es sowas? Wäre super wenn mich jemand unterstützen könnte, danke. -
@jahnel Ich nutze am SH10RT für den Modbus den LAN-Anschluss des WR. So hat es auch der Support von Sungrow empfohlen. Mein SH10RT hängt sozusagen 2x am gleichen Netzwerk mit zwei IP-Adressen. Einmal LAN des WR und einmal LAN des WiNet-S.
Alle Register vom WR hole ich über den LAN des WR mit folgenden Einstellungen:
Über die IP des WiNet-S hole ich mir die Register der Wallbox. Der SH10RT liefert mit diesen Einstellungen sauber und stabil die Register. Leider kann ich das vom WiNet-S nicht behaupten. Der Steigt immer wieder aus. Liegt wohl an der schwachen CPU des WiNet-S.
Auf dem SH10RT läuft folgende Firmware:
Modellbezeichnung
SH10RT
Nennwirkleistung
10.00 kW
Nennblindleistung
6.00 kvar
ARM-Softwareversion
SAPPHIRE-H_01011.51.05
MDSP-Softwareversion
SAPPHIRE-H_03011.51.04
SDSP Softwareversion
SUBCTL-S_04011.01.01Eventuell hilft das weiter. Grüße Lars
-
@eisbaeeer
@eisbaeeer
Danke für deine Hilfe. Das Problem habe ich ja bei beiden Varianten LAN direkt am WR und auch beim LAN Anschluss des WinNet-S des WR.
Software habe ich eine neuerer
ARM-SoftwareversionSAPPHIRE-H_01011.71.18
MDSP-SoftwareversionSAPPHIRE-H_03011.71.15
weiß nicht ob das dann das Problem ist!?
Könntest du mir einmal bitte deine Werte aus dem Modbus Adapter hier einstellen, meine aktuellen Werte
sehen so aus, vileeicht liegt hier ja das Problem -
@jahnel sagte in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:
@eisbaeeer
@eisbaeeer
Danke für deine Hilfe. Das Problem habe ich ja bei beiden Varianten LAN direkt am WR und auch beim LAN Anschluss des WinNet-S des WR.
Software habe ich eine neuerer
ARM-SoftwareversionSAPPHIRE-H_01011.71.18
MDSP-SoftwareversionSAPPHIRE-H_03011.71.15
weiß nicht ob das dann das Problem ist!?
Könntest du mir einmal bitte deine Werte aus dem Modbus Adapter hier einstellen, meine aktuellen Werte
sehen so aus, vileeicht liegt hier ja das Problem
