evcc und Batterieeinstellungen

[TRON4R]

Hallo liebe evcc-Nutzer,

nachdem ich verstanden hatte, dass die Nutzung der Batterieeinstellungen nur bedeutet, dass der für das Laden des Autos verwendete Überschuss anders berechnet wird, als ich naiverweise der Doku entnommen hatte, (die 5 kW Ladestrom, die mein Hausspeicher aufnehmen kann, werden einfach nur vom Autoladestrom abgezogen - und nicht als Schaltschwelle benutzt), habe ich das sonnige Wetter heute gleich mal dazu genutzt, das auszuprobieren und den prioritySoc im UI auf 80% hochgestellt.

Es gab allerdings ein paar seltsame Effekte, die ich so vorher noch nie erlebt hatte. Das Auto lud z.B. für kurze Zeit mit 11,1 kW und es gab Probleme mit der Umschaltung zwischen 1-phasig und 3-phasig und öfter kam die Anzeige am Loadpoint, dass der Schaltschutz aktiv sei). Bei der Gelegenheit habe ich noch einmal gemerkt, dass man beim Einsatz von evcc mit Huawei-Wechselrichtern manchmal anscheinend einfach dem Ganzen paar Minuten Zeit geben muss bis alles richtig eingepegelt ist.

Nachdem dann aber die Werte soweit stabil und im sinnvollen Bereich liefen, stellte ich jedoch fest, dass ich ständig 0,8 kW in das Stadtnetz eingespeist habe. Da fiel mir dann ein, dass ich den Wert residualpower noch auf 500 Watt stehen hatte (weil ich in meinem ursprünglichen Setting der Batterie immer etwas zukommen lassen wollte) und habe den Wert erstmal auf die für Systeme mit Hausspeicher in der Doku empfohlenen 100 Watt runtergesetzt.

Leider geht das nur über die evcc.yaml, was einen Neustart des Dockers auf meiner Synology erforderlich machte. Allerdings habe ich dabei noch einmal gemerkt, dass es evcc wirklich gar nicht mag, mitten in einem Ladevorgang neugestartet zu werden (das nächste Mal werde ich den Ladevorgang vor einem Neustart immer beenden, denn am Ende läuft er sowieso nicht durch. Ich freue mich schon darauf, wenn solche Werte wie wohl schon geplant zukünftig direkt über das UI eingestellt werden können).

Aber selbst danach blieb die Einspeisung ins Stadtnetz häufig im Bereich von 0,3 kW (meist schwankend zwischen 0,2 und 0,4 kW).

Jetzt aber zu meinen Fragen / Erkenntnissen:
Vorher - als ich dem Auto Vorzug gegeben hatte, indem ich den prioritySoc auf 10% stehen hatte, war der Vorteil, dass kurzfristige Schwankungen in der Stromerzeugung oder im Stromverbrauch vom Huawei-Wechselrichter in Echtzeit ausgeglichen werden konnten, indem kurzfristig entsprechend einfach mehr oder weniger Strom in die Hausbatterie geschickt wurde.

Wenn aber die Batterie schon die ganze Zeit am Anschlag mit 5 kW lädt, dann können Verbrauchseinbrüche oder spontane PV-Leistungssteigerungen leider nicht mehr von der Huawei-Steuerung abgefangen werden, sondern nur noch über die Veränderung der Ladeleistung am Loadpoint geregelt werden. D.h. der Anteil des Stroms, der durchschnittlich ins Stadtnetz gespeist wird, steigt dadurch spürbar an.
Das mag jetzt ein Spezialfall von Huawei-Wechselrichtern sein, weil die nur sehr langsam auf die Abfragen von evcc reagieren (für einen stabilen Betrieb mit 2 SUN2000-WRs musste ich das Intervall sogar von 30 Sekunden auf 35 Sekunden hochsetzen und bekomme trotzdem immer noch oft Fehlermeldungen, wenn ich in der FusionSolar-App von Huawei einen Parameter verändere, weil der Dongle total ausgelastet ist). Aber bis zu 35 Sekunden lang speise ich dann entsprechend Strom ins Stadtnetz statt in mein Auto, weil evcc eben nicht so sekundenschnell reagieren kann wie die Batteriesteuerung vom Wechselrichter.

In der Hinsicht war meine alte Vorgehensweise, das Auto mit soviel Strom zu laden, dass nur 3 bis 4 kW für den Hausspeicher übrig blieben, einen Tacken besser, denn da konnte die Batteriesteuerung sofort in beide Richtungen reagieren.

Das ist jetzt natürlich alles anderes als tragisch und betrifft vermutlich auch nur Besitzer von Huawei-Geräten oder anderen Herstellern, welche die benötigten Werte nur in so langsamen Intervallen rausrücken. Aber der permanente "gelbe Rand" an der rechten Seite der evcc-Anzeige war und ist schon auffällig. 🙂

Jetzt meine Frage:
Ist es angedacht, einen Parameter einzuführen, mit dem ich den maximalen Batteriebezug im Falle der Priorität des Batteriespeichers durch prioritySoc regeln kann?
Irgendwie scheint ja evcc automatisch herausgefunden zu haben, dass mein Hausspeicher mit maximal 5 kW geladen werden kann.

Würde es entwicklungsseitig Sinn machen, dass man diesem Batteriebezugs-Wert eine Regelgung verpasst, in der Art dass man z.B. sagen kann:
Schick dem Hausspeicher immer 1 kW weniger als maximal möglich (also ein relativer Offset) und entsprechend mehr ins Auto oder
Schick dem Hausspeicher maximal 4 kW (also eine absolute Obergrenze definiert)

Oder würde es schon ausreichen, wenn residualpower über das UI einstellbar würde (ich bin mir gerade nicht sicher, ob ich irgendwelche Randfälle übersehe)?

[premultiply]

Das Hausspeichersystem ist bzgl. seiner Leistungsregelung autark.
Für sehr schlechte Implementierungen oder falsche Einstellungen dort können wir nichts.

"Normale" Speichersysteme regeln die Leistungsschwankungen sehr schnell nach vorgegebenen Kurven aus. Das passiert regelmäßig in Sekundenbruchteilen bis hin zu niedrigen Sekundenbereichen für größere Lastsprünge.

Was bei deinem System da verkehrt läuft kann ich nicht beantworten.
Jedenfalls scheint es bei Huawei-Systemen nur über die RS485-Schnittstelle eine brauchbare Kommunikationsverbindung zu geben.

[JoergO]

Also wir haben auch einen SUN2000MA-10KTL-M1, mit 10kWh LUNA2000, DTSU666 und SDongel-A05 - der ist allerdings per LAN-Kabel im Netz und nicht per WLAN. An den Intervallen in evcc habe ich nix geändert und die Werte kommen ohne Fehlermeldung rein. Liegt das vielleicht an deinen 2 Wechselrichtern?

@mucki12 : Du schreibst "...erfolgt durch evcc bei Huawei ja (noch) nicht..." - bedeutet, dass ist in Arbeit? Wäre sehr daran interessiert, weil mir die Wallbox beim (nicht PV) Laden immer den Speicher leer zieht... Wenn ich da irgendwie unterstützen/supporten kann, will ich das gerne versuchen ;-)

[mucki12]

@SolarPowerEV
Denke auch, dass das mit Kaskade einfach zu viel für den sDongle ist.

@JoergO
Die evcc Entwickler benötigen dafür in der Tat mehr Input von Usern:
#10806
Mir fehlen fürs Testen gerade ein wenig die PV-Erträge. Allerdings habe ich das auch bereits mit Home Assistant über die Entladeleistung umgesetzt.

[TRON4R]

@JoergO nur zur Klarstellung: mein SDongleA-05 hängt auch per LAN im Netz. Ebenso meine Synology, wo evc im Docker-Container läuft.

Ich habe eine Gigabit-Verkabelung im Haus und nutze die, wo ich nur kann, um wackelige WLAN-Verbindungen zu vermeiden, wann immer möglich. Meine Alfen-Wallboxen hängen z.B. auch direkt am LAN-Kabel.

Verzögerungen in der Abfragegeschwindigkeit liegen definitiv nicht an der Verbindungsqualität. Die Kabel sind durchgemessen und funktionieren einwandfrei und keine der Komponenten ist per WLAN eingebunden.

Abfragen über die Kommandozeile unter Windows oder Linux (in der VM auf meiner QNAP) gehen auch nicht schneller. Das liegt eindeutig am Dongle selber, der je nach Lust und Laune mal alle 4 Abfragen (grid, pv-master, pv-slave, battery) in 20 Sekunden, manchmal aber auch erst in 31 Sekunden schafft.

Wenn evcc im Docker läuft und ich dann parallel noch eine Abfrage über Windows mache, läuft meist mindestens eine Abfrage, manchmal auch beide in einen Timeout (aber nicht immer 🤪).
Veränderungen via FusionSolar, während evcc aktiv ist, enden ebenfalls oft in einem Timeout-Error. Schalte ich evcc ab, geht es meist (aber auch nicht immer 🤪) auf Anhieb durch. Seitdem das Interval auf 35 Sekunden steht, klappt es aber in der Regel nach 3 Anläufen, ein Setting abzuspeichern. Vorher hat es manchmal 6 oder 7 Anläufe gebraucht.

[mucki12]

@SolarPowerEV
Meintest du mit "Abfrage über Windows" eine Modbus Abfrage, oder die Nutzung von FS Web? Ersteres verträgt der Dongle auch schon ohne Kaskade nicht - bei einer Modbus Verbindung ist Schluss.

Habe mal irgendwo von Leuten gelesen, die an dem zweiten Sun2000 ebenfalls noch einen Dongle angesteckt haben. Weiß aber nicht ob man dann die Kaskade auflösen müsste... Angeblich (nagel mich nicht drauf fest), wird das Gebilde in FS dann dennoch als eine Anlage dargestellt.

So oder so - der sDongle ist halt Mist. Wahrscheinlich hat Huawei den absichtlich so besch...eiden geplant um mehr Smartlogger und zukünftig Emma Geräte zu verkaufen :-)

[TRON4R]

Ich meinte mit "Abfrage über Windows", dass meine reguläre evcc Installation im Docker-Container auf meiner Synology läuft, ich aber noch eine evcc Installation auf meinem Windows PC mit identischer evcc.yaml habe, wo ich per Kommandozeile evcc Abfragen ausführen und Änderungen an der evcc.yaml austesten kann.
Insofern besteht die Möglichkeit, während evcc im Docker läuft, gleichzeitig noch eine Abfrage mit evcc unter Windows an den SDongle zu schicken. Aber das mag der natürlich überhaupt nicht, weil er nur für die Windows-Abfrage evcc meter oft bis zu 30 Sekunden braucht und selbst ein evcc meter grid oder evcc meter battery schon schnell 10 bis 15 Sekunden dauern kann, bis die Antwort zurück kommt. Wenn dann tatsächlich der Docker noch aktiv ist, dann failed die doppelte Abfrage in gefühlt 80% der Fälle teilweise oder sogar ganz.

Wie das mit der Kaskadierung der Wechselrichter als Master und Slave funktionieren soll, wenn man zwei SDongles im Einsatz hat, jeweils einen am Master und einen am Slave, weiß ich leider auch nicht. Es fühlt sich ein bisschen so an, als ob das nicht vorgesehen sein könnte von Huawei und dann die Kaskadierung aufgelöst werden müsste. Da würden aus meiner Sicht wieder die Nachteile überwiegen und ich würde dann lieber weiterhin die hässliche Dongle-Kröte schlucken.

Und ja, dass man in den 20er Jahren des 21. Jahrhunderts, wo man einen raspberry PI mit ordentlich Dampf (900 MHZ quad core ARM CPU) für unter 50 EUR kaufen kann, sich noch traut, so einen SDongle den Leuten anzudrehen, kann eigentlich nur brutale Absicht gewesen sein, um den Einstiegspreis erstmal niedrig zu halten und später den völlig entnervten Techies dann noch einen Smartlogger oder eine EMMA verkaufen zu können. Ich weiß gar nicht, wo man so langsame Prozessoren, die 30 Sekunden brauchen, um gefühlt nicht mehr als 20 Zahlen zurückzuliefern, überhaupt heute noch kaufen kann.