Rückmeldungen 2.1.8 Beta 1

[fawick]

Rueckfrage zu https://github.com/openWB/openwb-ui-set ... 086aaae02b (Ausbau eines Hinweistextes im MQTT-SOC-Modul):

Waere es vielleicht eine Idee, wenn jedes Auswerten von "openWB/set/mqtt/vehicle/id/get/..." implizit "openWB/mqtt/vehicle/id/get/force_soc_update" fuer dieses Vehicle setzen wuerde? Damit waere das Abfrageinterval wieder egal und die Werte wuerden spaetestens eine Iteration spaeter im Theme/Status ankommen.

[miradarya]

Hab heute morgen von einer älteren 2.1.8er alpha/master auf die Beta 1 aktualisiert. Ich musste für beide Autos die Ziellade-Pläne neu anlegen: Ich hatte bzw. habe jeweils einen Sommer- und einen Winter-Plan mit unterschiedlichem Ziel-SOC. Das Verhalten war nach dem Update zunächst so, dass beim (De-)Aktivieren eines Plans (z.B. Sommer) alle Pläne gleichzeitig (de-)aktiviert wurden. Beim Löschen der Pläne ist mir dann aufgefallen, dass im Benachrichtigungbereich mit der Glocke für alle Pläne dieselbe ID angegeben wurde. Nach dem Neu-Anlegen der Pläne haben jetzt alle eine individuelle ID und es funktioniert wieder wie gewünscht.

Ansonsten funktioniert bisher alles einwandfrei, das neue Koala-Theme gefällt mir sehr gut! Ein großes Lob an das Team für die vielen Verbesserungen und Neuerungen in der 2.1.8!

Dein letzter Beitrag war vom 7.7., da habe ich mal diese Version genommen. Ich konnte das Problem bei mir nicht beobachten.
Hast Du irgendwann mal einen Downgrade gemacht? Hast Du sonst weitere Infos?

Oh, da könntest du recht haben... Bin mir nicht 100%-ig sicher, aber ich meine, dass ich ein Downgrade von einer etwas späteren Alpha gemacht hatte. Ich glaube, wegen der vorübergehenden SolarEdge-Problematik?

Falls es relevant ist, hätte ich ein Backup von vor dem Update auf die Beta 1. Aber da sind dann halt Zugangsdaten usw. drin... Logs hatte ich nicht gespeichert, nach dem Löschen und Neu-Anlegen der Pläne ging ja alles wieder.

[LenaK]

Zu dem Punkt
Maximale Ausgangsleistung des WR: Liefert ein WR mehr als seine max konfigurierte Ausgangsleistung wird diese Leistung von der Speicherleistung, die im Algorithmus zur Verfügung steht, abgezogen. Unabhängig davon, ob der Speicher als Hybrid-Speicher oder eigenständiger Speicher konfiguriert ist.

Geht das auch bei MQTT Wechselrichtern und Speichern ?

ja, wenn die neuen openWB/set/mqtt/pv... Topics genutzt werden.

Ja habe ich in Verwendung .
Muss ich dann den MQTT Speicher in den Wechselrichter ziehen ?
Wenn ja dann zählt er mit Ladung zur PV dazu .

Nein, das funktioniert auch ohne Hybrid-WR.

[LenaK]

Rueckfrage zu https://github.com/openWB/openwb-ui-set ... 086aaae02b (Ausbau eines Hinweistextes im MQTT-SOC-Modul):

Waere es vielleicht eine Idee, wenn jedes Auswerten von "openWB/set/mqtt/vehicle/id/get/..." implizit "openWB/mqtt/vehicle/id/get/force_soc_update" fuer dieses Vehicle setzen wuerde? Damit waere das Abfrageinterval wieder egal und die Werte wuerden spaetestens eine Iteration spaeter im Theme/Status ankommen.

Für die SoC-Abfrage sind feste Interalle vorgesehen. Wenn Du "openWB/set/mqtt/vehicle/id/get/..." gepublished hast, kannst Du ja auch noch ein "openWB/mqtt/vehicle/id/get/force_soc_update" publishen und damit die SoC-Aktualisierung anstoßen.

[LenaK]

Hab heute morgen von einer älteren 2.1.8er alpha/master auf die Beta 1 aktualisiert. Ich musste für beide Autos die Ziellade-Pläne neu anlegen: Ich hatte bzw. habe jeweils einen Sommer- und einen Winter-Plan mit unterschiedlichem Ziel-SOC. Das Verhalten war nach dem Update zunächst so, dass beim (De-)Aktivieren eines Plans (z.B. Sommer) alle Pläne gleichzeitig (de-)aktiviert wurden. Beim Löschen der Pläne ist mir dann aufgefallen, dass im Benachrichtigungbereich mit der Glocke für alle Pläne dieselbe ID angegeben wurde. Nach dem Neu-Anlegen der Pläne haben jetzt alle eine individuelle ID und es funktioniert wieder wie gewünscht.

Ansonsten funktioniert bisher alles einwandfrei, das neue Koala-Theme gefällt mir sehr gut! Ein großes Lob an das Team für die vielen Verbesserungen und Neuerungen in der 2.1.8!

Dein letzter Beitrag war vom 7.7., da habe ich mal diese Version genommen. Ich konnte das Problem bei mir nicht beobachten.
Hast Du irgendwann mal einen Downgrade gemacht? Hast Du sonst weitere Infos?

Oh, da könntest du recht haben... Bin mir nicht 100%-ig sicher, aber ich meine, dass ich ein Downgrade von einer etwas späteren Alpha gemacht hatte. Ich glaube, wegen der vorübergehenden SolarEdge-Problematik?

Falls es relevant ist, hätte ich ein Backup von vor dem Update auf die Beta 1. Aber da sind dann halt Zugangsdaten usw. drin... Logs hatte ich nicht gespeichert, nach dem Löschen und Neu-Anlegen der Pläne ging ja alles wieder.

Ich gehe stark davon aus, dass das durch das Downgrade verursacht wurde. In der Alpha wurde die Struktur der Pläne im Backend geändert.

[fawick]

Für die SoC-Abfrage sind feste Interalle vorgesehen. Wenn Du "openWB/set/mqtt/vehicle/id/get/..." gepublished hast, kannst Du ja auch noch ein "openWB/mqtt/vehicle/id/get/force_soc_update" publishen und damit die SoC-Aktualisierung anstoßen.

Guter Vorschlag, so mach ich das, danke! Sollte ich dann aber besser openWB/set/mqtt/vehicle/id/get/force_soc_update nehmen (inkl. `/set`)?

[LenaK]

Für die SoC-Abfrage sind feste Interalle vorgesehen. Wenn Du "openWB/set/mqtt/vehicle/id/get/..." gepublished hast, kannst Du ja auch noch ein "openWB/mqtt/vehicle/id/get/force_soc_update" publishen und damit die SoC-Aktualisierung anstoßen.

Guter Vorschlag, so mach ich das, danke! Sollte ich dann aber besser openWB/set/mqtt/vehicle/id/get/force_soc_update nehmen (inkl. `/set`)?

Ja, unbedingt. Hatte ich übersehen.

[mattberlin]

Dieses Verhalten führt dann dazu, dass bspw. nach Verstreichen der Pufferzeit, ein kurzer Sonnenschein (so lang wie die Wartezeit Ladestart) ausreichend ist um von 1p auf 3p zu schalten, oder?

Ja. Das konnte ich bei mir auch schon beobachten, weil die Wartezeit Ladestart bei mir 30s beträgt.

Ich bin mir noch nicht sicher, ob ich das positiv oder eher negativ empfinde (bezogen auf die vorherige/alte Regelung). Ich tendiere zu letztem, da bei Wolken zwar die Ladung trotz wechselnder Leistung recht flott gestartet, aber eben auch ebenso flott auf 3p hochgeschaltet wird - und dann aber relativ lange auf dem hohen Level gehalten wird, was bei mir zu deutlich mehr Bezug aus dem Hausakku führt. Und der wird gleichzeitig langsamer nachgeladen, weil das Auto mit der Regelung mehr abbekommt.

Also, diese Umstellung ist auf jeden Fall negativ!!!

Eine gewisse Pufferzeit, in der definitiv keine Umschaltung stattfinden soll (z.B. 15 min), ist wirklich sinnvoll.
ABER: Ist die Pufferzeit abgelaufen und dann scheint für die kurze Dauer der Wartezeit (z.B. 30 s) mal kurz die Sonne, dann wird direkt auf 3p gewechselt. Dann fällt der Überschuss z.B. wieder auf 1,5 kW ab und die WB ballert die nächsten 15 min mit 4,2 kW weiter, so dass fast 3 kW aus der Hausbatterie entnommen werden.
Neben einer optionalen Pufferzeit MUSS für eine Phasenumschaltung auf 3p IMMER erfüllt sein, dass eine bestimmte Zeit t genug Überschuss vorhanden ist. Und diese bestimmt Zeit ist sicher nicht die Zeit, die man sinnvollerweise als Wartezeit definiert?
Zudem macht eine Asymmetrie Sinn: Das heißt die Umschaltung zu 3p müssen die Bedingungen länger erfüllt sein als für eine Rückschaltung auf 1p.

Wer kommt denn auf diese Umsetzung? Was sind die Gründe dafür?

Verärgern tut mich, dass ich dieses Verhalten schon mehrfach in der Alpha-Phase kritisiert habe, wobei es keine Beachtung fand, und es nun trotzdem in der Beta gelandet ist.

[Elchkopp]

Ich kenne diese Regelung von EVCC und fand die Regelung von openWB immer besser. Das einzige Manko war eben der starre Rahmen (Summe musste immer 16 Minuten ergeben). Gerade jetzt wo Min+PV als Button/eigener Modus entfallen ist, finde ich das auch sehr unglücklich, denn eigentlich muss man jetzt die Zeit zum Ladestart hochsetzen, um nicht zu schnell auf 3p zu kommen. Bei wolkigem Wetter und schwacher Last startet er dann aber nicht. Möchte man jetzt einfach nur das Auto sanft mitlaufen lassen, um ungenutzten Überschuss einzufangen ohne den Hausakku zu sehr zu belasten, bräuchte ich jetzt Min+PV - aber als Button und nicht umständlich als Schieberegler, damit es dann auch Familientauglich wäre.

[Gero]

Das mit dem runtersetzen der Einschaltverzägerung fur eine bessere Min+PV-Unterstützung ist ja auch eher ein Workaround. Ich hatte statt dessen ja mal ein Häkchen neben „Mindeststrom“ vorgeschlagen, welches den Mindeststrom nur startet, wenn auch eine gewisse Menge PV-Überschuss da ist. Das ist aber irgendwie noch nichts geworden.

Eins noch zur Einschaltverzögerung: ich bin da der Meinung, dass dieser Zähler immer mitlaufen sollte, also auch wenn kein Auto eingesteckt ist. Mit fällt das immer auf, wenn ich bei praller Sonne mein Auto einstecke und dann erst mal analysiert wird, ob die Sonne auch scheint. Da muss meiner Meinung nach ohne Verzögerung losgeladen werden.

Ich bin auch der Meinung, dass diese Einschaltverzögerung nicht in der Phasenumschalutung berücksichtigt werden sollte. Das ist einfach eine andere Baustelle und da nochmal eine Zeitspanne zur Entscheidungsfindung einzubauen, macht die ganze Sache nur unübersichtlich. Was spricht denn dagegen, zwei Zeiten einstellbar zu machen? Einmal eine für‘s rauf- und eine für‘s runterschalten? Gerne auch mit Mindestwerten, danit man sich kein Klackerkonzert fehlkonfigurieren kann. Denn Leute mit kleinem Speicher möchten den sicherlich anders schonen, als solche mit großen.