Hallo Freunde der Sonnenstrahlen-Ernte. Wie ihr wisst stehen bei mir drei SunEnergyXT 500 Pro Geräte. Über meine Anfänge mit den SunenergyXT 500 Pro hatte ich hier berichtet.
Die drei unabhängigen Speicher lassen sich über die SunEnergyXT-App über die smarte Multi-Bereich-Strategie als eine Einheit steuern und bieten so bis zu 7.200 Watt Ein- und Ausgangsleistung. Da ich ein großer Fan von Home Assistant für die Steuerung aller meiner smarten Komponenten unterschiedlicher Hersteller bin, war der nächste logische Schritt die Integration der SunEnergyXT 500 Pro Geräte in Home Assistant. Für die lokale Anbindung gibt es eine Integration sowie ein Blueprint, welches zum Zeitpunkt der Artikelerstellung allerdings nur für die Steuerung von einem einzelnen Gerät ausgelegt ist. Und genau da setzt meine Blueprint-Erweiterung an, die alle drei Geräte über einen gemeinsamen Regelkreis koordiniert.
Erst einmal die Grundlagen – wie SunEnergyXT und Home Assistant überhaupt miteinander reden –, dann die Installation der Integration und des Standard-Blueprints von SunEnergyXT, und last but not least, wie es für drei Geräte erweitert wurde. Nicht auslassen will ich auch all die Stolpersteine, die dabei aufgetreten sind.
Key Facts
- Geräte: 3× SunEnergyXT 500 Pro, koordiniert als ein System
- Zentraler Zähler: EcoTracker, BitShake, Shelly Pro 3EM, Shelly EM oder ein anderer in Home Assistant integrierter Zähler – einzige Wahrheitsquelle für Netzbezug/-einspeisung
- Ziel-Netzleistung: 35 W, Halteband ±40 W
- Reaktionsstufen: 5 – klein, mittel, mittelhoch, groß, Notausgleich – statt einer fixen Regelrate
- Trigger: prüft jede Sekunde, geschrieben wird aber nur alle 2–7 Sekunden, je nach Stufe
- Sollwerte pro Zyklus: Netzleistungs-Sollwert (GS) + maximale Wechselrichterleistung (IS)
- Verteilung auf die Geräte: aktuell gespiegelt – alle drei bekommen denselben Wert (eine bewusste Vereinfachung, keine endgültige Entscheidung)
- Vorab getestet mit Claude KI: in einer eigenen Python-Simulationsumgebung, die die YAML/Jinja2-Logik isoliert durchspielt, ganz ohne echte Hardware
Inhaltsverzeichnis
- Grundlagen: Wie SunEnergyXT mit Home Assistant spricht
- Die SunEnergyXT-Integration installieren
- Das Standard-Blueprint einrichten
- Warum das für drei Geräte nicht reicht
- Die Erweiterung: ein Regelkreis für drei Geräte
- Die Stolpersteine
- Fazit
1. Grundlagen: Wie SunEnergyXT mit Home Assistant spricht
Bevor ich zu den Blueprints komme, kurz die Basis, für alle, die noch nicht mit SunEnergyXT und Home Assistant gearbeitet haben. Die Geräte hängen per WLAN im heimischen Netzwerk und lassen sich auf zwei Wegen ansteuern: über die Cloud (App, von überall) oder lokal (Home Assistant, ohne Cloud-Umweg). Für alles, was in diesem Artikel folgt, nutze ich den lokalen Weg.
Kurz zusammengefasst: In der App wird die lokale Steuerung für ein Gerät aktiviert, das Gerät meldet sich daraufhin mit IP-Adresse und Port im lokalen Netz, und Home Assistant nimmt es darüber als Integration auf. Am Ende stehen in Home Assistant nicht nur Sensoren (Leistung, Ladezustand, Temperatur) zur Verfügung, sondern auch beschreibbare Sollwert-Felder – genau die number.-Entitäten, auf denen das gesamte Blueprint später aufbaut.
2. Die SunEnergyXT-Integration installieren
Zwei Teile gehören hier zusammen: die lokale Kommunikation in der App freischalten und die eigentliche Integration über HACS installieren. SunEnergyXT beschreibt beides auf ihrer Website.
Voraussetzungen:
- Home Assistant ist installiert.
- HACS (Home Assistant Community Store) ist installiert.
- Bekannt, welche Installationsart die eigene Home-Assistant-Instanz hat – unter Einstellungen → Info nachsehen: „Home Assistant OS“ → OS/Supervised wählen, „Home Assistant Container“ → Container wählen, sonst Core.
- Gerät und Home Assistant hängen im selben lokalen Netzwerk.
Schritt 1 – lokale Kommunikation in der App aktivieren:
- In der SunEnergyXT-App zum Tab „Konto“ wechseln, dort „Smart-Home-Hub“ wählen.
- „Home Assistant“ antippen, Gerät auswählen, Schalter aktivieren.
- Das Gerät aktualisiert seine lokalen Netzwerkdaten – IP-Adresse und Port (Standard: 80) werden angezeigt. Das Ganze in meinem Fall mal drei. Die IP-Adressen am besten kurz aufschreiben.
So sieht dieser Ablauf in der App aus:
Schritt 2 – die Integration über HACS installieren:
- In HACS über das ⋮-Menü „Custom repositories“ öffnen.
- Repository-URL
https://github.com/SunEnergyXT/SunEnergyXT-500-Series/releaseseintragen, als Typ „Integration“ wählen, hinzufügen. - In HACS nach „SunEnergyXT 500 Series“ suchen, unter „Neu“ auswählen und herunterladen (Download-Dialog zweimal bestätigen).
- Die Integration erscheint danach unter „Neustart ausstehend“.
- Unter Entwicklerwerkzeuge → Neustart Home Assistant neu starten.
Schritt 3 – Gerät einbinden:
Unter Einstellungen → Geräte & Dienste: Wurde das Gerät automatisch erkannt, direkt auswählen und übernehmen. Falls nicht, manuell hinzufügen und als Host die zuvor notierte(n) IP-Adresse(n) eintragen.
So sieht die eingerichtete Integration mit allen drei Geräten aus:
Nach erfolgreicher Verbindung tauchen die Entitäten auf. Wer schon mal in den Entwicklerwerkzeugen von Home Assistant nach number. gesucht hat, kennt das Bild:
Die ausführlichen Original-Anleitungen von SunEnergyXT findet ihr hier: Integration einrichten und Plugin über HACS installieren.
3. Das Standard-Blueprint einrichten
SunEnergyXT liefert für ein einzelnes 500 oder 500 Pro ein fertiges Nulleinspeisung-Blueprint mit. Bevor man es einrichtet, sollte Folgendes stehen:
- Home Assistant ist installiert und eingerichtet.
- Die Integration für SunEnergyXT 500 bzw. 500 Pro ist eingerichtet, das Gerät ist sichtbar.
- Ein externer Zähler ist in Home Assistant verfügbar – Shelly, BitShake/Tasmota, EcoTracker oder eine andere Zähler-Integration.
- Gerät, Zähler und Home Assistant hängen im selben lokalen Netzwerk.
Das Original-Blueprint findet ihr hier: Original-Blueprint auf GitHub.
Die Installation läuft über Einstellungen → Automatisierungen & Szenen → Blueprints → Blueprint importieren, dort die Import-URL des Herstellers einfügen (alternativ die YAML-Datei manuell nach /config/blueprints/automation/sunenergyxt/ kopieren). Danach:
- Unter den Blueprints „SunEnergyXT 500 Serie – Nulleinspeisung“ auswählen.
- Gerät auswählen, Verhalten bei voller Batterie festlegen, maximale Netzeinspeiseleistung setzen – 800 W für den 500er, 2.400 W für den 500 Pro, sofern vor Ort kein niedrigerer Grenzwert gilt.
- SOC-Grenzen setzen (System Entladegrenze, System Ladegrenze).
- Genau einen Zählertyp wählen und nur das dazu passende Formular ausfüllen – EcoTracker ist als Typ direkt eingebaut, keine Bastellösung nötig.
- Speichern, aktivieren, den externen Zähler beobachten. Er sollte sich dem Zielwert annähern.
Ich habe während der Tests übrigens immer einen neuen Ordner angelegt, um die verschiedenen Versionen darin abzulegen und zu testen.
Der Zielwert im Auslieferungszustand: 0 W am externen Zähler. Genau dieser Punkt wird gleich wichtig.
4. Warum das für drei Geräte nicht reicht
Das Standard-Blueprint ist für genau ein Gerät gedacht. Setzt man es dreimal parallel auf, alle drei am selben Zähler – dann versucht jedes Gerät für sich, denselben Zählerwert auf null zu bringen, ohne von den beiden anderen zu wissen. Das Ergebnis: Die Geräte regeln gegeneinander statt miteinander, und am Ende schwankt alles mehr, als es müsste.
Genau dafür bräuchte es eine Koordination, die alle drei Geräte kennt. In der App ist dies die smarte Multi-Bereich-Strategie. Für Home Assistant habe ich das für die lokale Multi-Bereich-Kommunikation mit einem gemeinsamen externen Regelkreis nachgebaut.
5. Die Erweiterung: ein Regelkreis für drei Geräte
So stehen die drei Geräte bei uns aktuell im Keller übereinander gestapelt:
Der Grundgedanke: Ein einziger Regelkreis liest beispielsweise den EcoTracker als alleinige Wahrheitsquelle und schreibt daraus abgeleitet pro Zyklus zwei Werte je Gerät – den Netzleistungs-Sollwert (GS) und die maximale Wechselrichterleistung (IS).
Aktuell bekommen alle drei Geräte denselben Sollwert – eine bewusste Vereinfachung für den Start, keine endgültige Entscheidung. Eine Staffelung oder Priorisierung zwischen den Geräten, abhängig von z. B. dem SOC-Stand, möchte ich zukünftig auch wieder einbauen.
Statt einer fixen Regelrate arbeitet die Automatisierung mit fünf Reaktionsstufen. Ein Trigger prüft jede Sekunde, geschrieben wird aber nur, wenn das Mindestintervall der aktuell zutreffenden Stufe erreicht ist:
- Halteband: ±40 W um die Ziel-Netzleistung von 35 W – innerhalb dieser Zone passiert nichts.
- klein: Abweichung unter 45 W, Schreibintervall 7 s.
- mittel: 45–150 W, Schritt 120 W, Intervall 2,5 s.
- mittelhoch: 150–250 W, Schritt 180 W, Intervall 2 s, ungedämpft.
- groß: 250–800 W, Schritt 250 W, Intervall 2 s.
- Notausgleich: ab 800 W, Schritt bis ca. 1.500 W, Intervall 2 s.
Hier ist, denke ich, das größte Feintuning-Potential, zusammen mit der Berücksichtigung von SOC-Kapazitäten der einzelnen Geräte, an denen ich sicher noch herumtüfteln werde.
Damit sich das Ganze nicht erst live am Wechselrichter beweisen musste, lief die gesamte Regellogik parallel in einer eigenen Python-Simulationsumgebung – dieselbe YAML/Jinja2-Logik, isoliert durchgespielt, ganz ohne echte Hardware im Zugriff. Dazu habe ich nach dem Test einiger KI-Modelle zum Schluss mit Claude Pro gearbeitet. Pro deshalb, da das Blueprint bei den Beschränkungen des Free Accounts wohl noch Wochen gedauert hätte.
6. Die Stolpersteine
Ganz ohne Umwege ist das nicht gelaufen. Die Kernprobleme zuerst im Überblick: eine falsche Rundung beim IS-Wert, eine pauschale 8-Sekunden-Bremse (gs_feedback_settle_s), die unabhängig von der eigentlichen Geschwindigkeit jeder Stufe ausbremste, eine Gain-Dämpfung, die sogar im Notausgleich noch griff, ein einzelnes störrisches Gerät, das über einen gemeinsamen Zeitstempel alle drei gleichzeitig blockieren konnte, und sequenzielle statt parallele Schreibvorgänge, bei denen ein Timeout an einem Gerät die anderen beiden mitblockierte.
Ein paar Beispiele:
Die ursprüngliche „unruhige“ Beobachtung
Auslöser für die erste Intervall-Anpassung: Der EcoTracker-Verbrauch stieg über mehrere 5-Sekunden-Zyklen (31 W → 88 W → 383 W), bevor die Ladeleistung überhaupt zu reagieren begann.
Und die nächste Baustelle…
Nach dem ersten Intervall-Fix sah die Regelung auf dem Dashboard weiterhin „eingefroren“ aus – Ladeleistung über mehrere Zyklen kaum verändert, SOC nahe 98 %.
Der Blick ins Home-Assistant-Log zeigte aber: Im Hintergrund wurden längst neue, deutlich unterschiedliche Sollwerte geschrieben – nur die tatsächliche Geräteleistung folgte spürbar langsamer. Eine Vermutung ist, dass die Änderungen vielleicht schneller geschrieben wurden, als die internen Wechselrichter hinterherkamen.
Reaktion auf die vorletzte statt die aktuelle Situation
Durch genau diese Verzögerung entstand zeitweise sogar eine Reaktion in die falsche Richtung – Entladen, während gerade ein großer Überschuss anlag:
An dieser Stelle half der Blick auf die Regelstrategie des Herstellers selbst: überraschende Parallelen im Prinzip, aber auch Unterschiede – ein breiteres Totband und eine feinere Stufenauflösung. Dementsprechend habe ich das Blueprint wieder angepasst und eine neue Zwischenstufe abgeleitet. Einen großen Dank an SunEnergyXT, die mir mit Infos geholfen haben, das Blueprint zu verbessern.
Nebenwirkung: Datenbankwachstum
Die Sollwert-Entitäten werden häufig neu geschrieben – der Trigger prüft zwar jede Sekunde, tatsächlich geschrieben wird aber nur alle 2 bis 7 Sekunden, je nach Reaktionsstufe. Genau diese häufigen Schreibvorgänge ließen die Home-Assistant-Datenbank auf 13 GB anwachsen.
Die Lösung war nicht, die gesamte Aufzeichnung abzuschalten, sondern gezielt nur diese Entitäten von der Recorder-Historie auszuschließen – identifiziert über genau die Entity-Liste von oben. Ärgerlich war, dass ich dann für die Bereinigung der Datenbank meine Home-Assistant-Festplatte vergrößern musste. Da Home Assistant bei mir jedoch als virtuelle Maschine auf einem Homeserver läuft, war das technisch kein großes Problem.
Fazit
Aus dem Blueprint für ein Gerät ist ein ist ein System geworden, das über einen gemeinsamen Zähler und einen gemeinsamen Regelkreis spricht statt gegeneinander zu arbeiten. Der Weg dahin lief über einige handfeste Stolpersteine, aber mich hat es persönlich auch in Bezug auf mein Home-Assistant-Wissen und meine KI-Codierung weitergebracht. Die Kombination aus Entwicklung, Ausprobieren, Verbessern, Lernen hat mir wahnsinnig Spaß gemacht, die SunEnergyXT-Geräte sowieso.
Fragen und eigene Erfahrungen wie immer jederzeit gerne – euer Zweifachpapa Chris
Antworten