Rückmeldungen openWB software2 2.2.0

[Gero]

Erst nach dem dritten Mal funktioniert die 1p3-Umschaltung. Erstaunlicherweise wird der dritte Versuch früher als nach den 7 Minuten gestartet. Im Übrigen hätte eigentlich mit 3p begonnen werden müssen. Prio steht auf Fahrzeuge.

Ansonsten hätte ich noch den Verbesserungsvorschlag, mit der Ladung sofort nach Einstecken zu beginnen statt die Verzögerungszeit erst mal abzuwarten. Man kann sich ja merken, wie die Überschuss-Situation in der letzten Zeit war. Z.B. über einen potentiellen Startmerker der bei Ablauf der Einschaltverzögerung gesetzt wird, wenn kein Auto eingesteckt ist. Den kann man dann zum Einsteckzeitpunkt befragen um sofort loslegen zu können.

3p.jpg (138.7 KiB) 163 mal betrachtet

https://paste.openwb.de/E5eFBxx7wQpKx41

[AlexSE]

leider ein erneuter, nicht abgefangener Modbus Peak, sieht wieder nach Zähler Reset der externen SolarEdge Produktion aus, bei der der gesamte Zählerstand übermittelt wird.
Leider genau vor dem Backup, daher kann ichs nicht rausschmeissen oder ich verliere schon wieder einen Tag Daten

Die Logs geben leider keinerlei Aufschluss. Mehr Details wären besser.

Ja, das sagte ich ja auch bereits. Aber hätte ich den Log nicht angehängt, wäre als erstes danach gefragt worden
Dauerhaft auf der höchsten Detailstufe laufen lassen ist leider keine Option. Aber ich werds auf meiner Test VM nochmal neu aufsezten. Leider haben da diese Fehler den Counter bereits auf Anschlag zugemüllt und muss neu aufgesetzt werden.

Zur Funktion:
Der Peakfilter prüft ob die aktuelle Leistung valide ist (das ist einfach).
Es werden allerdings auch die Zählerstände geprüft. Hierzu werden 2 aufeinander folgende Zählerstände verglichen. Ist die Differenz doppelt so hoch wie das was im Regelintervall maximal möglich ist, wird der Peak angenommen.
Der Peakfilter ist kein Allheilmittel sondern dazu gedacht einmalige Kommunikationsfehler zu finden.
Längere Peaks (mehr als ein Regelzyklus) gelten als valide.
Stell dir vor die openWB wird mal aus irgendwelchen Gründen abgeschaltet und erst nach 2 Tagen neu gestartet. Alles was in der Zwischenzeit passiert ist kommt als Peak an - und zwar dauerhaft.
Nebenbei gibt es auch Wechselrichter die ihre Registerwerte nur in Sprüngen erhöhen - auch das sind dann valide Peaks. All diese Fälle müssen abgedeckt werden.
Ein valider Peak ist aktuell so definiert, dass er dauerhaft auftritt.
Meine Vermutung wäre, dass die Anlage den fehlerhaften Wert über mehrere Zyklen hält. Ggfs. ließe sich das nochmal anhand eines Logs nachvollziehen.

Hier ist klar SolarEdge das Problem mit ihrem Software Schrott. Keine Frage.
Nicht umsonst tu ich schon seit November 2024 damit rum und hab die ganze Hardware mittlerweile einmal durchgewechselt bekommen. Ohne Erfolg. Selbst ein direkter Mitarbeiter von SE hat sich das schon angesehen.
Ist halt einfach Software Schrott.
Aber da die meisten Endanwender es nicht in dem Detail verfolgen und überwachen, fallen denen viele Aussetzer auch einfach nicht auf.

Frage:
- Warum wird hier überhaupt die Gesamtsumme eines Zählerstandes übermittelt, wenn der vorhergehende Wert nicht älter <5 Minuten ist?
- Warum greift hier nicht die Abfrage des Lastmanagements bzgl. "Maximale Ausgangsleistung des Wechselrichters"?

Zur Verbesserung:
- Kann hier (evtl. nur für SolarEdge) eine dauerhafte Abfrage gegen "Maximale Ausgangsleistung des Wechselrichters" stattfinden.
- mMn. macht es keinen Sinn, auch bei einem 2 Tagesausfall, nachträglich einen "Gesamtzählerstand" als Datenpunkt zu akzeptieren. Wenn die Wallbox 2 Tage aus war, dann ist es ja auch ein valides Ergebnis, wenn dafür 2 Tage keine Daten vorhanden sind. Aber in der aktuellen Konstellation ist die Gefahr eines zumüllens des Counters einfach sehr groß.

Verbesserung außerhalb von Modbus Peaks:
- Möglichkeit mehrere automatisierte Backups pro Tag erstellen zu lassen


Danke & VG

[LenaK]

Ich musste ein bestehendes Fahrzeug (ich glaube, wurde mit ID: 1 angelegt) durch ein neu anzulegendes Fahrzeug (ID: 3) ersetzen. Problem, damit sind so wie es aussieht, die ganzen Ladelogs für das „alte“ Fahrzeug verschwunden.

Frage, wie kann ich die Logs reaktivieren?

Gruß

Hans

Aktuell leider nur über den csv-Download. Ein Fix ist in Arbeit.

[LenaK]

Ich habe noch mal getestet und bin mir sehr sicher, dass da weiterhin ein Bug drin ist.

Mein Test:
Das Auto hat eine Batterie Kapazität von 33kWh. Hinterlegte Wirkungsgrad ist 90 Prozent. Es hatte um 6:35 Uhr einen Ladestand von 50 Prozent. Als Ziel habe ich einen Ladestand von 60 Prozent um 7:15 Uhr mit einer Ladeleistung von 10A und maximaler Phasenzahl angegeben.

Erwartetes Verhalten:
Für die benötigte Ladung von 3,3/0,9=3,7kWh reicht Ladung mit 10A nicht aus, da so bei 2-phasigem Laden in 40 Minuten nur ca 33kWh geladen würden. Es müsste auf ca 12A erhöht werden.

Beobachtetes Verhalten:
Es kommt korrekt die Meldung, dass die Ladeleistung erhöht wurde, um das Ziel zu erreichen. Allerdings nicht auf 12A, sondern auf 7,67A, was faktisch eine Reduktion der Stromstärke ist. Diese Stromstärke wäre bei 3-phasiger Ladung korrekt, aber nicht bei 2-phasiger Ladung. Offenbar wird also bei der Berechnung der veränderten Stromstärke weiterhin nicht berücksichtigt, dass das Auto nur 2-phasig lädt.

Ich wäre sehr froh, wenn dieser Bug mal wirklich gefixt würde und das dann nach Möglichkeit auch schnell in einen Patch einfließen würde und nicht erst wieder ins nächste Release.

Wenn ich mal einen Tipp bekomme, an welcher Stelle im Code ich anfangen muss, kann ich mir das auch mal selber anschauen, aber ich habe keine Zeit, mich durch den ganzen Code zu wühlen

Es wundert mich etwas, dass sich solche Bugs so hartnäckig halten. Sind die Autos bei euch Objekte? Dann wäre es doch sinnvoll, dass das Auto weiß, wie es laden kann und dass die Laderoutine in so einem Fall das Auto fragt, welche Stromstärke es braucht, um eine Ladeleistung von den benötigten 5,5kW zu erreichen. Dann müsste man nur noch die Auto-Klasse testen und hätte nicht verteilt im Code solche Berechnungen.

Log: https://paste.openwb.de/OpuPlVXhJNAUKHh
Screenshots:
Screenshot_20260520-063749_Native Alpha.png
Screenshot_20260520-063739_Native Alpha.png

Ist im Master behoben. Nächstes Release ist in den nächsten zwei Wochen geplant.

[mattberlin]

Hallo,

kann es sein, dass es irgendwann zwischen Release und dem aktuellen Master eine Änderung gab?:

Steckt man die Karre an UND es war schon zuvor für eine Zeit in der Länge von "Wartezeit Ladestart" die Überschussbedingung erfüllt, dann wird sofort das PV-Laden begonnen, ohne die "Wartezeit Ladestart" abzuwarten - zumindest hatte ich gestern den Eindruck, dass es so ist.

Falls dem so ist:
Gerade eben hat es nicht funktioniert.
Es wurde auch in 1p begonnen, obwohl schon für 2 h ausreichend Überschuss für 3p vorhanden war.

https://paste.openwb.de/o8jkv7wtOLvUDyY

[Gero]

Gerade eben hat es nicht funktioniert.
Es wurde auch in 1p begonnen, obwohl schon für 2 h ausreichend Überschuss für 3p vorhanden war.

same here: viewtopic.php?p=143781#p143781 Allerdings wusste ich nicht, dass im Bereich retrospektivem Ladestart Änderungen gegeben hat - oder haben soll.

[therobbot]

@LenaK: danke. Ich hatte auch schon mal selber in den Code geschaut, aber ehrlich gesagt fiel es mir schwer, bei den verschiedenen plan-Variablen und phase-Variablen durchzublicken. Da hätte ich mich tiefer in die Logik einarbeiten müssen. Anscheinend ist ja im Plan nicht automatisch die korrekte Phasenzahl hinterlegt.