Beiträge von ElsenerJunge

Der schlechte Wirkungsgrad kommt aus meiner Sicht nicht vom SBS sondern von der Resu 7H. Ich hatte die gleiche Kombination und einen Jahreswirkungsgrad von 67 %. Mit einer Resu 10M sind es jetzt 79%.

Die Resu 7H ist keine echte Hochvoltbatterie. Da gibt es einen internen DCDC als Spannungswandler, was bestimmt nicht förderlich für den Wirkungsgrad ist.

Zitat von Matthias_Roeschinger

Dachneigung richtig? Ausrichtung etwas Richtung süd korrigieren.

Dachneigung ist richtig eingestellt. Wenn ich es richtig verstehe, würde durch die "Korrektur" nach süd die Prognose etwas besser. Die ist tendenziell nämlich im Mittagspeak immer etwas zu niedrig. Das wird da sicher helfen.

Das eigentliche Problem ist aus meiner Sicht aber, dass der Wechselrichter in der Abregelung ist, die Batterie freie Kapazität hat, es wird aber nicht geladen. Dafür braucht man keine Prognose, sondern die Batterielade-Regelung kann unmittelbar auf die Ist-Werte reagieren. Das macht sie aber nicht, da sie laut eigener Status Meldung gar nicht weiß, dass gerade der Wechselrichter in der Abregelung ist.

Das der Batterieregler grundsätzlich extrem gut (einseitig) einem Sollwert folgen kann sieht man ja beim Entladen. Da werden 0 W am Netzanschlusspunkt sauber geregelt. Gleiches müsste er in der Abregelung mit dem 50%-Wert der Nennleistung machen, ggf. mit einem kleinen Abschlag nach unten, damit er sich nicht mit der Regelungen vom WR in die Quere kommt. Aber wenn er nicht weiß, dass gerade abgeregelt wird ...

Ein ebenso sonderbares Verhalten auch bei mir. Am Montag war keine Wolke am Himmel, was auch die Anlagen auf Sunny Places im Umkreis von ein paar Kilometern bestätigen.

Die Anlage ist Ost/West mit 9,9 kWp und 50% Abregelung wegen der Batterie.

Offenbar braucht die Laderegelung immer etwas, bis die Abregelung erkannt wird (vgl. ~10:30 ... 11:30). Danach sieht es ganz gut aus, bis um 12:30 kurz der Herd lief. Danach war die Laderegelung völlig "von der Rolle" und hat sich erst gegen 15:00 wieder berappelt.

Interessant sind die Statusmeldungen auf Wechselrichter (STP 8.0) und Batterie-WR (SBS 3.7), jeweils gegen 13:50

Offenbar bekommt der Batterie-WR nicht mit, dass sich die Anlage in der Abregelung befindet.

Natürlich geht es nur um wenige kWh an einigen Tagen im Jahr, aber die Verläufe sehen einfach blöd aus.

Das Verhalten gab es auch schon letztes Jahr, aber der SMA-Service konnte oder wollte das Problem nicht einmal verstehen.

Hat irgendjemand eine Idee, was man da noch machen kann?

Bei mir verhindert dass prognosebasierte Laden auch nicht immer eine Abregelung obwohl noch reichlich Kapazität in der Batterie frei ist. Besonders intensiv tritt das nach einem negativen Lastsprung auf. Die Batterie wird erst nach dem Ende der Abregelung geladen .

7fsc72 Gab es einem brauchbaren Hinweis vom SMA Support?

Zitat von t0mberg

Wenn der Speicher dann bei 40% gegen 15 Uhr aufhört zu laden. ( nächster Tag sehr sonnig) ich aber abends gerne mehr im Speicher haben möchte, habe ich mir eine Funksteckdose als MUSS VERBRAUCHER 2 kW in die Zeit von 20-24 Uhr angelegt. Mit der Aktivierung/Deaktivierung dieses "Verbrauchers" kann ich den Speicher dann auf das Prozent genau hochfahren.

Ist etwas umständlich, aber funktionert sehr gut

Coole Idee. Genau so etwas habe ich gesucht. Danke!

Da ich den SAE für eine Warmwasser-Wärmepumpe sowieso am Laufen habe, werde ich dort einen "Fake"-Verbraucher definieren und hoffen, das der Homemanager es nicht lernt, dass dieser Verbraucher nie den eingeplanten Strom abnimmt

Zitat von bumaad

Nachdem meine ersten Gehversuche in einer VM sehr erfolgreich waren, wollte ich nun dauerhaft auf einen Raspberry Pi Zero umsteigen.

Bei der Installation des openjdk-11-jre-headless Pakets kommt es jedoch zu einer Fehlermeldung:

Code

Error occurred during initialization of VM
Server VM is only supported on ARMv7+ VFP

Sehe ich es richtig, dass für die Version 1.5 dann mindestens ein Raspberry Pi 2 Mod.B benötigt wird. Oder gibt es auch eine Möglichkeit für den Zero?

Für den Zero geht nur 1.4. Aber selbst das ist nicht ohne Tücken, da der Timeout beim Starten von 60s zu kurz ist. Ich hatte das vor einiger Zeit mal gepostet.

Zitat von camueller

Wenn Du den SAE startest, kannst dir den kompletten Aufruf, den das Start-Script macht, aus der Prozess-Liste holen:

Code

$ ps waux|grep sae.home
sae       1970  0.0  0.0   4784   524 pts/0    S+   11:29   0:00 grep --color=auto sae.home
root     15974  0.0  0.3  10284  3040 ?        S    Apr01   0:00 sudo -u sae /usr/bin/java -Djava.awt.headless=true -Xmx256m -Dlogging.config=/opt/sae/logback-spring.xml -Dsae.pidfile=/var/run/sae/smartapplianceenabler.pid -Dsae.home=/opt/sae -jar /opt/sae/SmartApplianceEnabler-1.5.4.war
sae      15980  2.6 13.7 439380 130528 ?       Sl   Apr01 332:27 /usr/bin/java -Djava.awt.headless=true -Xmx256m -Dlogging.config=/opt/sae/logback-spring.xml -Dsae.pidfile=/var/run/sae/smartapplianceenabler.pid -Dsae.home=/opt/sae -jar /opt/sae/SmartApplianceEnabler-1.5.4.war

Jetzt solltest Du den SAE stoppen, falls er läuft.

Dann kannst Du den SAE in der aktuellen Shell starten mit dem Aufruf von oben (dritter Eintrag oben - der ohne "sudo"):

Code

$ /usr/bin/java -Djava.awt.headless=true -Xmx256m -Dlogging.config=/opt/sae/logback-spring.xml -Dsae.pidfile=/var/run/sae/smartapplianceenabler.pid -Dsae.home=/opt/sae -jar /opt/sae/SmartApplianceEnabler-1.5.4.war

Jetzt siehst Du auf der Console, wie der SAE startet und ob es Fehler gibt. Außerdem kannst Du im Log schauen, ob da was drin steht.

Axel

Alles anzeigen

Axel, vielen Dank für den Tip.

Von der Konsole ließ sich der SAE ohne Fehler starten. Das Problem war wirklich ein Timeout, da der Start bei mir auf dem Pi Zero ca. 105s dauert.

Den Timeout zu umgehen war allerdings kniffeliger als erwartet, da zum einen im Startscript /opt/sae/smartapplianceenabler nach 60 s abgebrochen wird und dann zusätzlich der systemd per Default nach 90s den Start eines Dienstes stoppt.

In /opt/sae/smartapplianceenabler habe ich "sleep 1" durch "sleep 3" ersetzt, so dass der Start bis zu 180s dauern darf. Danach musste ich noch in /lib/systemd/system/smartapplicanceenabler.service "TimeoutStartSec=90s" auf "TimeoutStartSec=180s" ändern.

Seitdem läuft jetzt der SAE auch auf meinem Pi Zero und ich habe eine nette Auffrischung meiner etwas eingestaubten Linux System-Kenntnisse hinter mir .

Ja genau, das "skipping ..." war für mich der einzige Ansatz den ich hatte, da es ein scheinbar auffälliger Eintrag im Log war.

Kann es evtl. ein Timeout Problem sein weil der Pi Zero langsam ist? Der Start dauert auf jeden Fall sehr lange, bis der Abbruch kommt. Davor sehe ich in der Taskliste, dass ein java Prozess läuft.

Gibt es eine Möglichkeit zu erkennen, ob ein Timeout zugeschlagen hat?

Zitat von Cliw

Zitat von ElsenerJunge

Vermutlich war meine Beschreibung bzgl. 1.5.3 und 1.4.19 etwas missverständlich. Das beschriebene Problem tritt mit folgender Konfiguration auf:

Pi Zero + Rasbian Stretch + Oracle Java 8 + SAE 1.4.19

Dabei habe ich mit einer Rasbian Stretch Neuinstallation begonnen und bin genau alle Schritte der Doku durchgegangen. Sicherheitshalber habe ich jetzt nochmal die Java Version geprüft. Das sollte nach meinem Verständnis aber passen.

pi@raspberrypi:~ $ java -version

java version "1.8.0_65"

Java(TM) SE Runtime Environment (build 1.8.0_65-b17)

Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)

Ich wäre super dankbar, wenn ihr noch einen Hinweis hättet.

Markus

Alles anzeigen

Stehe vor demselben Problem bei gleichem Setup - hast du es zwischenzeitlich lösen können?

Gruß

Alles anzeigen

Leider habe ich bislang noch keine Lösung finden können. Ich fürchte, dass ich auf einen neueren Pi wechseln muss.

Buster lässt sich problemlos installieren, aber es gibt für den Pi Zero kein passendes OpenJDK 11.

Die prognosebasierte Ladung funktioniert bei mir über den Tag recht gut. Eingestellt sind 20% Ladung bis zum Beginn der prognosebasierten Ladung. Allerdings stoppt der SHM die Batterieladung bei den zur Zeit sehr guten Prognosen für den nächsten Tag bei ca. 50% SOC. Das passt ganz passable für den über Nacht prognostizierten Verbrauch (inkl. kleiner Reserve für ungeplanten Verbrauch). Trotzdem ist die Batterie trotz tatsächlichem Verbrauchs unterhalb der Prognose morgens komplett leer und es kommt zu geringem Netzbezug. Der Grund scheint mir der Wirkungsgrad des Batteriesystems (SBS3.7 + LG Resu 7H) von unter 70% zu sein, den der SHM offenbar nicht lernt.

Gleichzeitig ist für die Vermeidung einer Wirkleistungsbegrenzung momentan bei weitem noch nicht die ganze Batteriekapazität notwendig, insbesondere da eine regelmäßige tägliche Abnahme von ca. 500 W durch eine Warmwasserwärmepumpe sicher gelernt werden kann.

Insgesamt sieht es für mich danach aus, dass der SHM lieber einen Netzbezug in der Nacht riskiert als eine Wirkleistungsbegrenzung über Mittag. Gibt es eine Möglichkeit hier die Gewichte zu verschieben? Die Steuerung des Optimierungsziels über ökologisch/wirtschaftlich ist für mich an der Stelle absolut intransparent.

Falko Schmidt: Ein zusätzlicher Parameter mit dem man einen Sicherheitsfaktor für den prognostizierten Verbrauch angeben könnte, wäre aus meiner Sicht sehr hilfreich. Zum einen könnte man damit einen schlechten Wirkungsgrad des Batteriesystems kompensieren und zum anderen die Reserve für die Nacht gegenüber der Wirkleistungsbegrenzung höher priorisieren.