Sungrow2mqtt – Sungrow & SMA Wechselrichter einfach per Modbus/MQTT einbinden

[Cyphylax]

Hallo zusammen ,

da das Thema Sungrow-Wechselrichter lokal und ohne iSolarCloud-Verzögerung in Home Assistant einzubinden immer wieder aufkommt, wollte ich euch mein Projekt sungrow2mqtt vorstellen bzw. ein Update dazu geben.

Ich nutze das Tool selbst seit geraumer Zeit. Es läuft bei mir und vielen anderen absolut stabil, wartungsfrei und zuverlässig im Alltag. Da der Core inzwischen extrem ausgereift ist, wollte ich es hier in der Community noch einmal teilen!

---

Danksagung & Einordnung (mkaiser)

Wichtiger Hinweis vorab:
sungrow2mqtt nutzt und basiert maßgeblich auf den großartigen Modbus-Register-Mappings und Vorarbeiten von mkaiser (mkaiser/sungrow-ha).
Mein Projekt soll in keinster Weise eine Konkurrenz oder ein Ersatz für sein Repository sein! Es dient lediglich als Ergänzung und Unterstützung, um seine durchdachte Konfiguration noch einfacher, schlanker und ohne manuelles YAML-Gefummel über eine eigenständige Modbus-zu-MQTT-Bridge in Home Assistant einzubinden. Ein riesiges Dankeschön geht an mkaiser für die Pionierarbeit!

---

Was macht sungrow2mqtt?

Anstatt sich durch kilometerlange YAML-Konfigurationen für Modbus TCP zu quälen, fungiert sungrow2mqtt als extrem leichte Bridge zwischen eurem Wechselrichter und Home Assistant.

• Zero-YAML (Auto-Discovery): Das Tool liest die Register aus und schickt sie per MQTT an Home Assistant. Alle Sensoren, Switches und Steuerungs-Entitäten tauchen vollautomatisch in eurer MQTT-Integration auf.
• Modbus Write-Support: Neben dem Auslesen könnt ihr Einstellungen, Ladelimits oder Betriebsmodi direkt aus HA heraus steuern.
• Block-basiertes Polling: Die Werte werden in Blöcken abgefragt – das minimiert Netzwerk-Traffic und verhindert Modbus-Timeouts komplett.
• Dynamische Limits: Automatische Erkennung der max. Lade-/Entladeleistung basierend auf den Wechselrichter-Metadaten.
• WiNET-S / WiNET-S2: Neben dem normalen LAN-Port werden auch die WiNET-Module unterstützt (Read-Only).
• Docker / Multi-Arch: Fertiger Docker-Container für amd64 (Proxmox, VMs) und arm64 (Raspberry Pi).

---

Schnellstart

1. Modbus TCP am Wechselrichter freischalten (über iSolarCloud oder lokales Admin-Portal).
2. Container starten (per Docker CLI, Portainer, Docker Compose oder Proxmox LXC):
   Einfach eure MQTT-Broker-Daten und die IP des Wechselrichters als Umgebungsvariablen mitgeben.
3. Fertig: In Home Assistant unter Einstellungen → Geräte & Dienste → MQTT taucht euer Wechselrichter mit allen Entitäten und passenden Einheiten (kWh, W, °C etc.) auf.

Eine genaue Anleitung und Konfigurationsbeispiele findet ihr im Repository:
GitHub: sungrow2mqtt Repository

---

Unterstützte Geräte

Erfolgreich getestet auf diversen Sungrow Hybrid- und String-Wechselrichtern (z. B. SH5RT, SH8RT, SH10RT, SHxxRS, S20T) sowie den passenden SBR-Batteriespeichern.

---

Kleine Bitte & Feedback

Da das Tool im Hintergrund einfach unauffällig seinen Dienst tut, bekommt man als Entwickler selten mit, wo es überall läuft.

Wenn euch sungrow2mqtt die Einrichtung erleichtert hat, würde ich mich riesig über einen Star auf GitHub freuen! Das hilft ungemein, damit auch andere Sungrow-Besitzer das Projekt leichter finden.

Falls ihr Fragen zur Einrichtung habt, Feedback dagelassen werden möchte oder euch noch bestimmte Modbus-Register fehlen: Schreibt es gerne einfach hier in den Thread!

Viel Spaß beim Ausprobieren!

[gobbli]

Hallo @Cyphylax ,

vielen Dank für deine wirklich hilfreiche APP. Ich habe vorher das Template von mkaiser genutzt. Es hat soweit seinen Dienst verrichtet, jedoch ist es hin und wieder dazu gekommen, dass sich der Modubus über LAN aufgehangen hat. Ende Juni(?) hab ich dann deine APP gefunden und installiert. Seit dem habe ich keine Probleme mehr und es läuft alles wunderbar im Hintergrund. Lediglich eine Entität hatte ich weniger als beim mkaiser Template beim SH8RT-20. Ich wüsste jedoch jetzt nichtmehr welche es gewesen ist, kann also nicht so schlimm gewesen sein

Jetzt sind es auf Github

[Pit]

Wie funktioniert die Umstellung, wenn man vorher die yaml- Datei von mkaiser genutzt hat (in meinem Fall eine für einen SH10RT und eine für einen SG10RT)?

Ich habe viele Dashboards, Automationen usw., müßte ich diese dann alle anpassen?

Danke und LG

[gobbli]

Hallo @Pit ,

es bekommen ja alles Entitäten neue Namen. Aufgrund dessen werden die Dashboards, Automationen, etc. angepasst werden müssen. Auch deine alten Statistiken werden dann nicht mehr aktualisiert. Du müsstest dann alles händisch wieder neu zuordnen. Bei mir ist es nicht so schlimm gewesen, da ich die PV erst seit Juni habe und konnte somit auf meine Statistik verzichten. Ob Du die vorhandene Statistik den neuen Namen der Entitäten zuordnen kannst, kann ich gerade nicht sagen. Viel Erfolg!

[Pit]

Danke, ich glaube, das tu ich mir nicht an, ich habe die PV schon mehrere Jahre, und es funktioniert ja alles.

[Cyphylax]

Hallo @Pit,
Aktuell unterstützt das Tool leider erst einen Wechselrichter. Wenn sich hierfür aber noch mehr Interessierte finden, baue ich das Feature sehr gerne ein! Da ich selbst nur einen Wechselrichter im Einsatz habe, wäre ich dafür allerdings auf Tester aus der Community angewiesen.

Wichtiger Hinweis zur Einrichtung: Bitte stelle sicher, dass während der Nutzung keine anderen Systeme (wie z. B. andere Modbus-Skripte) zeitgleich auf den Wechselrichter zugreifen. Sungrow-Wechselrichter (besonders über den WiNet-Dongle) reagieren sehr empfindlich auf parallele oder zu schnelle Anfragen, was schnell zu Verbindungsabbrüchen führt.

Um das zu testen, empfehle ich dir, einen Modbus-Proxy (z. B. ha-modbusproxy) dazwischenzuschalten.

Für deine Automationen und Dashboards kannst du die Entitäten-IDs, welche von der App erstellt werden, einfach an deine bereits verwendeten Entitäten anpassen.

Edit:

Die Statistiken, glaub ich nicht das übernommen werden. Da es ja dann neue Geräte Entitäten sind.

[gobbli]

Hallo @Cyphylax ,

ich würde den Abfrageintervall gerne unter 10 Sekunden einstellen. Leider wird das durch deine APP unterbunden. Ich würde mir wünschen, gerne auch 1 Sekunde oder mindestens 5 Sekunden zu nutzen, zumindest für bestimmte Sensoren. Mit dem Wechselrichter sollte das über LAN-TCP möglich sein.

[Cyphylax]

Hey @gobbli ,
die Entitäten sind getrennt getimed wie in mkaisers yml. Aber ja den Timeout kann ich einbauen dass dieser über einen int wert konfigurierbar ist. Würdest du hierzu ein feature request in github stellen (als issue). Dann baue ich es im nächsten Release ein.
Danke

[gobbli]

Hallo Cyphylax,

welchen Grund gibt es eigentlich dafür, dass der Wert der Entität

number.keller_sungrow_sh8_0rt_20_battery_max_charge_power

nicht kleiner als 10 W gesetzt werden kann? Das ergibt meiner Meinung nach wenig Sinn, da der Sungrow mit 10 W ohnehin nicht sinnvoll laden kann. Könnte man den Minimalwert nicht auf 0 W setzen?

Ich erstelle mir gerade ein Skript und möchte in bestimmten Zeitphasen das Laden komplett unterbinden. Da sehen 10 W als Sollwert etwas merkwürdig aus.

Gibt es beim Sungrow SH8 eigentlich einen Schalter bzw. ein Register, mit dem man den Ladevorgang direkt aussetzen kann – also so etwas wie Ein/Aus?

Ach was mir noch aufgefallen ist, könntest Du die Entitäten für die maximale Einspeisung, etc. welche auch bei mkaiser vorhanden sind auch hier integrieren. Wichtig ist, wenn man z.B. mittags automatisiert bei einer hohen Netzlast die Einspeisung drosseln möchte.

Auch wären z.B. wie bei mkaiser Batterie bypass etc. nützlich.

Vielen Dank!

[Cyphylax]

Hi @gobbli
ich bin voll dabei, und habe gesehen dass mir beim Timing ein Fehler unterlaufen ist, ich vermute das das auch nur ein Bug ist wo ich den min Wert nicht richtig gesetzt habe. Gerne schau ich mir die anderen Auffälligkeiten mal an.
Danke dir fürs melden!

[Cyphylax]

Kurzes Update zum 10-W-Minimum: Ich hab’s mir angeschaut — das ist kein Tippfehler von mir, sondern kommt unverändert aus der mkaiser Sungrow-SHx-Registerliste, die ich für die Register-Definitionen nutze. sungrow2mqtt reicht den Wert nur 1:1 an Home Assistant weiter, ich setze ihn nicht selbst.

Ich halte mich bei den Registerdefinitionen bewusst so nah wie möglich am mkaiser-Original — dadurch bleiben sie automatisch aktuell und ich muss nicht bei jedem Upstream-Update eigene Anpassungen nachziehen (dafür fehlt mir als Ein-Mann-Projekt schlicht die Zeit). Änderungen wie das Absenken auf 0 W würde ich deshalb ungern lokal in sungrow2mqtt patchen, weil es beim nächsten automatischen Update sowieso wieder überschrieben würde. Der sauberere Weg wäre ein Issue oder PR direkt bei mkaiser — dann profitieren auch alle anderen Nutzer davon, die dieselbe Registerliste nutzen. Ich verlinke das gerne hier, falls ich das dort anspreche, oder du machst das selbst.

Zum Ein/Aus-Schalter für den Ladevorgang: Aktuell gibt’s dafür kein eigenes Register in der Konfiguration. Das wäre ebenfalls eher ein Thema für die Registerliste bei mkaiser, falls der SH8 ein passendes Register hergibt.

Feed-in-Limit und Battery-Bypass stehen aktuell nicht auf meiner Roadmap, und aus den gleichen Zeitgründen kann ich da leider nichts versprechen. Falls sich das über zusätzliche Register bei mkaiser abbilden lässt, würde das mit meinem Auto-Update automatisch bei mir landen.

[Cyphylax]

Sungrow2MQTT v1.2.0 ist da

Hallo zusammen,

Version 1.2.0 ist released und über die üblichen Kanäle verfügbar (Add-on-Store-Update bzw. git pull je nach Installation). Hier die wichtigsten Punkte im Überblick:

Neu

• Scan Level (scan.level): BASIC, STANDARD oder FULL — reduziert bei Bedarf die Anzahl abgefragter Modbus-Register, z. B. wenn die Verbindung (WiNET-S) etwas langsamer ist. Schalter und steuerbare Entities sind immer verfügbar, unabhängig von der Stufe.
• Scan Interval (scan.interval.realtime/fast/medium/slowest): eigene Abfrageintervalle je Register-Kategorie sind jetzt konfigurierbar (Issue #6).
• Retries (scan.retries): Anzahl der Wiederholungsversuche bei fehlgeschlagenen Modbus-Reads einstellbar.

Wichtige Fixes

• Der automatische Registerdatei-Update (von der mkaiser-Liste) ist jetzt robust: Timeout, Validierung vor dem Überschreiben, kein Absturz mehr bei Netzwerkproblemen.
• Ein Bug behoben, durch den eure konfigurierten scan.interval-Werte komplett ignoriert wurden.
• Sauberes Verhalten beim Stoppen des Add-ons: Home Assistant zeigt die Entities jetzt korrekt als “offline” an, statt fälschlich “online” hängen zu bleiben.
• Diverse kleinere Fixes (siehe Changelog unten).

Sicherheit

• Die Jinja2-Templates laufen jetzt in einer Sandbox, da die Registerdatei automatisch von extern aktualisiert wird — schützt vor manipulierten Templates.
• Unnötige Berechtigungen entfernt.

Sonstiges

• Deutlich besseres Logging (Heartbeat alle 5 Minuten zeigt, dass alles läuft, ohne das Log zu fluten; mehr Details im DEBUG-Modus).
• Unter der Haube: Testsuite + automatische Prüfungen bei jeder Änderung, damit sowas wie der scan.interval-Bug künftig schneller auffällt.

Vollständiges Changelog wie immer hier: CHANGELOG.md

Feedback, Bugs oder Wünsche gerne wie gewohnt hier im Thread oder als Issue auf GitHub.

[gobbli]

Update hat erstmal funktioniert mit ein paar kleinen Anlaufschwierigkeiten

Ich hatte die “default” Parameter nicht berücksichtigt und daher wollte das AddOn nicht starten. Nachdem ich alle Parameter angepasst habe, läuft es jetzt.