Also hier erstmal zu deinem LXC Problem:
Debian 13 geht — seit heute auch direkt im Proxmox-Helper: bei „Defaults verwenden?" auf Nein, dann steht Debian 13 Trixie im Menü. python3-venv regelt der Installer selbst (auf Trixie also python3.13-venv). Getestet auf debian-13-standard_13.6-1, komplett bis durch den Setup-Wizard. Debian 12 Bookworm dagegen fällt raus: es liefert nur Python 3.11, dafür bricht der Installer jetzt mit einem klaren Hinweis ab, statt scheinbar durchzulaufen.
Okay, ich werde den Container löschen und einen neuen mit Trixie bauen.
Kannst du mir noch etwas zu dem WR Problem sagen bzw. einen Rat / Tipp geben?
Puh, du willst es aber wissen.
Ok, da spielen jetzt mehrere Dinge mit.
- Komplett autarke AC-Batterien hatte ich bis jetzt noch nicht, entsprechend sind sie nicht im Programm. Wenn du aber Lust hast diese mit mir zu implementieren, würde ich das gerne machen, allerdings dann nur im Community Forum, damit wir hier nicht alles zu spamen, und dann können wir die Bugs direkt in deinem Thread lösen.
- Das mit der Wallbox ist tatsächlich ein Bug den ich nicht bedacht habe, dafür gibt es aber einen einfachen Fix den ich gleich einspiele.
- Messpunkt als Bilanzquelle habe ich noch gar nicht bedacht, separate Messpunkte, und diese verwaltet als Hersteller und Produktquellen habe ich gerade erst hinzugefügt für Leute, die gerne in den Aufgaben eine Aufgabe anlegen möchten, wie zero export to Messstelle und dabei selber die Messstelle wählen wollen (z.b. ein Shelly). Kann ich implementieren, ist quasi ein Feature, braucht aber mindestens mal 2 Tage für alles zusammen und dich als Tester mit Rückmeldungen.
Ganz vergessen zu sagen, das Forum ist aktuell nur per Invite zugänglich,
ich möchte erstmal alle groben Schnitzer raus haben, und eure Hardware unterstützen,
bevor ich nachher 100 Support-Requests habe… Ich schicke dir gleich einen Invite-Link
ja klar, ich würde aber sagen, dass wir das in einem separaten Thread im Community Forum bei mir behandeln, sonst wird das hier etwas unübersichtlich. Das Forum ist aktuell noch nur per Invite zugänglich, ich schicke dir gleich mal einen Link dafür.
1 „Gefällt mir“
Die Notwendigkeit sollte nicht unterschätzt werden, entsprechend würde ich sogar „muss haben“ sagen.
Ich stehe noch am Solhive-Spielfeldrand und schaue bisher nur zu aber die Idee eines autarken EMS gefällt mir schon sehr gut.
Als Victron-Fanboy kann ich bestimmt auch AC-Speicher-Fragen beantworten und so unterstützen.
Für alle die gerne Zugang zum Beta Forum haben möchten, bitte hier Beta-Bewerbung — Solhive kurz registrieren.
Ich beende meine Versuche. Mir fehlt die Geduld, das läuft hier zu zäh.
Eventuell komme ich nochmal darauf zurück, wenn Solhive ausgereifter und intuitiver ist. Meine Beta-Bewerbung wurde bisher nicht beantwortet, ist auch nicht mehr nötig.
Alles klar, kein Problem @HaGoDo .
Leider ist vorgestern meine Schwiegermutter gestorben, etwas unglückliches Timing dass ich
gerade jetzt die Öffentlichkeit suche, aber letzte Woche sah es noch nicht so schlimm aus. Auf Grund des Sterbefalls waren die letzten zwei Tage doch recht voll.
Nichts desto trotz habe ich deine Bugs und deine Wünsche schon mal aufgenommen und werde sie jetzt umsetzen. Wenn du später nochmal Lust hast, kannst du dich ja jederzeit nochmal melden.
An alle anderen: Ich werde diese Woche leider etwas mit halber Kraft arbeiten, da mir Familie einfach wichtig ist. Wie ihr im Changelog aber seht, ich bin dran.
Zum Thema Beta-Einladungen: Bei mir sind die Bewerbungen eingegangen, dann ist mir aber noch ein Fehler aufgefallen dass ihr keinen Beta-Lizenzkey bekommen hättet, und ohne funktioniert das Debug System noch nicht (Wer keinen Lizenzkey hat, kann keine Supportanfrage stellen, aber trotzdem das System komplett nutzen. Geht da primär nur um langsam das System zu öffnen)
EDIT:
Ich musste gerade mich noch rechtlich absichern, deswegen habe ich erst die Datenschutzerklärung und die ganzen Rechtstexte angepasst und prüfen lassen, sowohl für die Webseite, das Forum und die Feature Request Formular bei Fider…
Hallo,
ich hab jetzt ein bisschen herum gespielt und solhive gefällt mir soweit ganz gut.
Wirklich beeindruckend was du da umgesetzt hast!
Besteht die Möglichkeit einen Sigenergy Wechselrichter/Batterie in die Liste der Geräte aufzunehmen?
Momentan habe ich es über die Homeassistant Entitäten gelöst, aber da scheint der Akku nicht im Dashboard auf. Ausserdem wird vermutlich die EMS Umschaltung auch schwierig werden.
LG
Manfred
ich bin auch gerade dabei alles nach und nach einzurichten.
ich habe aktuell 3 WR, die sich nicht löschen lassen.
ist das schon bekannt?
habe auch bereits mehrfach neugestartet.
Hallo,
das hört sich grundsätzlich erst mal sehr interessant an.
Gefällt mir vom Ansatz her super.
Ich nutze hier fast ausschließlich Proxmox mit knapp 20 LXC Containern.
Ich verwende normalerweise aber Arch-Linux und notfalls noch DietPi, weil das sowohl im LXC als auch auf den diversen PI Modellen aus Anwendersicht gleich läuft.
So läuft z.B. EVCC in einem separaten LXC unter DiePi
HAOS läuft leider als VM auf Proxmox …
Ich habe mir die Demo ein wenig angesehen, bin aber bei den Einstellungen gleich auf ein paar Unklarheiten gestoßen und müsste rätseln, welche Werte ich eintragen muss.
Vielleicht liegt das an meinem Environment.
So hängt hier das gesamte Haus inkl. Wallbox am Backup Port des Sungrow SH25T. Der Hausanschluss ist hier ausschließlich mit dem Grid Anschluss des SH25T verbunden.
Daher nehme ich mal an, das bei der Konfiguration des Hausanschlusses nicht die 63A des Hausanschlusses selbst einzutragen sind, sondern die 25A die der SH25T am Backup Port liefern kann.
Ist ja wohl egal ob er das aus den 30kWp Panels, dem 22kWh Akku oder -wenn alle Stricke reißen- aus dem Netz holt.
Bevor ich mich hier ins Unglück stürze, frage ich mal nach…
Sollte Solhive mit so einer 100% Backup Lösung umgehen können? Oder sind da Schwierigkeiten zu erwarten.
Warum bei uns kein neuronales Netz die Sonne vorhersagt
Die Frage kam in den letzten Tagen mehrfach auf, und sie ist berechtigt: Andere Systeme werben mit Deep Learning — LSTM-Netze, Attention, Transformer mit zweistelligen Millionen Parametern. Solhive nicht. Warum eigentlich?
Vorweg, weil das oft durcheinandergeht: Wir nutzen sehr wohl maschinelles Lernen. Die Verbrauchsprognose ist ein trainiertes Gradient-Boosting-Modell. Die Solarprognose korrigiert sich selbst über gelernte Faktoren pro MPPT-Strang, über Sonnenhöhen-Buckets, Monatsfaktoren und ein Schatten-Kataster, das den Schattenverlauf deines Daches über den echten Sonnenstand lernt. Dazu ein Kalman-Filter für den Live-Nowcast. Das ist alles lernend — es ist nur kein Deep Learning. Und das ist eine bewusste Entscheidung, keine Bequemlichkeit.
1. Bei Photovoltaik ist der größte Teil gar kein Lernproblem
Wo die Sonne in 90 Minuten steht, welchen Winkel sie zu deinen Modulen hat, wie warm die Zellen bei 28 °C und 2 m/s Wind werden — das ist Physik. Berechenbar, exakt, ohne einen einzigen Trainingstag. Das erledigt bei uns pvlib.
Ein neuronales Netz muss sich diese Physik erst aus deinen Messdaten herleiten. Es lernt dann mühsam etwas, das wir bereits exakt wissen — und rät schlechter, sobald eine Situation kommt, die so noch nicht im Training vorkam. Der wirklich unsichere Teil sind Wolken, Verschattung, Verschmutzung und die Eigenheiten deiner Anlage. Genau dort — und nur dort — setzen wir das Lernen an.
2. Deine Anlage startet bei null Daten
Am Tag der Installation existiert keine Historie. Ein tiefes Netz braucht Monate bis Jahre, um überhaupt etwas Sinnvolles zu sagen — inklusive eines vollständigen Jahresgangs, damit es den Winter kennt. Ein System, das erst im zweiten Betriebsjahr brauchbar wird, ist für einen Neukunden wertlos.
Unsere Kaskade fängt deshalb ganz unten an und reicht nach oben durch: ML-Modell → Slot-Prior → Muster-Fallback → statischer Wert. Ab Tag eins kommt eine belastbare Zahl heraus, nur eben mit ehrlich ausgewiesener Unsicherheit. Nach knapp drei Monaten lag das Verbrauchsmodell bei rund 209 W mittlerem Fehler.
3. Jetzt zu den Zahlen — was das Ding tatsächlich kostet
Ich habe unsere Prognose-Bausteine nachgemessen, damit hier keine gefühlten Werte stehen. Gemessen auf meiner Workstation; für die typische Zielhardware (ein bis zwei vCPU im Container bzw. ein Compute-Module-5-Kern) rechne ich konservativ mit Faktor fünf.
| Vorgang | gemessen | auf Zielhardware | wie oft |
|---|---|---|---|
| Nächtliches Training des Verbrauchsmodells (2160 Stunden-Datensätze) | 1,8 s | ~9 s | 1× pro Nacht |
| Sonnenstand + Clear-Sky für 48 Stunden (pvlib) | 6,8 ms | ~35 ms | alle 30 min |
| Eine Verbrauchsprognose abrufen | 0,12 ms | ~0,6 ms | pro Regelzyklus |
| Ein Kalman-Update im Live-Nowcast | 0,15 µs | ~1 µs | pro Messwert |
Zusammengerechnet kostet die komplette Prognose-Rechnerei rund 20 bis 25 Prozessor-Sekunden am Tag. Ein Tag hat 86.400 Sekunden — das sind etwa 0,03 % eines einzelnen Kerns. Das Gesamtsystem inklusive Wechselrichter-Abfrage, Datenbank, Weboberfläche und Regelung liegt bei rund 2 % eines Kerns und etwa 270 MB Arbeitsspeicher, gemessen an einer real laufenden Anlage. Solhive läuft damit auf 1 vCPU und 1 GB RAM.
Und die Gegenseite?
Nehmen wir ein Netz in der Größenordnung, mit der geworben wird: rund 20 Millionen Parameter. Die Faustformel für einen Vorwärtslauf sind zwei Rechenoperationen je Parameter und Zeitschritt; fürs Training kommt der Rückwärtslauf dazu, grob Faktor drei.
-
Eine einzelne Vorhersage über ein Kontextfenster von einer Woche: rund 7 Milliarden Rechenoperationen. Ein sparsamer ARM-Kern schafft davon in der Praxis vielleicht 2 Milliarden pro Sekunde. Macht ein bis fünf Sekunden pro Prognose — bei uns liegt die komplette Neuberechnung deutlich unter einer Sekunde, der Physik-Teil bei 35 Millisekunden.
-
Ein vollständiges Training über ein Jahr Messdaten: je nachdem, wie groß man Kontextfenster und Trainingsdurchläufe ansetzt, landet man zwischen etwa einem halben Tag und mehreren Wochen Dauerlast auf demselben Kern. Unser nächtliches Training braucht neun Sekunden.
Das ist, je nach Ansatz, ein Faktor von mehreren tausend bis über hunderttausend. Dazu der Speicher: allein die Gewichte belegen rund 80 MB, mit Optimierer-Zuständen und Zwischenergebnissen ist man beim Training schnell bei einem halben bis mehreren Gigabyte. Unser gesamter Dienst braucht 270 MB. Die PyTorch-Installation allein wiegt mehrere hundert Megabyte bis über ein Gigabyte.
Deshalb trainieren solche Systeme in aller Regel nicht bei dir zu Hause, sondern in der Cloud — oder sie liefern ein fertig trainiertes Modell mit, das deine Anlage gar nicht kennt. Beides ist ein Tauschgeschäft: entweder deine Daten gehen raus, oder das Modell weiß nichts von deinem Dach.
Nebenbei, und für eine Solar-Community vielleicht der schönste Punkt: Ein System, das jede Nacht stundenlang unter Volllast rechnet, verbrennt einen spürbaren Teil dessen, was es dir an Ertrag optimieren soll. Unsere neun Sekunden nicht.
4. Der Punkt, der mir am wichtigsten ist: Ich muss den Fehler finden können
Die letzten drei Wochen sind der beste Beleg. Wir hatten drei echte Fehler in der Prognose:
-
Die Korrekturstufen haben sich multipliziert und denselben Fehler mehrfach bestraft. Das Rohmodell traf auf 5,9 % genau — angezeigt wurden 165 % daneben.
-
Bei Abregelung wurde der Ausgleich nicht auf den tatsächlichen Fehlbetrag begrenzt.
-
Der Nowcast bekam die gedrosselte Leistung zu sehen statt der möglichen — und hat daraus gelernt, die Anlage sei schwächer, als sie ist.
Alle drei waren Struktur-Fehler, keine Modell-Schwäche. Wir konnten sie finden, weil man die Kette von vorne bis hinten lesen kann: Physik → Korrekturen → Nowcast → angezeigter Wert. Jede Stufe hat eine Zahl, die man nachprüfen kann.
In einem Netz mit 20 Millionen Parametern wäre keiner dieser drei Fehler jemals sichtbar geworden. Man hätte festgestellt: „die Prognose ist ungenau" — und weitertrainiert. Gegen einen systematischen Fehler in den Eingangsdaten hilft kein Training der Welt, es zementiert ihn nur.
Und das ist keine akademische Frage. Diese Prognose steuert echte Hardware: Batterie, Netzladung, Wallbox. Wenn sie danebenliegt, lädt jemand nachts für teures Geld Strom, den er tagsüber geschenkt bekommen hätte. Da will ich sagen können, warum eine Entscheidung so gefallen ist — nicht nur, dass das Netz es so wollte.
5. Und, ist es denn schlechter?
Das ist am Ende die einzige Frage, die zählt. Unsere Vortages-Prognose lag am 18. und 19. August bei 4,2 % und 4,7 % Tagesabweichung. Das sind unsere besten Werte, nicht der Schnitt — aber es zeigt, wo die Decke inzwischen liegt.
Die Genauigkeitsangaben, mit denen Deep-Learning-Systeme werben („93–97 %"), sind fast immer Selbstauskunft ohne definierte Metrik. Ohne zu wissen, worauf sich die Prozente beziehen — Tagessumme? Stundenwerte? Über welchen Zeitraum, bei welchem Wetter? — ist die Zahl schlicht nicht vergleichbar. Ich habe mir eines dieser Projekte im Juni genauer angesehen. Es ist beeindruckend gebaut. Aber es gibt keinen belastbaren Beleg, dass es besser trifft, und in einigen Punkten sind wir schlicht feiner: Wir rechnen pro MPPT-Strang statt in vier groben Panel-Gruppen, wir haben ein Schatten-Kataster über den echten Sonnenstand, und unsere Abregelungs-Erkennung wertet sieben unabhängige Signale aus.
Zum Schluss: Die Tür ist nicht zu
Ich bin nicht ideologisch gegen neuronale Netze. Ich bin gegen Aufwand ohne Gegenwert. Wenn jemand zeigt, dass ein tiefes Netz auf unserer Zielhardware, mit der Datenlage einer frisch installierten Anlage, reproduzierbar besser trifft — dann sehe ich mir das ernsthaft an.
Bis dahin stecke ich die Zeit lieber in die Stellen mit echtem Hebel: eine Prognose als Korridor statt als einzelne Zahl (P10/P50/P90), damit der Aufgabenplaner rechnen kann „so viel Überschuss ist zu 90 % sicher da". Ein sauberes Zurücksetzen des Gelernten, wenn du Module dazubaust. Sichtbare Gütewerte, damit du selbst siehst, wie gut die Prognose gerade arbeitet. Und die saisonale Verschattung durch Laub, die unser Kataster heute noch nicht unterscheidet.
Das bringt euch mehr als ein Transformer, der 20 Millionen Parameter dafür aufwendet, sich den Sonnenstand herzuleiten, den wir längst exakt ausrechnen.
1 „Gefällt mir“
Also fasse ich zusammen, dein Haus hängt komplett am Backup-Port, so dass man eigentlich deinen Backup-Port als Netzanschluss konfigurieren müsste?
Wenn du mir das genauer beschreiben könntest, wäre das super.
Meine Annahme ging davon aus, dass die meisten Menschen die Wechselrichter so betreiben, dass sie entweder CTs haben oder ein Smartmeter. Entsprechend kannte mein System noch keine zusätzlichen Messpunkte.
Da ich aber eine ähnliche Anwendung bei mir jetzt habe, und ich gerne meinem zweiten Wechselrichter ein Software geführtes Zero Export to Messstelle beibringen möchte, und ich dafür frei konfigurierbare Messstellen implementiert habe, wäre es eigentlich jetzt sinnvoll, diesen Ausbau weiter voran zu treiben, und den Messpunkt für unsere Regelung separat zu definieren.
Die nötige Änderung am System ist schon strukturell drin, aber ich bin gerade dabei noch die Leistungsbilanzen die dann im Haus entstehen zu definieren. Da wäre deine Antwort echt hilfreich
Nein das ist nicht bekannt, ich teste es direkt nochmal und gebe dir gleich bescheid wenn der Fix raus ist.
Gib mir mal eine Typ oder Modellnummer, dann bekommen wir das bestimmt hin. Wenn eine HA Integration existiert, gibt es meist auch einen Weg dazu, muss ich mir aber anschauen. Schreib mir gerne eine PN
Ein angelegtes Gerät lässt sich über die Einstellungen grundsätzlich nicht löschen, sobald mindestens zwei Geräte derselben Klasse vorhanden sind. Das gilt für alle acht Geräteklassen (Wechselrichter, Balkonkraftwerke, Wallboxen, Verbraucher, Wärmepumpen, Messpunkte, Speicher, Fahrzeuge). Ich habe es End-to-End über den echten Speicherpfad reproduziert:
vorher: ['Deye 12K', 'Deye 5K']
gesendet: ['Deye 12K']
nachher: ['Deye 12K', 'Deye 5K'] ← und genauso in der config.yaml
Ursache: Der ✕-Knopf entfernt den Eintrag nur lokal aus dem Array (SettingsView.vue:2017), gespeichert wird danach die komplette Config per PUT /api/settings. Im Backend läuft das durch _merge_list (config.py:2510), und diese Funktion ist bewusst als Vereinigung über das name-Feld gebaut: ein weggelassener Eintrag gilt nicht als gelöscht, sondern als „nicht angefasst" und wird aus dem Bestand wieder eingefügt. Der Docstring sagt dazu selbst, man müsse zum Löschen einen dedizierten DELETE-Endpunkt benutzen — den gibt es für keine einzige Geräteklasse. Der Lösch-Knopf benutzt also den einen Weg, der per Konstruktion nicht löschen kann, und den anderen gibt es nicht.
Bugfix wird gerade getestet, dann kurz ein update machen, dann sollte das löschen gehen…
Ja, das schauen wir uns gerne an — Sigenergy steht auf meiner Liste, und die Voraussetzungen dafür sind besser als bei vielen anderen Herstellern.
Zuerst aber dein Akku-Problem, das lässt sich sofort lösen: Wenn du deinen Wechselrichter über manuell zugeordnete HA-Entitäten eingebunden hast, musst du den Speicher einmal explizit anmelden. Einstellungen → dein Wechselrichter → Abschnitt Batterie → Haken bei „Batterie vorhanden", dazu die nutzbare Kapazität und die Kopplung (beim SigenStor: DC, der Akku hängt hinter dem Wechselrichter). Ohne diesen Haken legt Solhive gar keine Speicher-Einheit an, und die Kachel bleibt leer. Bei Geräten mit fertigem Profil kommt diese Information automatisch vom Wechselrichter — beim manuellen Weg eben nicht. Zugeben: das ist unglücklich gelöst, das schreibe ich mir auf.
Prüf danach bitte einmal das Vorzeichen. Schau aufs Dashboard, während der Akku sicher lädt. Zeigt Solhive stattdessen „entladen", dann hast du einen Bug von uns erwischt: unser HA-Pfad dreht das Vorzeichen aktuell fest nach der Deye-Konvention um (dort ist positiv = entladen), und Sigenergy liefert es nativ andersherum. Einen Schalter dagegen gibt es noch nicht — den baue ich ein, sag mir einfach kurz Bescheid, was du siehst.
Zur EMS-Umschaltung liegst du richtig, und ich will dir da nichts versprechen, was heute nicht geht: Über HA-Entitäten kann Solhive momentan nur lesen. Der Schreibpfad ist noch auf die Deye-Namenskonvention verdrahtet, fremde Integrationen kommen da nicht durch. Steuern geht also über diesen Weg nicht.
Der richtige Weg wäre ein echtes Modbus-Profil. Und da sieht es gut aus: Sigenergy veröffentlicht sein Modbus-Protokoll offiziell (aktuell V2.7 vom Mai 2025), und darin ist die Fernsteuerung ausdrücklich vorgesehen — es gibt ein Register für den „Remote EMS control mode" (40031) und darauf aufbauend Lade-/Entladegrenzen (z. B. 40032 „ESS max charging limit"), die greifen, sobald der Remote-Modus aktiv ist. Genau das ist die Schnittstelle, auf die unser Aufgaben-Modell zielt. Sigenergy wäre damit der erste Hersteller, bei dem die EMS-Übergabe sauber dokumentiert ist statt zusammengereimt.
Was ich dafür brauche: dich als Tester. Register rate ich grundsätzlich nicht — bei Deye hat uns das schon einmal viel Zeit gekostet, und ein falsch geschriebenes Register kann an einer echten Anlage weh tun. Konkret:
-
Modbus-TCP freischalten. Geht in der mySigen-App (System → drei Punkte hinterm Anlagennamen → Systemeinstellungen → Gerät → SigenStor-Einstellungen → „Modbus TCP Server Enable" → oben rechts Speichern nicht vergessen), notfalls über deinen Installateur. Dazu Port 502, eine feste IP für den SigenStor und die Modbus-Slave-Adresse. Firmware sollte SPC109 oder neuer sein.
-
Sag mir dein genaues Modell (SigenStor EC …, Speichergröße, Anzahl Module) und deine Firmware-Version.
-
Wenn Modbus läuft, baue ich dir ein Profil zum Testen — erst nur lesend, Steuerung danach in einem zweiten Schritt, wenn die Messwerte sauber stehen.
Als Zwischenlösung, falls du sofort mehr Daten willst: Die HACS-Integration Sigenergy-Local-Modbus liest sehr viel aus und liefert dir saubere Entities zum Mappen. Es gibt außerdem das HA-Addon sigenergy2mqtt, das Sigenergy über MQTT bereitstellt und auch schreiben kann — das wäre perspektivisch ein zweiter Anschlussweg für uns, weil Solhive einen MQTT-Treiber mitbringt.
Hallo @echnaton ,
ich hatte im Betaforum eine Frage gepostet, die leider unbeantwortet blieb. Daher poste ich die Frage hier noch einmal:
Ich versuche gerade meine Anlage abzubilden. Ich habe zwei Wechselrichter, der ersten Kostal Plenticore G3 M konnte ich auswählen. Der zweite ist ein Kostal Piko 20. Dieser fehlt in der Liste.
Am Plenticore hängt mein Speicher, ein Pylontech Force H3 HV mit drei Blöcken und einer Kapazität von 15,4 kWh. Auch dieser fehlt in der Liste.
Wo kann ich das Smartmeter eintragen? Ich setze einen Hichi mit Tasmota ein, der die Daten zu einem Mosquitto überträgt.
Ja genau.
Der Hausanschluss geht zu einem “neuen” Zählerkasten und von dort mit 5x16mm2 zum Grid Anschluss des Sungrow SH25T. An dieser Leitung hängt das Sungrow übliche DTSU666-20 Smartmeter. Dort wird also erfasst wieviel gerade aus dem Netz bezogen bzw. eingespeist wird.
Daneben lese ich den Bezug / die Einspeisung / Zählerstand noch mal über die optische Schnittstelle des “Stromzählers” des Netzbetreibers aus.
Am SH25T sind alle 3 MPPTs mit insgesamt 5 Strings belegt.
Je ein MPPT für Ost-, West- Süd Dach.
Der Sungrow SBR224 22kWh (Hochvolt) Akku ist direkt mit dem SH25T verbunden.
Vom Backup Port des SH25T geht es dann ebenfalls via 5x16mm2 an den “alten” Zählerkasten. Und da hängt dann alles dran.
Wenn genügend Solar Ertrag da ist, werden damit zuerst einmal alle Verbraucher im Haus versorgt.
Ist was übrig, wird der Akku geladen (Hab ich aktuell auf 5kW Ladeleistung begrenzt).
Wenn dann noch was übrig ist gehts ins öffentliche Netz.
Bei 14,6kW wird wegen 60% Regel abgeregelt.
Reicht der Solar Ertrag nicht aus, wird der Strom zusätzlich aus dem Akku geholt. Nachts also 100% aus dem Akku …
Die Leistung des Akkus reicht aus um bei einem Stromausfall das Haus mit max. 3*25A Notstrom zu versorgen.
Dauert der Stromausfall länger und die Akku Kapazität sinkt unter 22kW wird ein Notstromaggregat mit 3,4 kW gestartet und der Strom mit 400V DC ebenfalls in den Wechselrichter eingespeist. Quasi wie ein zusätzlicher PV-String.
Das ganze System verhält sich im Grunde wie eine Online-USV für Computer.
In Home-Assistant verwende ich die Integration von Mkaiser.
In der GUI sieht das dann z.B. so aus:
Der Akku wird jetzt angezeigt, wie schon vermutet mit falschem Vorzeichen. Ich hab das jetzt über ein Template in HA angepasst. Ein Schalter für das Vorzeichen wäre natürlich praktisch, um ein Template würde man trotzdem nicht herum kommen, da die Sigenergy-Local-Modbus Integration alle Werte als kW liefert.
Ich kann gerne testen. Modbus ist schon aktiv. Wechselrichter ist SigenStor EC 12,0 TP (Firmware V100R001C21). Batterie SigenStor BAT 10,0 - 9,04kWh (Firmware V100R001C00). 8 Module am 1. String und 20 Module am 2. String (je Modul 460W).