UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Savek]

@gombersiob der SH15T hat keinen separaten LAN-Port. Anschluss an den Logger-Port (A1,B1) des COM2-Anschlusses, siehe Handbuch auf Seite 14.

Dort gibt es halt Modbus/RS485 - und dort kann dann ein Modbus/TCP-Adapter dran wie z.B. der WaveShare um dann über den IoBroker Modbus-Adapter die Daten auslesen zu können.

Hier gibt es noch einmal einen aktuellen Export der Register des SH15T in 2024, direkt importierbar in den Modbus-Adapter v6.3.2: IoBroker_Modbus_SH15T_Eingangsregister_Export.txt

Quelle dazu war die aktuelle Beschreibung der Register im Sungrow-Dokument in Version 1.1.4.

Edit: In dem Export könnten noch kleinere Fehler drin sein; Aktualisiere das wenn ich welche finde.

[GombersIOB]

@savek
Ok, ich verstehe. Aber der WiNet-S hat doch einen LAN-Port. Ich frage meine SH8RT mit zwei unterschiedlichen Clients über die beiden LAN-Ports ab.

[Savek]

@gombersiob ja, hat der WiNet-S - allerdings bekomme ich per Modbus alle Register problemlos und im Sekundentakt. Mit dem WiNet-S ist das anscheinend eher Glücksache.

[GombersIOB]

@savek
Ok, verstehe. Ich habe keine Probleme, auf keinem der beiden Ports. Aber es hat etwas gedauert, bis es funktionierte. Und eine echte Erklärung für die Probleme gab es nie.

[Savek]

@gombersiob anscheinend sind die Probleme mit dem WiNET-S besser geworden; MPPT3 lässt sich aber wohl noch immer nur über Umwege auslesen.
Darüber hinaus kann man mit dem Modbus-Adapter aber auch noch Daten des angeschlossenen Akkus (interne Spannungen etc) über SOC hinaus auslesen, siehe https://github.com/mkaiser/Sungrow-SHx-Inverter-Modbus-Home-Assistant/blob/main/modbus_sungrow.yaml und https://github.com/c0ldtech/sungrow/tree/main

[berlinerbolle]

@savek

Nur eine kurze Anmerkung von mir als Eigentümer eines der zitierten github Repositories: Die Datenpunkte die ich dort gesammelt habe, sind ausnahmslos auch ohne extra Modbus Hardware Adapter über Modbus TCP am SH10RT über den LAN Port des Wechselrichters auslesbar - auch die Werte des Sungrow Stromzählers am Netzanschlusspunkt.

Wenn man allerdings Wert darauf legt, die Werte zuverlässig im Sekundentakt zu bekommen, ist ein Hardwareadapter sicher die bessere Wahl. Ich frage über Modbus TCP ohne Probleme alle drei Sekunden ab.

Habe aber auch schon mit dem Gedanken eines extra Modbus (Hardware) Adapters gespielt in der Hoffnung, die Werte schneller (nicht unbedingt öfter) zu bekommen, da über Modbus TCP schon ein ziemlicher Zeitversatz in einigen Werten drin ist. Das macht sich zum Beispiel bei der Ansteuerung einer Wallbox durchaus bemerkbar und kann zu unschönen Effekten führen.

[Savek]

@berlinerbolle der SH10RT hat ja auch einen extra LAN-Port für Modbus; Also WiNET-S + Extra LAN; Der SH15/20T hat diesen extra LAN-Port eben gerade nicht. Die einzige RJ45/Ethernet-Möglichkeit ist über den WiNET-S. Da ist ein 30€ Adapter am COM2 wie oben beschrieben jetzt auch kein Beinbruch. Habe aber selber nicht versucht über WiNET-S dran zu gehen sondern einfach direkt den Adapter verbaut.

[berlinerbolle]

@savek

Ja, ich weiß. Ich wollte nur klarstellen, dass die genannten Register durchaus alle per Software ohne einen Hardwareadapter auszulesen sind - aus den letzten Beiträgen hätte jemand Neues den Eindruck gewinnen können, dass dies nur mit zusätzlicher Hardware geht. Also alles gut.

Auch wenn es ohne extra Adapter geht, hat der Adapter durchaus trotzdem Vorteile. Potentiell kürzeres Abfrageintervall und eventuell schnellere Datenlieferung (das muss ich bei Gelegenheit aber selbst noch austesten).

[GombersIOB]

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

Das macht sich zum Beispiel bei der Ansteuerung einer Wallbox durchaus bemerkbar und kann zu unschönen Effekten führen.

Delays im Sekundenbereich? Das verstehe ich nicht wirklich. Die Ladezeiten sind doch auch im Stundenbereich. Welche Probleme kann denn ein verzögerter Ladestart oder Ladeende machen?

[berlinerbolle]

@gombersiob

Zum Beispiel ist das dann ein Problem, wenn man die Wallbox mit den Daten der Zähler füttert, damit die weiß wieviel PV Überschuss vorhanden ist. Die Berechnung des Überschusses macht sie aber (anhand der Zählerdaten des Netzanschlusses, des PV Speichers und ihres eigenen Verbauchs) selbst. Nun ist der Verbrauch der Wallbox in Echtzeit vorhanden, die Zählerdaten des Netzanschlusses und PV Speichers hinken aber ein paar Sekunden hinterher (da sie vom Sungrow WR über Modbus TCP kommen). Das führt zu einem falschen Wert des errechneten PV Überschusses wenn die Wallbox beginnt zu laden (Da Netzanschluss und PV Speicher Werte die zusätzliche Last noch nicht widerspiegeln) und damit zur Auswahl der falschen Ladeleistung und ständigem hin- und herpendeln zwischen zu hoher und zu niedriger Leistung.

Dadurch wiederum wird unnötig der PV Speicher zum Laden des Fahrzeugs genutzt, oder Strom aus dem Netz bezogen, bzw. unnötig eingespeist. Oder sogar die falsche Ladebedingung ausgewählt. Ich habe eine cFos Wallbox, die kann da allerhand - wenn aber die Zählerdaten nicht stimmen bzw. mit zu großer Verzögerung vorliegen, greift die Ladelogik nicht richtig und Überschussladen funktioniert nicht so gut wie es sollte/könnte.

[aleks-83]

Moin,
kann sich jemand erklären, warum mein Datenpunkt aus dem WR heute Nacht um 2:00 auf 0 gesprungen ist?
Gab es da einen Überlauf?

Der Datenpunkt ist als "Number" deklariert.
Da sollten doch deutlich höhere Werte möglich sein!?

[Codierknecht]

@aleks-83 sagte in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

Der Datenpunkt ist als "Number" deklariert.
Da sollten doch deutlich höhere Werte möglich sein!?

Dem Datenpunkt sollte das Schnuppe sein.
Wie ist denn der Wert im Modbus-Register definiert?
Sieht verdächtig nach UINT 16 aus. Da wäre dann ein Überlauf normal.

[aleks-83]

@codierknecht
Danke für den Hinweis.
Es war als 16bit konfiguriert. Das habe ich so hier aus dem Forum übernommen.

Habs auf 32 bit Endian Word Swap umgestellt. Funktioniert! :smile:

[Codierknecht]

@aleks-83 sagte in Sungrow WR SGH10RT erfolgreich mit MODBUS eingebunden:

Das habe ich so hier aus dem Forum übernommen.

Bei der Einstellung der Register besser die offizielle Dokumentation des Herstellers beachten.
Einträge im Forum können falsch oder veraltet sein.

[Schneider]

Hi, ich versuche mit obiger Anleitung einen SH20T anzubinden.
Bin MODBUS Neuling - bitte nicht steinigen ;-)

Ich bekomme die Register nicht reinkopiert. Was mach ich da falsch?

[gmt94]

@schneider

Die ganzen Einsen sind falsch. Also zwischen Adress und Name, die müssen raus.

[berlinerbolle]

@schneider
@gmt94

Falsch sind die Einsen nicht per se - ich würde empfehlen, die drin zu lassen. Dafür muss aber im Modbus Adapter in den Einstellungen "Multiple Device IDs" angehakt sein, sonst klappt es nicht.

Vorteil dabei: man kann die einzelnen Batteriewerte per Modbus auslesen, die Batterie hat eine eigene Modbus Adresse.

Siehe hier.

[GombersIOB]

@berlinerbolle
Zumindest ist offensichtlich, dass die Tabelle derzeit nicht zu den Überschriften passt. Ob es eine Einstellung gibt, die der Tabelle eine weitere Spalte hinzufügt, weiß ich nicht. Aber derzeit passen die Einsen jedenfalls nicht rein. Die „Unit“-Werte der Einfügungen werden offensichtlich, wie auch die Fehlermeldung sagt in der Spalte „type“ eingefügt - und entsprechen deshalb nicht den hinterlegten, erlaubten, Werten.
Die Einsen sind hier und jetzt jedenfalls zu viel.

[berlinerbolle]

@gombersiob

Vollkommen richtig, so wie es im Screenshot ist, kann es nicht funktionieren - egal ob die Option "Multiple Device IDs" angehakt ist oder nicht. Mit der angehakten Option kommt eine zusätzliche Spalte "deviceId" dazu, die natürlich in der ersten Zeile entsprechend dabei sein muss.

Deshalb mein Verweis auf das github Repo, da passt es.

[Schneider]

Cool, hat geklappt. Danke für die Hilfe.

Jetzt habe ich die Objekte drin - allerdings stehen alle auf "0":