Rückmeldungen 2.1.8 Release & Release Patch 1

[openWB]

Ist denn der mit Patch 4 angekündigte Fix überhaupt in dieses Release eingeflossen und kann ich irgendwelche Infos liefern um euch bei der Analyse zu unterstützen ?

Logs sind immer hilfreich und unabdingbar zur Analyse! ( viewtopic.php?t=1526 )

[Scusi83]

Nun, das ist eine weitere Auswirkunge der Implementierung: wenn du abgesteckt was am Ladeprofil veränderst, hat das keine Auswirkungen auf die aktiven Einstellungen zum nächsten Einstecken des Autos. Erst beim übernächsten Einstecken (besser: dem Abstecken davor) wird die Änderung übernommen. (Und beim Anstecken wirkt siendann)

Die aktuelle Implementierung ist geschickt von der Programmierungsseite, aber schwer verständlich für den Anwender. Der geht üblicherweise davon aus, dass die letzte Aktivität etwas bewirkt. Also: Anstecken als Aktivität übernimmt die aktuelen Werte aus dem Ladeprofil.

Für den Normalsterblichen wir das immer ein Bug bleiben und unerklärbar sein. Änderungen müssen sofort da sein und bleiben.

Beispiel was wir letzten Samstag hatten. Meine Frau hat ihre OpenWB von PV auf Sofortladen geändert, weil später mein Schwiegervater kommt um zu laden. Wenn ich ihr jetzt erklären müsste warum man zwei mal das Fahrzeug anstecken muss damit das funktioniert würde die mich fragen ob ich noch ganz dicht bin.

[Thomas aus W]

Für den Normalsterblichen wir das immer ein Bug bleiben und unerklärbar sein.

Also ich bin ja auch ein Normalsterblicher und für mich ist das sehr verständlich.

Ja, es ist eine Änderung gegenüber älteren Versionen, aber durchaus sinnvoll.

Meine Frau hat ihre OpenWB von PV auf Sofortladen geändert, weil später mein Schwiegervater kommt um zu laden.

Warum hast Du ihr denn für ihren Vater kein eigenes Fahrzeug- und Ladeprofil eingerichtet, dass sie dann nur noch aktivieren muss, wenn er das Auto an steckt? Und wenn da noch "Standard nach abstecken" aktiviert wäre müsste sie nicht noch mal an der Box rum machen, wenn der Schwiegervater wieder weg ist...

bye
TW

[Frank-H]

Für den Normalsterblichen wir das immer ein Bug bleiben und unerklärbar sein. Änderungen müssen sofort da sein und bleiben.

Beispiel was wir letzten Samstag hatten. Meine Frau hat ihre OpenWB von PV auf Sofortladen geändert, weil später mein Schwiegervater kommt um zu laden. Wenn ich ihr jetzt erklären müsste warum man zwei mal das Fahrzeug anstecken muss damit das funktioniert würde die mich fragen ob ich noch ganz dicht bin.

Wurde wohl gerade geändert: https://github.com/openWB/core/pull/2781

[QuisaZaderak]

Ich bin auch seit der 2.1.8 RC1 von den freezes betroffen. Ich habe jeweils aus RC1, RC2 und zuletzt heute früh aus der Final ein Supportticket erstellt. Es steht immer dort das die notwendigen Daten hochgeladen werden und man die Seite verlassen kann. Ich habe aber nie eine Email/Antwort dazu bekommen und sehe auch in den Logs nirgends ob erfolgreich versendet wurde. Wie kann ich erkennen ob die Box noch in der Lage war das Ticket zu erstellen?

2x openWB Series2 Standard+ mit 2.1.8, EVU MQTT, 2x Vehicle MQTT

[JOGRA]

Für den Normalsterblichen wir das immer ein Bug bleiben und unerklärbar sein. Änderungen müssen sofort da sein und bleiben.

Beispiel was wir letzten Samstag hatten. Meine Frau hat ihre OpenWB von PV auf Sofortladen geändert, weil später mein Schwiegervater kommt um zu laden. Wenn ich ihr jetzt erklären müsste warum man zwei mal das Fahrzeug anstecken muss damit das funktioniert würde die mich fragen ob ich noch ganz dicht bin.

Wurde wohl gerade geändert: https://github.com/openWB/core/pull/2781

Danke Frank-H für die Info, mit 2.1.8 Patch 1 werden beim Speichern von Konfigurationseinstellungen (getestet im Lade-Profil) diese wenigsten dann übernommen, wenn kein Fahrzeug angesteckt ist. Soweit ich spontan noch testen konnte werden allerdings weiterhin keine Konfigurationsänderungen übernommen, wenn das Fahrzeug angesteckt ist. Dies gilt für alle Konfig.-Änderungen PV-, Sofort-, Zeit-, Ziel-Laden, usw.

Und ich muss hier 'Scusi83' zustimmen und leider dem 'Gero' oder 'Thomas aus W' widersprechen, egal ob Normalsterblicher oder Superuser, wenn ich die Konfiguration ändere und speichere sollte diese aktiv sein. Wenn es zu einen Konflikt mit einem aktivem Ladevorgang kommen kann, dann muss dieses Problem anders gelöst werden.

Dass "Änderungen nur mit Abstecken .." übernommen werden wird als Info unterhalb dem Reiter 'Fahrzeug-Profile' angezeigt, nicht aber unter 'Lade-Profil' wie ich inzwischen zufällig 'entdeckt' habe ...

Hintergrund: Ich hatte am 22.9. Update auf 2.1.8 Release gemacht, soweit so gut.
Am 23.9. Fahrzeug angesteckt als ich abends nach Hause kam, wollte später Zeitladen aktivieren und musste feststellen, dass dies nicht mehr funktionierte ... (Hatte seit 2.1.7 fünf Zeit- und zwei Ziel-Profile definiert). Da dachte ich mir, ist beim Update was schief gelaufen. Ich alle Zeit/Ziel Profile gelöscht, dann Fahrzeug abgesteckt, dann OpenWB Neustart über Weboberfläche durchgeführt. Danach 1 Zeit-Lade-Profil neu definiert und Fahrzeug wieder angesteckt - und - die Sch... funktioniert wieder nicht. Absoluter Frust, Puls 180. Fahrzeug um 23 Uhr über Sofortladen noch auf 45% geladen damit ich heute früh 24.9. fahren konnte. Mittags festgestellt, dass das gestern definierte Profil auf der Startseite sichtbar war. Erst dadurch habe ich erkannt, dass vermutlich das Abstecken dafür verantwortlich war. Soweit zu meiner Geschichte, um die Problematik an solchen Änderungen zu verdeutlichen!

[Gero]

Wie kann ich erkennen ob die Box noch in der Lage war das Ticket zu erstellen?

In deinem Email-Postfach der von dir angegebenen Adresse befindet sich eine Mail mit der Ticket-Nummer.

[fedv-mbu]

Hallo zusammen,

da wir Zwangs der Änderung bei Inexogy (Discovergy) die Firmware updaten mussten, sind wir jetzt auch auf der neuen Version.
Wir haben jedoch massive Probleme in unserer SmartHome Anbindung mit ioBroker festgestellt.

Bisher haben wir super zum einstellen der Lademodi damit verfahren, dass wir diese über
mqtt.0.openWB.set.vehicle.template.charge_template.1.chargemode.selected
gesetzt haben.

Das hat sich dann in dem JSON-Block unter mqtt.0.openWB.vehicle.template.charge_template.1 direkt wiedergespiegelt.
Den IST-Zustand des Lademodi haben wir auch dann einfach aus dem JSON rausgezogen mit eigenem JavaScript.

Jedoch ist nun aufgefallen, dass dies nicht mehr greift.

Ich bin leider weder Programmierer noch OpenWB/MQTT SuperUser, vielleicht hat ein anderer ja einen Weg gefunden, das zu steuern...

Wichtig für uns ist, dass wir die Lademodi für die 4 Ladepunkte auch während den Ladevorgängen steuern können, da wir hier mit mehreren Faktoren aus dem ioBroker System entscheiden, welche Autos zu welcher Zeit laden sollen.

Viele Grüße

[Gero]

Dies gilt für alle Konfig.-Änderungen PV-, Sofort-, Zeit-, Ziel-Laden, usw.

Genauer: es gilt für alle Änderungen im Ladeprofil. Diese werden sehr wohl im Ladeprofil gespeichert, haben aber keine Auswirkungen auf die Einstellungen des Ladepunkts.

Und ich muss hier 'Scusi83' zustimmen und leider dem 'Gero' oder 'Thomas aus W' widersprechen, egal ob Normalsterblicher oder Superuser, wenn ich die Konfiguration ändere und speichere sollte diese aktiv sein.

Ich habe mich anfänglich aber zu einem anderen Verhalten negativ geäußert.

Um die Sache noch einmal zu verdeutlichen:

Die (aus dem Ladeprofil kommenden) Einstellungen am Ladepunkt sind nun temporär. Das ist gut, weil so die Konfiguration des Ladeprofils nicht mehr verändert wird. Wird ein Auto neu angesteckt, gelten nun wieder die Einstellungen aus dem Ladeprofil. Nun ist es also möglich, des Sommers PV im Ladeprofil zu haben und wenn man am regnerischen Tag mal auf Sofort (am Ladepunkt) umstellt ist beim nächsten Laden wieder PV (aus dem Ladeprofil) wieder aktiv. Bislang musste man daran denken, wieder auf PV zurückzustellen.

Was nun für ein wenig Aufregung sorgt, ist der Zeitpunkt des Rückstellens der temporäre Werte. Aktuell implementiert ist es beim Abstecken des Autos. Das finde ich für Nutzer nicht so richtig selbsterklärend, ich denke dass der normale Nutzer das übertragen des konfigurierten Ladeprofils auf den Ladepunkt beim Einstecken (und nicht beim Abstecken) erwarten würde.

Wir müssen also genauer hinschauen:

a) Ändert man die Konfiguration des eingesteckten / ladenden Autos: -> soll die Einstellung des Ladepunkts aktualisiert werden? Bei der Antwort "Ja" kann es passieren, dass die Konfigurationsänderung die aktuell laufende Ladung stoppt oder eine neue startet. Je nachdem, was man geändert hat. Bei "Nein" bleibt am Ladepunkt alles so wie es ist und die Änderung der Konfiguration greift beim nächsten Ladevorgang aka Einstecken. Ob man da nun "Ja" oder "Nein" besser findet, ist mir egal. Ich kann mit beidem leben. Logischer fände ich aber die Option "Nein", die die aktuelle Ladesitzung unbehelligt von Konfigurationsänderungen lässt.

b) Ändert man bei abgestecktem Auto die Konfiguration sollte beim nächsten Einstecken - oder auch Auswählen dieses Autos am Ladepunkt - das Ladeprofil auf den Ladepunkt übernommen werden. Das ist aktuell nicht so, die Konfiguration wird beim Abstecken des Autos auf den Ladepunkt übernommen. Das führt zu dem schwer erklärlichen Effekt, dass man um die geänderte Konfiguration in den Ladepunkt zu bekommen mehrfach ab- und anstecken muss. Der Fix adressiert das insofern, als dass nach einer Konfigurationsänderung beim Anstecken die neu konfigurierten Werte übernommen werden sollen. Ich bin gespannt, weil der oben verlinkte PR immer noch "unplugged" im Titel trägt.

edit: Wie ich weiter unten bestätige. ist der Punkt b) nun erledigt. Speichert man bei abgestecktem Auto eine geändertes Ladeprofil, so wird diese Änderung in den Ladepunkt übernommen.

[odoll]

Sorry, wenn ich mich hier als Unqualifizierter [1] einbringe, aber

> Für den Normalsterblichen wir das immer ein Bug bleiben und unerklärbar sein. Änderungen müssen sofort da sein und bleiben.

wäre es nicht ein "Einfaches" zwei Varianten eine "OK" Buttons zu implementieren, a la "Sofort temp aktivieren" "bzw. "Dauerhaft aktiv nach dem nächsten Anstecken"?

Und ein mehr genereller Kommentar zu dem Update Prozess: (Ich meine) früher wären die Namen der verfügbaren Versionen "sprechender" gewesen?
Da ich mir durch das Lesen im Forum durchaus über die Warnung durch ein vorschnelles Update von 2.1.7 evt. auf .8er Beta-Release bewusst war, war es aber immer schwer zu erkennen, ob ein aktuell angebotenes Update denn nun auf .8 führt, oder doch wieder "nur ein harmloser" Patch der .7er Version. Auch jetzt kann ich nicht gleich erkenn, ob das angebotene Release 2.1.8 ist, oder doch wieder nur zb. ein 2.1.7p6!?!
(siehe Anhang, inzwischen weiß ich das ich mir 2.1.8 bzw. 2.1.8p1 "einfangen" würde)

[1] Ich betreibe die openWB2 2.0 seit geraumer Zeit auf einem ausrangierten Raspberry Pi 3 Model B Rev 1.2, allein ohne eine WB, weil ich das http://openwb2/openWB/web/themes/standard_legacy/ angezeigte rollenden MRTG-alike Graphen der Daten unserer SMA PV mit BYD Speicher auf einem ausrangiertem FireTV Tablet im Kiosk-Modus den Anwesenden zur "Mahnung" präsentiere. (Finde ich halt praktischer als die SMA App bzw. das SunnyPortal bzw. ennexOS.