[Oben angepinnt] Nulleinspeisung DIY mit Balkonsolar

Ich will vorwegschicken, nichts was ich schreibe soll ärgern...
...
Das müsste sich etwas besser verhalten als deine Variante.

Vielen Dank für deinen Beitrag Carolus!

Ich freue mich sehr, dass mir jemand mit Sachverstand helfen will! Ich hab das ja tatsächlich mit herumprobieren gebastelt.
Da ich demnächst auf 2 Phasen regeln werde, freut mich diese Hilfe um so mehr!
Mit dem "letzten" Einspeisewert konnte ich tatsächlich keine funktionierende Regelung hinbiegen...
vermutlich ist das der Trägheit des WR geschuldet.
Da ich entschlossen bin, auch die Leistungsdaten des WR abzurufen (s.o.), kann man vielleicht mit dieser Info auch noch etwas verbessern.

Ich werde auf jeden Fall nochmal dazu berichten!
:thumbup:

Du müsstest Mal genau hinschauen, wie der Wandler auf einen "Sprung" reagiert.
Langsamer Hochlauf, einschwingen, ggf Totzeit zu Beginn....

Update: wenn man die tatsächliche Leistung abfragen kann, kann man das in die formel einbeziehen.
Dann ist der P Faktor nicht mehr vom Übertragungstakt abhängig.

Zum Vorschlag, Versuche dochmal folgendes, Stelle die Formel so um:
Summe der Phasen Mal Korrekturfaktor + letzter Wandlerwert ist neuer Wandlerwert

Du meinst also: ( Summe der Phasen Mal Korrekturfaktor ) + letzter Wandlerwert = Wandlerwert
macht: Summe der Phasen + ( Korrekturfaktor x letzter Wandlerwert) = Wandlerwert
nicht mehr Sinn? In der Summe der Phasen ist doch kein Messfehler?

Jedenfalls habe ich mit einem wie von mir skizzierten Korrekturfaktor keinen Erfolg gehabt. 😉
Aber ich werde die andere Variante testen! Update: erste Tests: kein Vorteil

Das erste ist richtig. Der Korrekturfaktor ist praktisch die Verstärkung.
Du kannst den Regler "weicher" / " verzögerter" auf den richtigen Wert bringen oder , wenn du über 1 gehst , einen steileren Anstieg provozieren ... aber,
Vorsicht ... Schwinggefahr 😉

macht: Summe der Phasen + ( Korrekturfaktor x letzter Wandlerwert) = Wandlerwert
nicht mehr Sinn? In der Summe der Phasen ist doch kein Messfehler?

Der P Faktor ist nicht dafür da, um Messfehler zu korrigieren.
Er ist dafür da, um die angeforderte Korrektur gerade klein genug ist, damit es nicht schwingt.

Wenn du also probierst, und es schwingt, dann kleiner machen.

Schau dir Mal
https://tams.informatik.uni-hamburg.de/lehre/2004ws/vorlesung/regelungstechnik/folien/Grundlagen%20der%20Regelungstechnik_01.pdf
an.
Besonders das Bild auf Seite 4.
Auf der Basis könnte ich weitere Details erklären.

Ich habe eine PI-Regler drin für den Wechselrichter und eine Art P-Regler für das Netzteil - da könnte ich aber genau so gut einen PI nehmen
https://github.com/jsphuebner/esp-egycounter/blob/main/battery-control/netzero.py

powerSetpoint = gridPower + setInverterPower.errSum / 5

if powerSetpoint < maxInverterPower:
setInverterPower.errSum = setInverterPower.errSum + gridPower

Also P=1, I=1/5, T=1
Billiges Anti-Windup
gridPower ist der aktuelle Zählerwert, also da "fehlt" quasi schon das bisher ausgeregelte

Um die Schwingungen in den Griff zu kriegen, habe ich noch diverse IIR-Filter drin, also sowas:
lastGridPower = (ptotal + lastGridPower) / 2

Die I-Funktion braucht man eigentlich nur für Genauigkeit im Ausregelvorgang.

Und die Filter sind Mittelwertbildung mit der Vergangenheit, faktisch also Tiefpässe.
Alles im normalen Rahmen.

Die I-Funktion braucht man eigentlich nur für Genauigkeit im Ausregelvorgang.

Naja, "nur" ist gut Hatte es ohne I probiert, dann schwingt sich das ganze beim halben Netzbezug ein. Also bei 900W Bezug steuert der Inverter dann nur 450W bei.

Oh..... Also dann wuerde ich mir den P Teil doch nochmal genauer ansehen :sick: .

Update: ganz besonders die erste Zeile.....

A fool with a tool is still a fool 😉
Ich habe nämlich die TX Leitung vom Wifi-Modul gar nicht am Logic Analyzer angeschlossen :wave:

Ok, kaum macht mans richtig schon gehts. Es kommt nämlich vor der Status-Message immer ein gleichbleibender Request
55 01 2C 2B 5A 63 00 00 00 04 00 E6
Sieht so etwas LIN-mäßig aus mit dem Sync-Byte am Anfang. Ist aber kein LIN.

So, jetzt was wir eigentlich wissen wollten: wenn man eine neue Konfig schickt, kommt:
55 0B 2C 2B 5A 63 00 00 00 04 12 CA

@johuebner Kannst du mir deine Logic Analyzer Mitschnitte zur Verfügung stellen? Toll waere in einem Sigrok kompatiblen Format. Ich habe festgestellt, dass in deiner Beschreibung des Verkehrs ein paar Frames unerwaehnt bleiben vgl. https://github.com/syssi/esphome-soyosource-gtn-virtual-meter/issues/45

Vielen Dank im Voraus!

Da setze ich mich gleich mal dran. Kann nur csv und png exportieren und das proprietäre Format von Waveforms
Heute sieht der Status Request irgendwie 0-lliger aus:
55 01 00 00 00 00 00 00 00 00 00 FE

Config Read
55 03 00 00 00 00 00 00 00 00 00 FC

Hmm, Prüfsumme FF-Byte1 ?

Und nochmal ein Write Settings, diesmal Battery starting voltage=45
55 0B 2D 2B 5A 64 00 00 00 04 12 C8
Battery starting voltage=44:
55 0B 2C 2B 5A 63 00 00 00 04 12 CA

Gut, Prüfsumme 0xFF-byte1...byte10 modulo 256 natürlich

Einen Reply gibt es dazu nicht

Sieht gut aus:

#!/usr/bin/python3

for frame in frames:
sum = 0xff
for i in frame:
sum = (sum - i) & 0xff
print(hex(sum))


Vielen Dank für die Infos! Ab hier komme ich klar.

Habe mal mein Soyosource Skript um die Statusabfrage erweitert: https://github.com/jsphuebner/esp-egycounter/blob/main/battery-control/soyosource_inverter.py

Interessante Beobachtung: wenn ich die 5V von der Wifi-Schnittstelle zum BeagleBone durchleite, funktioniert die Kommunikation über USB nicht mehr richtig... Also abgeknipst.

@johuebner: Ich habe noch eine Bitte! 🙂 Nachdem du nun den "USB-TTL"-Port anzapfst: Kannst du 20-30 verschiedene Status-Responses aufzeichnen und zur Verfügung stellen? Dann könntest du einmal die Batterie-Spannung vom Inverter trennen und schauen ob durch den "DC voltage low"-Fehler irgendwo ein Bit kippt. Ich vermisse naemlich den Inverter-Status (Standby vs. Normal).