openWB Forum

Auch die 1.9.259 schaukelt sich auf.
Die Regel-Zeit steigt stetig an. bei >50 Sekunden hab ich dann abgebrochen.

netstat zeigt mir dann: (63 ist mein RCT, 67 der openWB Pi3B+ mit 1.9.259)

tcp 8242 0 192.168.208.67:38764 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10222 0 192.168.208.67:38668 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 8779 0 192.168.208.67:38876 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 11739 0 192.168.208.67:38782 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10607 0 192.168.208.67:38832 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 7745 0 192.168.208.67:38926 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 11333 0 192.168.208.67:38794 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 11077 0 192.168.208.67:38810 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 6565 0 192.168.208.67:38916 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 9579 0 192.168.208.67:38852 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10225 0 192.168.208.67:38824 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 9127 0 192.168.208.67:38868 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 11867 0 192.168.208.67:38488 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10124 0 192.168.208.67:38492 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10818 0 192.168.208.67:38816 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 7929 0 192.168.208.67:38888 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 12293 0 192.168.208.67:38788 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10416 0 192.168.208.67:38846 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10316 0 192.168.208.67:38762 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 12374 0 192.168.208.67:38862 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 7993 0 192.168.208.67:38896 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 8804 0 192.168.208.67:38784 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 5940 0 192.168.208.67:38908 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 9583 0 192.168.208.67:38746 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 9210 0 192.168.208.67:38694 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10750 0 192.168.208.67:38858 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 8106 0 192.168.208.67:38904 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 10774 0 192.168.208.67:38558 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 9818 0 192.168.208.67:38848 192.168.208.63:8899 VERBUNDEN 22245/python3
tcp 7893 0 192.168.208.67:38880 192.168.208.63:8899 VERBUNDEN 22245/python3

Ich muste den LRS Killen um die Verbindungen wieder los zu werden.

yankee hatte mal ein auswertung der Logdatei vorgestellt die die Laufzeiten statischtisch darstellt.
Damit kommt hier dann folgendes heraus.
(Die hohe anzahl von 6,7,8,9 ist der Normalbetrieb ohne LRS vor dem Update auf die 1.2.259)
---: | --- |
| 6 | 117 |
| 7 | 947 |
| 8 | 1287 |
| 9 | 175 |
| 10 | 11 |
| 11 | 1 |
| 12 | 1 |
| 13 | 2 |
| 14 | 2 |
| 17 | 1 |
| 19 | 1 |
| 20 | 2 |
| 24 | 1 |
| 25 | 2 |
| 30 | 1 |
| 41 | 1 |
| 84 | 1 |
| 95 | 1 |
| 306 | 12 |
| 307 | 6 |
| 308 | 2 |
| 309 | 3 |
| 354 | 2 |
| 384 | 1 |
| 389 | 1 |
| 402 | 1 |
| 421 | 1 |

Siehe auch unsere Diskussion auf GitHub. Die Verbindungen werden nicht ordentlich beendet.

Hm.
zur gleichen Zeit in der die 1.9.259 hier Amok läuft und den RCT zumüllt mit Verbindungen
hat übrigigens die "Produktive"-openWB mit der 1.9.250 (ohne den LRS) keinerlei Ausfallerscheiungen gezeigt.
Sie ist mit 6-8 Sekunden Regelzeit einfach durchgelaufen und alle Werte / Summen / Grafiken zeigen keinerlei Fehler.

Da der eigentlich Kern-Code identisch ist kann es meiner Meinung nach nur am legacy y-Run-Server Liegen.
Er muss wohl je Aufruf eine "frische" Umgebung bereitstellen und wohl auch das Aufräumen erledigen das sonst
die Python Runtimeumgebung durchführen würde.
Da die Laufzeit der RCT Module aber die 10 Sekunden nicht übersteigt ist der Einsatz des LSR eventuell auch gar nicht nötig.

Mein Testsystem ist wieder auf der 1.9.250 und läuft wieder stabil.

Da fällt mir noch was anderes ein.
Sowohl mit RCT alt als auch mit RCT V2 wird die DC Leistung für die Regelung verwendet.
Das ist natürlich nicht das was man bei Überschuss laden haben möchte.
Meine 8,8 kWp Anlage mit DC 6.0 liefert im Sommer teils bis zu 10kWp. Aus dem Wechselrichter kommen aber nur max. 6kWh AC.
Heißt es wird zusätzlich aus dem Netz gezogen und der Rest geht in die Batterie.
Da wäre noch eine Anpassung nötig.
@hhoefling: ich glaube du kennst Dich ganz gut mit den openWB Parametern aus. Wir könnten uns das doch mal gemeinsam anschauen, oder?

Ok. Dein Anwendungsfall kommt bei mir nicht vor 6.1KWP O/W mit 6KW RCT kommt nicht an sein Maximum.
Bei mir ist nur der eigenverbrauch des RCT als unterschied DC/AC erkennbar.
Aber wenn mehr vom Dach kommt als der WR AC-Seitig leisten kann....
...ja dann sollte das Auto auch nicht mehr ziehen.
Also deckeln auf die WR-Leistung.

Schon mal mit die 70% Reglung probiert....
...Keine Ahnung ob die sich auswirkt.

In den Zusammmenhang noch eine Frage.

Konstruieren wir mal ein Beispiel.
Sonne lacht, Hausakku voll.

PV könnte >6KW liefern, wie gesagt könnte,
kann aber nicht da das Auto gerade mit 6 KW läd und somit nur 6KW verbraucht werden (alles andere ist aus)

Also der WR Läuft am Limit und erzeugt 6KW-AC.

Was zeigen openWB und die RCT App in diesen fall als DC Leisung an,
6KW( plus die ~60W Eigenverbauch des RCT)
oder die (möglichen)8-10KW je nach Sonne.

Ich denke RCT wird eine DC Leistung von 6KW Melden (und die möglichen 2-4KW Überhang verschweigen)

- Nächstes Schritt, gleiches Scenario aber Hausakku aufnahmefähig.
Werden dann 10KW DC , 4KW HausAkku-Laden und 6KW AC gemeldet?

Weiteres...
All das gilt nur für die DC gekoppelten Hyprid-WR.
Dort ist der Akku auf der DC Seite angeordnet.
RCT hat auch reine WR bei dennen dann irgendein Akku auf AC Seite angeklemmt werden kann.
In diesem Falle ist die OpenWB reglung natürlich so richtig wie sie gerade ist.

Hallo Heinz,

versuche mal alles zu beantworten. Nochmal kurz mein Setup:
8,8 kWp auf dem Dach
RCT Power DC 6.0 als Wechselrichter
11,8 kWh RCT Akku auf der DC Seite
70% Limitierung, heißt ich darf nur max. 6,1 kW einspeisen, daher auch der DC 6.0

Szenario: Sonne lacht, Hausakku voll.
In diesem Fall regelt der WR die Energiemenge vom Dach auf ca 6kW herunter
(das passiert aufgrund des coolen RCT Algorithmus allerdings sehr sehr selten).
Was jetzt nicht von Haus/Autos verbraucht wird, geht ins öffentliche Netz.

Szenario: Sonne lacht, Hausakku aufnahmefähig
Hier kommen zeitweise sogar über 10 kW vom Dach.
Entweder es geht abzgl. Hausverbrauch alles in den Akku oder
4 kW in den Akku und 6kW auf die AC Seite.
Genau in diesem Fall, versucht die openWB auch mehr die 6 kW in das Auto zu schieben.
Heißt es werden bei mir leider ca. 3,5 kW aus dem öffentlichen Netz gezogen.

Die 70% Regelung habe ich noch nicht ausprobiert, da die ja auch bei geringeren Leistungen (<max. AC Leistung) greift und ich das da eigentlich noch nicht möchte.

Hast Du denn in deinem Setup keine 70% Limitierung oder speist Du nicht ein? Mit 70% solltest Du eigentlich in das gleiche Problem wie ich laufen (DC 6 kW, AC 4,2kW).

Viele Grüße,
Peter

Liegt dann bei dir darin das Speicherladung vorhanden ist und die openWB in der Folge hochregelt damit der Speicher sich nicht lädt.
Da die AC Abgabeleistung begrenzt ist entsteht aber Netzbezug.

Für openWB 2.0 ist das schon gelöst.
Derzeit kann als Workaround "Speichervorrang" gewählt werden, dann wird nur der EVU Punkt, nicht aber die Speicher(lade)Leistung betrachtet.