NEWS
Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden
-
@aleks-83 Sorry für die Späte Antwort. Das Holding Register beinhaltet die Register. welche man per Modbus beschreiben/ändern kann. Z.B: kann man hier die Min SOC, MAX SOC, Reserve SOC festlegen und auch ein Laden/Entladen der Batterie mit einer einstellbaren Leistung starten.
Die Eingangsregister dagegen beinhalten nur Register, welche man auslesen kann.
-
@carsten-sauermann
Ähm ja, das ist mir bewusst.
Deshalb verwende ich nur die eingangs Register.
Ich möchte erst mal sehen wie die Anlage so läuft. Ob ich überhaupt Register schreiben will weiß ich noch nicht. Vermisse ich bisher nicht.
Oder kann man damit das Laden der Wallbox starten und stoppen? Vielleicht sogar den Lade Modus einstellen? -
@aleks-83 moin. Also das Einzige was ich damit aktuell mache ist das Ich den reserveSOC im Winter automatisch höher stelle und den Akku nachlade falls dieser unter der neu eingestellten Reserve soc ist.
Für Anlagen wo die Erzeugung grösser der Wechselrichterleistung ist kann man hier ein Programm schreiben welches die Batterie dann entsprechend lädt.
Also Beispiel Anlage erzeugt 10000W und WR kann nur 8000W. Dann könnte man ein Programm schreiben welches die Batterie nur mit dem lädt was über 8000w erzeugt wird um den Ertrag zu optimieren.Den Lademodus der Wallbox müsste man dann ja im Modbus der Wallbox einstellen, wenn diese das unterstützt.
-
@carsten-sauermann said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:
Also Beispiel Anlage erzeugt 10000W und WR kann nur 8000W. Dann könnte man ein Programm schreiben welches die Batterie nur mit dem lädt was über 8000w erzeugt wird um den Ertrag zu optimieren.
Da möchte ich mal nachhaken. Ich verstehe das nicht. Der Wechselrichter steht zwischen PV-Anlage und allem Anderen (Batterie, Zähler, Wallbox und was da noch mehr sein könnte). Die Information über die 10kW Erzeugung erhält man doch vom WR, wie kann ich das anders wissen. Und Strom, der nicht verbraucht wird, geht bei mir in der Regel sowieso in die Batterie - und ansonsten ins Netz. Wie ein Programm den Strom am WR vorbei in die Batterie leiten könnte, leuchtet mir nicht auf Anhieb ein.
Ich habe einen 8kW Wechselrichter. Die größte Erzeugung war am 11 März mit 9,2kW. Die größte Einspeisung ins Netz war am 4. April mit 7,9 kW (mag sein dass sie am 11. März noch größer war, aber da habe ich diese Zahl noch nicht ermittelt). Das lief aber automatisch ab. Und die Batterieladung ist auch automatisch. Was ich da mit ioBroker noch verbessern könnte erkenne ich nicht. -
@gombersiob
Also ich rede von der Momentanerzeugung. Die könnte ja z.B. bei 10kw liegen. Der WR kann aber nur 8kw umwandeln. Die restlichen 2kw können aber am wechselrichter "vorbei" direkt in den Akku geladen werden. Der Strom fließt natürlich durch den WR wird aber nicht umgewandelt sonder wird durchgesetzt zur Batterie. Denn vom Dach kommt Gleichstrom (DC) und die Batterie kann nur Gleichstrom speichern.Ob mehr erzeugt wird als der WR könnte man einfach so ermitteln das man wenn der wr 8kw erzeugt und der Verbrauch kleiner 8kw ist das mann dann anfängt den Akku mit 200w zu laden und das erhöht man so lange bis der WR nur noch 7950watt erzeugt. Man baut sich also ein eigenes batteriemanagementsystem auf.
Evtl. Kann man es auch am MPP erkennen wenn Strom MAL Spannung deutlich grösser also 8kw sind. Das kann ich aber nicht testen da bei ich nur 7.5kw auf dem Dach habe und einen 8kw WR.
Das schwierigste dürfte sein das so zu programmieren das die Batterie auch immer voll wird und nicht bei schlechtem wetter wo die 8kw nicht erreicht werden nicht lädt..
-
Hallo,
ich habe heute erstmalig den Modbus-Adapter installiert und mit Hilfe der Infos hier konfiguriert (für Sungrow SH10RT). Der Modbus-Adapter holt auch die Daten und schreibt sie in den erzeugten Datenpunkte.Was mich wunder ist, dass der Status der Modbus-Instanz ständig zwischen disconnected und connected wechselt (die Teilstati "Verbunden mit Host" und "Lebenszeichen" bleiben durchgängig grün, jedoch "Verbunden mit Gerät oder Dienst" wechselt ständig). Dieses "Hin und Her" ist dann auch im Datenpunkt modbus.0.info.connection
In der Modbus.0 - Konfiguration habe ich diese Werte hinterlegt:
- Datenabfrageintervall: 5000
- Wartezeit bis zum erneuten Verbinden: 2000
- Wartezeit lesend: 5000
- Impulszeit: 1000
- Wartezeit: 50
Leider werde ich aus der Doku nicht so wirklich schlau.
=> Wechselt bei Euch auch der Verbindungsstatus ständig?
=> Wenn nein, was habt ihr für Einstellungen bzw. wie müsste ich meine Einstellungen anpassen?Danke schon mal
Johannes -
@johannesjahn
Als ich den Beitrag gestern las, habe ich bei mir geschaut und fand dasselbe Verhalten. Es war begleitet mit Meldungen2023-08-13 14:30:37.412 - info: modbus.0 (28748) Connected to slave 192.168.111.44 2023-08-13 14:30:42.414 - warn: modbus.0 (28748) Error: undefined 2023-08-13 14:30:42.415 - error: modbus.0 (28748) Request timed out. 2023-08-13 14:30:42.415 - error: modbus.0 (28748) Client in error state. 2023-08-13 14:30:42.416 - warn: modbus.0 (28748) Poll error count: 12 code: {"err":"timeout","timeout":5000} 2023-08-13 14:30:43.416 - info: modbus.0 (28748) Disconnected from slave 192.168.111.44
Diese Meldungen kamen gestern zwischen 11:19 und 15:10
Es wurde immer wieder der Adapter restarted und dann zählte der "Poll error count" wieder von 1 los.Beispiel für den Restart.
2023-08-13 11:41:41.324 - info: modbus.0 (21196) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2023-08-13 11:41:41.942 - info: host.raspberrypi instance system.adapter.modbus.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP) 2023-08-13 11:41:41.944 - info: host.raspberrypi Restart adapter system.adapter.modbus.0 because enabled 2023-08-13 11:41:43.004 - info: host.raspberrypi instance system.adapter.modbus.0 started with pid 21642 2023-08-13 11:41:45.379 - info: modbus.0 (21642) starting. Version 5.0.11 in /opt/iobroker/node_modules/iobroker.modbus, node: v16.20.2, js-controller: 4.0.24 2023-08-13 11:41:46.639 - info: modbus.0 (21642) Connected to slave 192.168.111.44
Und um 15:10 war dieses Verhalten, dem Log nach, zu Ende. Heute sehe ich keinerlei Probleme.
Einen Grund dafür kann ich aber nicht nennen. Das in der Meldung erwähnte "polling" muss meines Erachten vom (Master/Client) also ioBroker ausgehen. Der Slave/Server kennt ja den Client eigentlich nicht. Auf das Polling scheint dann aber der Adapter am WR aus irgendwelchen Gründen nicht zu reagieren.
Aber tatsächlich weiß ich nicht, ob es irgendwelche KeepAlive-Aktionen tatsächlich gibt. An den Parametern kann es kaum liegen, sonst wäre der Fehler ja dauerhaft da.- Datenabfrageintervall (Data polling interval): 1000
- Wartezeit bis zum erneuten Verbinden(Reconnect delay): 60000
- Wartezeit lesend (Read timeout): 5000
- Impulszeit (Pulse time): 1000
- Wartezeit (Wait time): 100
- Max Leseanforderungslänge (Float): 128
- Max Leseanforderungslänge (Booleans): 128
- Leseintervall: 0
- Schreibintervall: 0
Dabei erkläre ich mir die Parameter wie folgt (eine wirklich Doku habe ich nicht gefunden. Die Erklärung auf GitHUB hilft nicht wirklich weiter:
- Data polling interval: Frequenz der Abfragen
- Reconnect delay: Dauer, bis man den Request, nach Timeout, nochmal versucht.
- Read timeout: Zeit die man maximal auf Antwort wartet, bis man den Request als gescheitert definiert
- Pulse time: Wird bei "Coils" verwendet. Hier nicht von Interesse
- Wait time: Wartezeit zwischen den Abfragen zweier verschiedener DeviceIds. Für mich nicht von Interesse
Ich habe den "Reconnect delay" auf 1 Minute gesetzt. Wenn der WR mal Probleme macht, muss ich mir ja nicht den LOG mit Fehlermeldungen zumüllen - das war meine Überlegung.
-
Danke für Deine Informationen, die mich auf eine Idee gebracht haben: Ich frage nicht nur mit ioBroker per Modbus die Werte ab, sondern auch mit dem Solarmanager. Als ich letzteren abgeschaltet habe, war das Problem weg = dauerhafter Connect zwischen Modbus-Adapter und Wechselrichter.
Da der Solarmanager nur wenige Werte benötigt, die auch der WiNet-S - Dongle liefert, der Dongle auch per LAN ans Netzwerk angeschlossen ist, habe ich im Solarmanager die IP vom WiNet-S hinterlegt. Nun kommen sich die Abfragen von ioBroker und vom Solarmanager nicht mehr in die Quere.
Viele Grüße
Johannes -
@johannesjahn said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:
sondern auch mit dem Solarmanager.
Das ist die Software "Solarmanager"?
Ich (und sicher Du auch) habe noch den zweiten Adaper an meinem Wechselrichter. Darüber sammele ich eigene History-Daten (unabhängig von ioBroker). Vielleicht wäre das für Deinen Solarmanager auch interessant.
Gerade eben habe ich unter ioBroker aber wieder das Problem mit den Timeouts. Es kamen 13 Timeouts. Da ich den Retry aber erst nach 1 Minute mache, dauerte das Ganze eben auch 12 Minuten. In der Zeit gab es keine neuen Daten. Dann hat ioBroker den Adapter restarted - danach war alles wieder gut.
Aber gerade habe ich bei mir auch einen Fehler in der Definition entdeckt. Den habe ich jetzt beseitigt, mal sehen ob das dauerhaft hilft. -
@gombersiob Der Solarmanager ist ein Stück Hardware (Raspberry Pi) mit Software inkl. Cloud-Anbindung. Der Solarmanager hat ein Energiemanagement eingebaut (wenn-dann...). Letzteres war Motivation für den Kauf. Leider ist die grafische Darstellung bzw. das Handling nicht so ganz nach meinem Geschmack.
Daher baue ich mir gerade eine eigene Visualisierung mit ioBroker (modbus-, sql- und jarvis-Adapter sowie Grafana manuell installiert; die SQL-DB läuft schon auf dem NAS, daher musste ich keine weitere DB installieren).
Die LAN-Anschlüsse von den Wechselrichtern selbst verwende ich nun für die Modbus-Instanz vom ioBroker und die LAN-Anschlüsse von den WiNet-S - Dongles nutze ich für den Solarmanager.
Seitdem ich die WiNet-S - Dongles per LAN angebunden (und WLAN deaktiviert) habe, habe ich keine Verbindungsprobleme mehr. Daher kann ich nur raten, LAN-Kabel statt WLAN zu verwenden (wenn das irgendwie möglich ist).
Viele Grüße
Johannes -
@manny4566 Es ist zum verrückt werden. Ich bekomme das Register 13099 bzw. 19938 über die holding register einfach nicht ausgelesen geschweigeden gesetzt. Alles was mit der Batterie sonst zu tun hat und in den input Registern abzufragen ist funktioniert. Noch irgendwelche Tipps? Wie bist du auf die Adresse 19938 gekommen?
-
Hallo zusammen,
als "alter Hase" habe ich mich seit einiger Zeit mit Smarthome und diversen Themen und Software dazu beschäftigt. Ich habe diverse Shellys verbaut, habe noch alte MAX!-Thermostate im Einsatz. Mein Netzwerk umfasst relativ viele Geräte (> 50). Ich arbeite in der IT als Admin und habe eine elektrotechnische Ausbildung. Soweit zu mir.
Nun zum Thema: Seit ein paar Tagen haben wir unsere PV-Anlage in Betrieb (noch ohne Abnahme, der Meister hat offenbar keine Zeit). Auf dem Dach sind insg. 44 Module á 410W verbaut und in 4 Strängen an 2 WR (SH10RT und SG5.0RT) angeschlossen. Der SH10RT hat noch eine SBR9.6 als Puffer dran, da wir derzeit noch nicht einspeisen (dürfen). Soweit zur Anlage.
Und natürlich soll das ganze zwecks besserem Monitoring und Steuerung in den IO-Broker (den ich auf einem Linux-PC als Server betreibe).
Nun fängt das Problem schon an: Ich habe inzwischen die Datenpunkte mit der Liste in die DB geladen, das hat geklappt.
Aber wenn ich den Modbus-Adapter mit den Daten zum WR 2 (SG5RT) füttere (wie hier angegeben), bekomme ich, wie oben, immer wieder 2 FM: Request timed out und Client in error state. Für diese Zeitspanne sind alle Steps des Adapters auch mal kurz komplett grün, ansonsten nur die oberen beiden.Übersehe ich was?
Vielen Dank im Voraus!
Viele Grüße. -
Ich habe es mit viel ausprobieren hinbekommen. Hifreich war das Tool "VaGaModbus Analyzer" (unter Windows), damit konnte ich einige Register auslesen.
Dann mit etwas ausprobieren und Gelduld klappte das Auslesen dann doch: Wichtig war der Haken bei "Multiple Device IDs" zu setzen. Jetzt kann ich die Register des WR1 (SH10RT) auslesen.
Viele Grüße, auch wenn keine Hilfe kam Oft hilft es auch, darüber zu schreiben und wirklich jeden Beitrag zu lesen -
Guten Abend,
also ich bin echt neidisch, was ihr alle für tolle Visualisierungen gebaut habt.
Würd ich auch gerne machen, daher von Openhab zu iobroker gewechselt.
Soweit läuft alles wunderbar und auch echt nicht kompliziert.
Aber die beiden Statusanzeigen (System_State und Running_State) sind bei mir immer 0.
Daher denke ich funktioniert auch das Script, das sagen soll wohin der Strom fließt (einfach ausgedrückt), es zeigt mir keine Fehler an aber auch da sind alle Werte 0 bzw. False.
Jemand eine Idee? Ich hab die Register von hier und auch in von anderen Foren verwendet und auch die PDF von Sungrow heruntergeladen in der alles so steht wie in meiner TSV Datei...
Bin dankbar für jeden Tipp.
WR1 = SH10RT
WR2 = SG5.0RT
Akku = BYDPDF:
Communication.Protocol.of.Residential.Hybrid.InverterV1.0.22_20201117.pdfRegister:
Register.txtWerte um 20:01 also keine Sonne mehr
Danke im voraus.
Gruß Sascha
-
@sascha127 said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:
Aber die beiden Statusanzeigen (System_State und Running_State) sind bei mir immer 0.
Die beiden Register sind nur, wenn sie über den Adapter WiNet-S ausgelesen werden, auf "0" gesetzt. Über den zweiten, nur über LAN-erreichbaren Adapter haben sie durchaus sinnvolle Werte.Aber es gibt in diesem sehr langen Thread im Februar auch eine Diskussion darüber wie man das Batterie laden/entladen auch ohne die Register entscheiden kann. Der User MRaioBroker hat hier und im Thread https://forum.iobroker.net/topic/63226/sungrow-wr-sgh10rt-modbus-ioskripte dazu eine Blockly eingestellt.
-
@gombersiob
Super Danke. Da hab ich wohl vor lauter Bäumen den Wald nicht gesehen
Dann teste ich das mal. -
@gombersiob
Ich bin zu doof um diese XML Datei zu importieren.
Andere Blockly Dateien konnte ich ohne Probleme einfügen über copy/paste.
Ich steh auf dem Schlauch, sorry für die sau dumme Frage -
@sascha127
Das sind doch nur 3 Zeilen. Vermutlich ist es sowieso einfacher das direkt zu programmieren. Dann stimmen die Objektnamen auch sicher. -
@sascha127 said in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:
Ich bin zu doof um diese XML Datei zu importieren.
Ich habs jetzt auch mal probiert. Das Importieren klappt wirklich nicht. Scheitert mit "Error: textToDom was unable to parse:". Ich bin aber sicher, das hat damals geklappt. Wenn man sich die XML anschaut, dann nutzt das Word-Tags. Ist reichlich merkwürdig.
Ich habe das Script (bis auf die letzte Zeile zum Setzen des eigenen Objects "Berechnung_Batterieentladung_negativ" einfach nochmal geschrieben und füge es an:
Die zugehöriger XML ist hier zum Download.
-
@gombersiob
Super, vielen Dank.
Ich hab es jetzt auch geschafft nachzubauen.
So langsam werde ich warm mit den Blockly Scripten
Hab auch mal den Energieflussadapter installiert und mit Daten gefüttert.
Sieh schon gut aus soweit, nur stimmt mein Verbrauch nicht, den der Adapter berechnen kann.
Ich habe auch ein IR Lesekopf auf meinem EHZ, aber der Zeigt ja nicht den aktuellen Verbrauch an. Sondern nur quasi den Rest was eingespeist bzw. vom Netz gezogen wird...
Wie zieht bzw. berechnet die iSolarCloud App den aktuellen Stromverbrauch?