MatzeTF

Ich kann dein Problem mit dem Umschalten auf Min+PV leider nicht nachstellen. Wenn ich versuche, den Ablauf in deiner ersten Grafik nachzustellen, wird nach dem Umschalten zu Min+PV eine Phasenumschaltung durchgeführt und dann immer ohne Verzögerung eine Ladung freigegeben. Ohne ein Event-Log aus dem fraglichen Bereich komme ich da nicht weiter. Bitte installiere mal diese Firmware. Die gibt in einem Fall, wenn kein Strom freigegeben wurde, eine zusätzliche Meldung im Log aus. Wenn dir das Problem nochmal auffällt, gleich ein Log runterladen und gerne zusammen mit einer Grafik hier hochladen. energy_manager_firmware_2_1_0_662bab4a_97884bf056af3f5_merged.bin

Ich bin nun endlich dazu gekommen, mir deine neuen Grafiken anzusehen, musste aber gerade feststellen, dass der Text in den Grafiken nur schwer lesbar ist. Hast du sie zufällig noch in Originalgröße? Poste nächstes Mal bitte keine verkleinerten Bilder sondern nur in Originalgröße. Zu deinen Fragen: Bei Reglern gibt es zwei grundsätzliche Ursachen für Überschwingen: zu aggressive PID-Parameter und zu kurzer Regelzyklus. Beispielsweise sieht der Regler 200 W Überschuss am Hausanschluss und gibt dem Auto exakt 200 W mehr. Leider treffen die meisten Autos nicht exakt die vorgegebene Leistung und in diesem Fall nimmt das Auto 300 W mehr. Daraufhin sieht der Regler 100 W Bezug und gibt dem Auto 100 W weniger. Daraufhin springt das Auto wieder um 300 W runter und das Ganze wiederholt sich. Diesen Fall haben wir übrigens exakt so mit einigen Fahrzeugen beobachtet. Im diesem Fall waren die PID-Parameter ungünstig, weshalb der WEM aktuell einen P-Regler mit adaptiver Schrittweitenregelung verwendet. Soll bedeuten, dass bei großen Leistungsunterschieden 90 % der überschüssigen oder fehlenden Leistung an das Auto weitergegeben wird. Bei kleinen Leistungsunterschieden reduziert sich das bis auf 50 %, was Überschwingen recht gut dämpft. Für das zweite Problem sehen wir uns dein Auto an: Zu Beginn der Ladung sieht der Regler Überschuss am Hausanschluss und gibt 6 A frei. Nach 10 s hat das Auto noch nicht angefangen zu laden und der Regler sieht immer noch Überschuss am Hausanschluss. Daraufhin gebt er 10 A frei. Nach insgesamt 18 s beginnt das Auto zu laden, allerdings hat der Regler das aufgrund von Verzögerungen in der Messkette zwei Sekunden später noch nicht gesehen und gibt 14 A frei. Da das Auto nun lädt, springt es schnell auf diese 14 A. Das ist natürlich viel zu viel, weshalb der Regler wieder Strom zurücknimmt. Hätte der Regler eine Zykluszeit von 25 s, hätte er beim zweiten Mal Nachschauen am Hausanschluss bereits die Ladeleistung vom Auto gesehen und hätte sie nicht unnötig erhöht. Hier ist also nicht die Wahl der PID-Parameter das Problem, sondern die Zykluszeit. Das Überschwingen aufgrund trödeliger Autos lässt sich aktuell nicht gut verhindern, ohne den Regler so langsam zu machen, dass dadurch das Nachregeln auf die PV-Leistung schlechter wird. Ansonsten liegt das Überschwingen in deiner zweiten Grafik voll im Rahmen. Dass das Überschwingen bereits nach zwei Perioden abgeklungen ist, bedeutet, dass der Regler eine gute Dämpfung hat. Vielleicht können wir da mit der anstehenden Überarbeitung des Lastmanagements trotzdem noch etwas was verbessern. Mal sehen. Dein Problem mit der ersten Grafik schaue ich mir gleich noch genauer an, allerdings bräuchte ich dafür eigentlich das Ereignis-Log, das du gerade in diesem Fall leider nicht hast.

Hat dein selbstgebautes IO-16 eine eigene Stromversorgung? Zum Flashen muss der Master Brick das Bricklet mittels Power Cycle neustarten können, was mit zusätzlicher Stromversorgung nicht funktioniert.

Es gibt dafür keine API vom Brick, aber du kannst wie in deinem Beispiel direkt mit den esp_* Funktionen reden. Beachte allerdings, dass der Rest des Projekts nicht erwartet, schlafen gelegt zu werden. Es kann z.B. sein, dass dein Projekt vom Watchdog neugestartet wird oder dass du verschiedenste Timeouts bekommst. Außerdem wirst du die WLAN-Verbindung verlieren, sofern du nicht auch noch spezielle Einstellungen für WLAN-Schlafen einbaust.

Das Problem dabei ist, dass die Wirleistung den Spannungsabfall der Zuleitung beinhaltet. Kommen bei deiner Wallbox nur noch 220 V an und das Auto lädt schon mit 16 A, siehst du 10560 W. Teilst du das durch 230*3 und schlussfolgerst, dass du bei 15,3 A noch 0,7 A mehr geben kannst, bist du dann in Wirklichkeit schon bei 16,7 A. In unserem alten Firmengebäude kamen teilweise nur 210 V bei den Wallboxen an. Wäre man da von 230 V ausgegangen, wäre man schon 1,4 A drüber gegangen. Ich habe gerade gestern bei einem Ladevorgang Strom und Leistung verglichen. Da ich sonst immer nur die Leistungskurve im Webinterface der Wallbox gesehen habe, dachte ich, dass das Fahrzeug einfach schwankend Leistung bezieht. Stellte sich heraus, dass der Ladestrom die ganze Zeit konstant war und die Schwankungen in der Leistung nur durch die schwankende Netzspannung verursacht wurden. Den Ladestrom nur anhand eines Leistungswertes, egal ob Wirk- oder Scheinleistung, einzustellen, halte ich daher für problematisch.

Wir überlegen gerade, ob man Modbus auch anders unterstützen kann, allerdings steht noch nichts fest. Wenn der WR eine Modbus-Bridge wäre, würde es darauf ankommen, wie die implementiert wäre. Nicht jede Bridge ist vollständig transparent. Ist mit CAN aber sowieso hinfällig.

Basierend auf welchen Daten beschließt du, dass das Auto zu wenig Strom zieht? Gemessener Strom vom Zähler? Wirkleistung? Scheinleistung?

Sieht so aus, als stellt dein Wechselrichter die Werte vom Netzanschluss nicht über SunSpec bereit. 😒

Sungrow mag anscheinend nicht so viele Anfragen. Deine Logs bestehen praktisch nur aus Lesefehlern. Kannst du testweise mal einen SunSpec-Zähler ohne Suche anlegen und von Hand die Geräteadresse 247, Model 701 und Instanz 0 eingeben? Sowohl mit als auch ohne Proxy? Werden da (nach einem Neustart) irgendwann Werte beim Zähler angezeigt?

Spontan würde ich zu Schrittmotoren und dem Silent Stepper Bricklet 2.0 Bricklet raten. Die Geräuschentwicklung dürfte für deinen Anwendungsfall egal sein, aber im Silent-Betrieb solltest du glatte, ruckelfreie Bewegungen hinbekommen.

Hängst du die Logs auch hier an? 🙂 Für die meisten Sungrow-Bugs haben wir Workarounds. Was bleibt, sind häufige Lesefehler bei gleichzeitigen Modbus-Zugriffen. Wenn du da noch mit OpenHAB oder einer App draufhängst, wird das irgendwann unbenutzbar. Wechselrichter würden wir gerne bauen, allerdings ist die Konkurrenz bei Wallboxen schon schwierig. Das wird bei Wechselrichtern noch schlimmer sein.

Wir haben jetzt noch einige Korrekturen für Sungrow-Probleme eingebaut. Bitte teste mal diese Firmware und lade anschließend ein Log der Gerätesuche hier hoch. warp3_firmware_2_3_0_6626a111_0ca140bbadd4d87_merged.bin

Wenn die Wallbox längere Zeit im Status „ladebereit“ bleibt, heißt das entweder, dass das Fahrzeug voll ist oder dass es aus anderen Gründen nicht laden möchte, z.B. wegen 80%-Limit. Etwas besseres gibt es da aktuell nicht. Längere Zeit „ladebereit“, obwohl das Fahrzeug laden möchte, kann nur im Fehlerfall auftreten, wenn das Fahrzeug die Ladefreigabe nicht annimmt.

Der Widerstand zwischen PP und PE codiert die Belastbarkeit des Kabels. 1k5 bedeutet, dass es ein 13 A-Kabel ist. Meine Vermutung ist, dass für ISO15118 ein korrekter PP-Widerstand angelegt werden muss und pyPLC an der Stelle einfach den größtmöglichen Widerstand gewählt hat, da sie die AC-Leitung nicht nutzen. Der tatsächliche Wert des PP-Widerstands kann für CCS nicht verwendet werden, da sich damit maximal 63 A codieren lassen, DC-Lader aber mit bis zu 500 A laden.

Whandlerverlust 😀 Danke, ist gefixt.