Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden

[GombersIOB]

@jwerlsdf
Ich glaube in der GitHub-Beschreibung ist ein Link. Und in der Beschreibung gibt es dann Fallunterscheidungen je nach WR.

[jwerlsdf]

@gombersiob
Finde ich leider nicht

[GombersIOB]

@jwerlsdf

Finde ich leider nicht

Merkwürdig. Ich hatte es gleich. Es gibt aber ein paar GitHub Einträge, vielleicht ist die Quelle nicht überfall aufgeführt. ich füge mal ein Dokument von mir bei. Ob das aktuell ist, habe ich nicht geprüft.

f2a8971f-a3b9-4dc1-8608-a7d3d3001a9e-Communication.Protocol.of.Residential.Hybrid.Inverter_V1.1.2_EN.pdf

[Maddm]

@drurob
ich würde mich gern mal an das Problem mit der Umstellung des Typs von 13021 dran hängen:
Hallo zusammen, ich hab an meiner PV seit fast 2 Jahren einen SH80RT Wechselrichter, dessen Daten ich via Modbus per IOBroker auslese und visualisiere die Daten in einem Stromflussdiagramm, dessen Logik ich komplett von hier übernommen habe.

Durch die Umstellung war der angezeigte Ladewert viel zu hoch, durch Suche habe ich gefunden, dass man den Type von 13021 selbst umstellen kann (unter Instanzen - modbus0 - Eingangsregister - den Typ von 13021 von unsigned 16 bit (Big Endian) umstellen auf signed 16 bit (Big Endian)".
Danach stehen in 13021 korrekte Werte, mit Vorzeichen drin (negative Werte = Ladung in die Batterie, positive Werte: Entladung der Batterie).

Welche Änderung muss ich jetzt im Blockly bzw. im Scriptblock, der auf der oben verlinken Seite drauf ist machen, damit die Berechnung der einzelnen Werte (Stromfluss in/von der Batterie, ins/vom Netz) wieder passen?

[wolfi913]

@maddm sagte in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

Welche Änderung muss ich jetzt im Blockly bzw. im Scriptblock, der auf der oben verlinken Seite drauf ist machen, damit die Berechnung der einzelnen Werte (Stromfluss in/von der Batterie, ins/vom Netz) wieder passen?

schau mal hier…

[Maddm]

@wolfi913
das scheint bei mir nicht zu gehen, der Stromfluss scheint zwar zu stimmen, aber die Werte gehen nicht auf.

Hier der Code den ich verwende (da habe ich die Codezeile aus dem oben verlinkten Beitrag mit reingenommen):

function decToBit(dec, bitPosition) {
    return (dec & (1 << bitPosition)) === 0 ? false : true;
}

// Creates a state if it does not exist yet
function createStateIfNotExists(state, name)
{
    // createState(state, 0, true, {name: name,  type: "number", role: 'value'}, function () {});    
    if ( !existsState(state )) {
        createState(state, 0, false, {name: name,  type: "number", role: 'value'}, function () {});    
    } 
}

// Create states
createStateIfNotExists("0_userdata.0.PV.PvToLoad", "Power from PV to load");
createStateIfNotExists("0_userdata.0.PV.PvToBat", "Power from PV to bat");
createStateIfNotExists("0_userdata.0.PV.PvToGrid", "Power from PV to grid");

createStateIfNotExists("0_userdata.0.PV.BatToLoad", "Power from Bat to load");
createStateIfNotExists("0_userdata.0.PV.BatToGrid", "Power from Bat to grid");

createStateIfNotExists("0_userdata.0.PV.GridToLoad", "Power from grid to load");
createStateIfNotExists("0_userdata.0.PV.GridToBat", "Power from Gridto battery");

createStateIfNotExists("0_userdata.0.PV.SignedBat", "Battery but with minus sign for charging");


// Decode running state flags
$powerGeneratedFromPV = decToBit(dec, 0);
$batteryCharging = decToBit(dec, 1);
$batteryDischarging = decToBit(dec, 2);
$loadActive = decToBit(dec, 3);
$powerFeedIntoGrid = decToBit(dec, 4);
$powerImportFromGrid = decToBit(dec, 5);
$powerGeneratedFromLoad = decToBit(dec, 7);

// Save running state more speaking fields
setState("0_userdata.0.PV.PowerGeneratedFromPV", $powerGeneratedFromPV, true);
setState("0_userdata.0.PV.BatteryCharging", $batteryCharging, true);
setState("0_userdata.0.PV.BatteryDischarging", $batteryDischarging, true);
setState("0_userdata.0.PV.LoadActive", $loadActive, true);
setState("0_userdata.0.PV.PowerFeedIntoGrid", $powerFeedIntoGrid, true);
setState("0_userdata.0.PV.PowerImportFromGrid", $powerImportFromGrid, true);
setState("0_userdata.0.PV.PowerGeneratedFromLoad", $powerGeneratedFromLoad, true);

// Read current power levels of bat, pv, load and grid
$load = getState("modbus.0.inputRegisters.13007_Load_power_").val;
$grid = getState("modbus.0.inputRegisters.13009_Export_power").val;
$pv = getState("modbus.0.inputRegisters.5016_Total_DC_Power").val;
$battery = Math.abs(getState('modbus.0.inputRegisters.13021_Battery_power_').val);


// Write signed bat

setState("0_userdata.0.PV.SignedBat", $batteryCharging ? $battery * -1 : $battery, true);

// Calculate PV
$pvToBat = 0;
$pvToLoad = 0;
$pvToGrid = 0;
$loadRemaining = $load;
if ($powerGeneratedFromPV) {
    $remaining = $pv;
    if ($remaining > $loadRemaining) {
        $pvToLoad = $loadRemaining;
        $remaining -= $load;
        $loadRemaining = 0;
    } else {
        $pvToLoad = $remaining;
        $loadRemaining = $load - $remaining;
        $remaining = 0;
        
    }
    
    if ($batteryCharging) {
        if ($remaining > $battery) {            
            $pvToBat = $battery;
            $remaining -= $battery;
        } else {            
            $pvToBat = $remaining;
            $remaining = 0;
        }
    }
    
    if ($grid > 0) {
        $pvToGrid = Math.min($grid, $remaining);
    }
}
setState("0_userdata.0.PV.PvToLoad", $pvToLoad);
setState("0_userdata.0.PV.PvToBat", $pvToBat);
setState("0_userdata.0.PV.PvToGrid", $pvToGrid);

// Calculate Bat
$batToLoad = 0;
$batToGrid = 0;
if ($batteryDischarging) {
    $remaining = $battery;
    if ($remaining > $loadRemaining) {
        $batToLoad = $loadRemaining;
        $remaining -= $loadRemaining;
        $loadRemaining = 0;
    } else {
        $batToLoad = $remaining;
        $loadRemaining -= $remaining;
        $remaining = 0;        
    }
    
    if ($powerFeedIntoGrid) {
        $batToGrid = Math.min($grid, $remaining);
    }
}

setState("0_userdata.0.PV.BatToLoad", $batToLoad);
setState("0_userdata.0.PV.BatToGrid", $batToGrid);

// Calculate grid
$gridToBat = 0;
$gridToLoad = 0;
if ($grid < 0) {
    $remaining = Math.abs($grid);
    if ($remaining > $loadRemaining) {
        $gridToLoad = $loadRemaining;
        $remaining -= $loadRemaining;
        $loadRemaining = 0;
    } else {
        $gridToLoad = $remaining;
        $loadRemaining -= $remaining;
        $remaining = 0;        
    }
    
    if ($batteryCharging) {
        $gridToBat = Math.min($battery, $remaining);;
    }
}

setState("0_userdata.0.PV.GridToLoad", $gridToLoad);
setState("0_userdata.0.PV.GridToBat", $gridToBat);

das führt zu folgenden Werten in den einzelnen Registern:

Stromerzeugung PV = 3159 W
Hausverbrauch = 413 W
bleiben also 2746 W um die Batterie zu laden, da stehen aber nur 2462 W, wo sind die restlichen 284 W hin?

Müssen bei noch weiteren Registern die "Typen" geändert werden oder ist meine Änderung einfach falsch?

[wolfi913]

@maddm

Im Bereich modbus.0 ändert die Einstellung ja nichts. Es wird nur für die Weiterverarbeitung im Script der absolute Wert für $battery (ohne negative Kennzeichnung) verwendet. So wie es vor der Firmwareänderung war. Das Script arbeitet dann so wie vorher unsigned weiter. Die verarbeiteten Werte speichert das Script ja unter 0_userdata.0.PV.xxx. Dort sollten dann wieder die korrekte und sinnvolle Werte stehen. In der Beschreibung vom Scriptersteller steht ja auch, dass die Werte die über Modbus geliefert werden ohne Weiterverarbeitung (gerade in Verbindung mit einer Batterie) nur bedingt direkt nutzbar sind.

Ergänzung:
Was mir gerade noch bei Deinem obigen Script aufgefallen ist.
Du hast das (Arbeits-)Script von der Homepage direkt verwendet. Ich meine das ist nicht ganz vollständig. Das enthält m.M.n. gar keinen Trigger der die Änderungen kontinuierlich einliest und weiterverarbeitet. Sinnvoll wäre das Script oder Blockly das dort im unteren Bereich unter Downloads verlinkt ist zu verwenden.

[GombersIOB]

@maddm

Ich bin immer etwas im Zweifel, welches Register gemeint ist, da der Dokumentationsoffset immer um 1 höher ist als die Registeradresse. Ich gehe mal von Battery Power aus.
Die Register 13020 bis 13022 sind wie folgt in der Dokumentation beschrieben:

Ich habe auch eine SH8.0RT und dort bei mir sind die Register auch genauso als UNSIGNED 16bit Integer im IOBroker eingetragen.

Diese Eintragung hat gar nichts damit zu tun wie der Wechselrichter seine Daten speichert oder sie an den aufrufenden Master sendet. Das Datenformat ist nicht Bestandteil des MODBUS-Protokolls. In dem werden einfach Register abgefragt und die Inhalte geschickt - aber nicht interpretiert. Man kann damit kein Vorzeichenbit im Wechselrichter einschalten!

Die Eintragung betrifft nur den IOBroker Modbus-Adapter selber, damit der weiß, wie er die Register interpretieren muss. Wenn die Zahl als signed verstanden werden soll, wird das erste Bit als Vorzeichen (0=="+"; 1=="-") interpretiert. Wird es als unsigned definiert werden alle 16 Bit als positiver Zahlwert gerechnet.
In die Objekte wird dann der entsprechend umgerechnete Dezimalwert eingetragen.

Woher das kommt, dass das Register 13021 jetzt vorzeichenbehaftet sein soll, würde mich doch interessieren. Mein letztes Dokument über die Beschreibung der Register ist vom August 2023 (V1.1.2), da ist es noch unsigned. Habt Ihr dazu neuere Dokumentation.

Ich habe mir gerade mal aller Werte der BatteryPower (13021) aus dem letzten Jahr angesehen. Da war bei mir absolut nichts merkwürdig.

[wolfi913]

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

Woher das kommt, dass das Register 13021 jetzt vorzeichenbehaftet sein soll, würde mich doch interessieren. Mein letztes Dokument über die Beschreibung der Register ist vom August 2023 (V1.1.2), da ist es noch unsigned. Habt Ihr dazu neuere Dokumentation.

Das hatte ich mal dazu gefunden. Die Änderung gibt's ab einer Firmware-Version 95.03 (Nov24). Die aktuellste Doku die es momentan gibt ist die 1.1.5 (Sep24). Dort ist die Anpassung noch nicht drin. Kommt drauf an, welche Firmware momentan läuft ob's mit oder ohne Vorzeichen ist.
Beide Informationen hier entdeckt https://github.com/evcc-io/evcc/issues/17461
Bei evcc ist die Änderung auch bereits ins Sungrow-Template mit int16 eingeflossen. Ebenso bei Homeassistant
Mehr Infos hab ich dazu aber leider auch nicht

JuMa1967 created this issue in evcc-io/evcc

closed Sungrow SH6.ORT Update führt zu falscher Auswertung des Batteriespeichers #17461

[Maddm]

Ich bin jetzt leider komplett verwirrt.
Ich habe auf 2 Systemen einen iobroker laufen, einer liest die "13021_Batterie_Power_" aus wie bisher, in der anderen Instanz habe ich die "Type" des Registers auf "Signed 16bit (Big Endian)" umgestellt.

In beiden Instanzen logge ich mit dem exakt gleichen Script (max Load Power für die Batterie ist auf 4000W eingestellt):

on({ id: "modbus.0.inputRegisters.5016_Total_DC_Power", change: 'ne'}, function(obj) {
    var $load = getState("modbus.0.inputRegisters.13007_Load_power_").val, // Hausverbrauch
        $grid = getState("modbus.0.inputRegisters.13009_Export_power").val,  // Netzbezug/-einspeisung
        $pv = getState("modbus.0.inputRegisters.5016_Total_DC_Power").val,  // Stromproduktion vom Dach
        $battery = getState("modbus.0.inputRegisters.13021_Battery_power_").val; // Batterieladung
    console.log('Testwerte: vom Dach = '+$pv+', ins Haus: '+$load+', in Batterie: '+$battery+', ins Netz: '+$grid)
});

Dass der Wert für "$battery" unterschiedlich ist, ergibt sich aus dem Datentyp, aber warum die Werte $load+$grid+$battery in Summe NICHT $pv ergeben, kann ich mir nicht erklären.

Log mit Type "unsigned 16bit" (13021 ist eine positive, viel zu große Zahl)

2025-03-02 09:38:08.529	info	script.js.log_Werte: Testwerte: vom Dach = 4714, ins Haus: 2070, in Batterie: 63015, ins Netz: -80
2025-03-02 09:37:46.474	info	script.js.log_Werte: Testwerte: vom Dach = 4795, ins Haus: 218, in Batterie: 61538, ins Netz: 281
2025-03-02 09:37:24.444	info	script.js.log_Werte: Testwerte: vom Dach = 4822, ins Haus: 211, in Batterie: 61538, ins Netz: 305
2025-03-02 09:37:02.337	info	script.js.log_Werte: Testwerte: vom Dach = 4830, ins Haus: 218, in Batterie: 61537, ins Netz: 288
2025-03-02 09:36:40.291	info	script.js.log_Werte: Testwerte: vom Dach = 4839, ins Haus: 213, in Batterie: 61538, ins Netz: 305

Log mit Type "signed 16bit" (13021 ist eine Zahl, positiv oder negativ)

2025-03-02 09:38:41.605	info	script.js.Log_Werte: Testwerte: vom Dach = 4480, ins Haus: 214, in Batterie: -3998, ins Netz: 99
2025-03-02 09:38:19.554	info	script.js.Log_Werte: Testwerte: vom Dach = 4640, ins Haus: 214, in Batterie: -3999, ins Netz: 225
2025-03-02 09:37:57.488	info	script.js.Log_Werte: Testwerte: vom Dach = 4770, ins Haus: 216, in Batterie: -3998, ins Netz: 270
2025-03-02 09:37:35.405	info	script.js.Log_Werte: Testwerte: vom Dach = 4808, ins Haus: 217, in Batterie: -3998, ins Netz: 297
2025-03-02 09:37:13.347	info	script.js.Log_Werte: Testwerte: vom Dach = 4844, ins Haus: 216, in Batterie: -3999, ins Netz: 293
2025-03-02 09:36:51.301	info	script.js.Log_Werte: Testwerte: vom Dach = 4849, ins Haus: 2089, in Batterie: -2491, ins Netz: -24
2025-03-02 09:36:29.240	info	script.js.Log_Werte: Testwerte: vom Dach = 4853, ins Haus: 200, in Batterie: -3999, ins Netz: 309

Ich hab das Gefühl, ich komm hier zu keiner Lösung - aber vielleicht hat jemand ein funktionierendes Script zur Hand, dass mir die Werte für:

• PV in die Batterie
• PV ins Haus
• PV ins Netz
• Batterie ins Haus
• Netz ins Haus
  korrekt ausrechnet

@wolfi913 : das Script steckt im Blockly drin, dass auf der Seite beschrieben ist. Damit wird auf die Änderung des Running State (13000) reagiert.

[wolfi913]

@maddm sagte in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

Damit wird auf die Änderung des Running State (13000) reagiert.

Ok. Dann ist mir klar warum da kein Trigger zu finden war. Wobei sich der RunningState ja nicht häufig ändert, bei mir zuletzt vor über einer Stunde. Da würde ich eher auf einen anderen Wert (z.B. 13007 LoadPower) oder angelehnt an deinen Einstellungen für die Aktualisierungen im Modbus-Adapter per cron-Job triggern um die Datenpunkte unter 0_userdata.0 zu aktualisieren. Ich hab das bei mir z.B. alle 10 Sekunden eingestellt */10 * * * * *.
Hat jetzt aber nichts mit Deinen Werten in modbus.0 zu tun.

Weshalb Du aber so große Abweichungen in der Gesamtsumme hast... keine Ahnung. Die werden ja direkt über Modbus geliefert und sind ja unabhängig von irgendwelchen Scripten. Bei mir sind die Werte zwar auch nie vollständig deckungsgleich, das weicht auch immer so ca. um Werte bis etwa 30W ab, warum bei Dir aber da regelmäßig Werte > 300W fehlen??? Sorry. Da kann ich Dir leider nicht weiterhelfen. Hoffentlich hat ja jemand anderes hierzu Ideen oder Erkenntnisse.

[GombersIOB]

@wolfi913
Danke für die neueste Dokumentation. Dass man die immer nur als "Geheimtipp" kriegen kann, ärgert mich schon maßlos. Wieso stellt Sungrow sie nicht einfach auf Ihrer Dokumentendownloadseit allseits zur Verfügung?

Die Problembeschreibung auf GitHub finde ich verworren. Dieser JROEGNER, der behauptet, das Register 13021 sei jetzt vorzeichenbehaftet, begründet es nicht. Er schreibt nur aus dem Nichts dem Register irgendwelche Attribute zu (z.B. int16), sagt aber nicht woher er das weiß. Mir scheint das einfach nur die eigene Interpretation des Ganzen zu sein. Die Dokumentation, wie gesagt gibt das nicht her.
Wenn ich aber in die verlinkte Modbus-Präsentation von Sungrow schaue, finde ich über die Besonderheiten der Hybrid-Wechselrichter (auf Seite 117) den Satz:

WiNet-S liefert nicht alle Register. z.B. das Register für das Vorzeichen der Batterieladung.

Welches Register hier gemeint ist, ist leider nicht gesagt.

Für mich ist dieses Thema in dem Link sehr unbefriedigend abgehandelt worden. Wenn es einen Änderung bei Sungrow im Register 13021 gegeben hat, sollte es doch mittlerweile eine passende Dokumentation dazu geben. Ich glaube fast eher, dass einfach irgendwas falsch läuft. Für die Batterie sei es sowieso angeraten, sie ab und zu mal zu 100% voll zu laden, damit das BMS die tatsächliche Kapazität der Batterie wieder lernt. Das habe ich auf einem YouTube-Video von Tom Bötticher gelernt (umgesetzt habe ich es selber noch nicht).

Was mich wundert ist, dass ich, wie gesagt im ganzen letzten Jahr keine merkwürdigen Zahlen gesehen. Wenn das High-Order-Bit in einem 16-Bit-Register an ist, heißt das, die Zahl ist größer als 32768 (W) - das hätte ich gesehen.

[wolfi913]

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

Wieso stellt Sungrow sie nicht einfach auf Ihrer Dokumentendownloadseit allseits zur Verfügung?

Da haben wir absolut eine Meinung
Wäre gut wenn's da bessere (und vor allem offizielle) Infos geben würde.
So bleibt leider vieles bei Try&Error

Was mich wundert ist, dass ich, wie gesagt im ganzen letzten Jahr keine merkwürdigen Zahlen gesehen.

Vermutlich läuft Deine Anlage noch mit einem Firmwarestand < November 2024
Da geben die bisherigen Register ja passende Werte raus.

[GombersIOB]

@wolfi913

Die Firmwarestände aus dem GitHub stimmen tatsächlich nicht mit dem überein, was ich aus den ModBus-Registern auslese:

ARM-Softwareversion SAPPHIRE-H_01011.71.21
MDSP-Softwareversion SAPPHIRE-H_03011.71.18
SDSP Softwareversion SUBCTL-S_04011.01.01
Communication Module: M_WiNet-S_V01_V01_A
Battery: SBRBCU-S_22011.01.16

Laut Report tritt der Fehler mit

Energy Storage System
MDSP auf Version SAPPHIRE-H_03011.95.03
LCD auf Version SAPPHIRE-H_01011.95.03
Communication Module auf Version WINET-SV200.001.00.P026
Battery auf Version SBRBCU-S_22011.01.24

aus.

Also, ich bin tatsächlich softwaremäßig auf einem älteren Stand. Und außerdem weiß ich auch noch nicht mal, wer den Upgrade anstößt. Der letzte Upgrade von dem ich weiß, kam von Sungrow, Anfang 2023.