openWB Forum

Häufig gibt es eine "Nachlaufzeit", bis das EV einschläft. Beim i3 habe da ein paar Min. gemessen (Ist schon länger her - glaube um die 10min).

Dennoch habe ich einen SoC-Abfrageintervall von 5min drin, weil dieses EV vermutlich keine großen Verbraucher aktiviert, wenn nur die Kommunikation läuft.
Auch hat BWM eine Nachladung des 12V-Akkus sichergestellt. Das Teil ist etwas größer als eine Motoradbatterie und hält bereits 6 Jahre.

Wenn man auch die ganzen anderen 12V-Kia-Probleme liest, deutet das auf Konstruktionsfehler bei der Behandlung des 12V-Akkus hin. Das ist insofern schade, da die Autos neu sind und "leerer 12V-Akku" wahrlich kein unbekanntes Problem aus der Frühzeit der EV ist.

Hallo, beim Kona ist mir das auch schon passiert, dass die 12V Batterie leer war, nachdem das Auto ein paar Tage kaum gefahren wurde und ich per openWB alle 15 Minuten den SOC angefragt habe. Ich habe dann den Minuspol abgeklemmt und die 12V Batterie mit einem externen Ladegerät nachgeladen. Alles wieder ok danach. Wenn man ein 12V Ladegerät hat, kann man sich den Werkstattbesuch wohl sparen.

Jede Abfrage weckt das Auto auf mit entsprechender Belastung der 12V Batterie bis es wieder einschläft. Auf ein paar Tage Schlafentzug würde ich auch sehr ungelaunt reagieren.

Abhilfe wird sein, das Abfrageintervall nicht dauerhaft auf 15 Minuten oder weniger zu haben. Ich nutze das SoC Modul jetzt jedenfalls nur noch homöopathisch.

Kleines Update von mir:
In den letzten zwei Wochen gab es keine Probleme mehr bei mir. Das SoC-Abfrage-Intervall habe ich inzwischen wieder etwas heruntergesetzt auf 90 Minuten.
Bei GoingElectric hat da gerade die letzten Tage jemand eine interessante Messung gepostet, nach der der Niro etwa 5 Minuten braucht um wieder einzuschlafen nach einer Abfrage: https://www.goingelectric.de/forum/view ... 0#p1507690
Bei 15 Minuten als Intervall wäre der Niro also 1/3 der Zeit "wach"...

Die selteneren SoC-Abfragen führten allerdings nun leider beim PV-geführten Laden zu dem Problem, dass mein Niro am Wochenende auf 86% statt auf meine konfigurierten 80% aufgeladen wurde.
Das finde ich nun ziemlich schade, da mein Ziel mit der OpenWB ist, dass ich im Alltag meinen Niro einfach immer anstecken kann und mich dann darauf verlassen kann, dass die OpenWB die konfigurierten Grenzen einhält, aber auch nicht meine 12V-Batterie durch unnötige SoC-Abfragen leergesaugt wird.
Daher habe ich etwas überlegt und zwei Vorschläge wie das verbessert werden könnte:

1.) Der SoC könnte anhand der initialen SoC-Abfrage beim Ladestart und der daraufhin geladenen kWh geschätzt werden. Dann müsste OpenWB nicht auf die nächste SoC-Abfrage warten, sondern könnte ggfs. schon früher abschalten.
Aber natürlich ist das relativ grob, da bspw. die Ladeverluste nicht mit einfließen oder geschätzt werden müssen.

2.) Es dürfte doch eigentlich kein Problem sein zwei unterschiedliche SoC-Abfrage-Intervalle konfigurierbar zu machen:
Eines für den Fall, dass gerade geladen wird. Hier könnte der PV-Besitzer mit sensiblem E-Auto 5 Minuten einstellen, damit die Ladegrenzen schnell erkannt werden.
Ein anderes Intervall für den Fall, dass gerade der Stecker eingesteckt ist, aber nicht geladen wird (bspw. PV-geführt in der Nacht). Hier könnte der PV-Besitzer mit sensiblem E-Auto dann eher ein Intervall von ein paar Stunden wählen, damit die 12-V-Batterie nicht leergesaugt wird.
Ggfs. dann noch ein drittes Intervall für den Fall, dass der Stecker gar nicht eingesteckt ist, oder man unterscheidet einfach nur zwischen Laden und nicht Laden.

Wäre die Umsetzung eines dieser Vorschläge denkbar?

Na ja - das Auto verursacht das Problem. oWB kann nichts dafür, dass das EV-Entwicklerteam die Pflege der 12V-Batterie nicht ordentlich sicherstellt. Es gibt OEM, die es deutlich besser machen.

zu 1) - SoC vorher schätzen
Wenn z.B. die Drosselung wegen zu hoher Schieflast einsetzt, müsste das mit beachtet werden. Auch andere Effekte können verfälschen.
M.E. viel zu viel Aufwand und das Resultat bliebe immer noch unbefriedigend.

Den SoC-"Nachlauf" kann man einfacher kompensieren, indem man den SoC etwas niedriger als das Soll einstellt.

Übrigens - es wird immer etwas Nachlauf geben. Hier sind es meist 3% (wenn der Autoserver gewartet wird, geht's auch Mal auf 100%). In 2020 trat das 4x bei BMW auf.
Bis 10% Abweichung (90 statt 80%) ist kein wirkliches Problem. Wenn's stört, stelle 75% ein => +6 = 81%.
Was ich sagen will - SoC ist eine Kenngröße (ohne Berücksichtigung weiterer Herstellersicherheitszuschläge), die man nicht überbewerten sollte (sicher auch nicht unterbewerten).

Der SoC kann bereits nach ein paar Stunden Wartezeit ohne Laden und bei Temp.-schwankungen abweichen.

VG

@jss
Wenn ich Dich richtig verstanden habe, ist der zweite Punkt in den SoC Modulen für Opel und Peugeot umgesetzt. Dort gibt es das Problem, dass der SoC während der Ladung auf den Servern nicht aktualisiert wird. Es ist jetzt so gelöst, dass zu Beginn der SoC abgerufen wird und während der Ladung die manuelle Berechnung den SoC intern nachführt.

Daraus ergeben sich auch automatisch unterschiedliche Abfrageintervalle während und ohne Ladung.

Vielleicht sollte die Berechnung des SoC während der Ladung optional bei allen Modulen verfügbar sein. Es gibt ja anscheinend viele Anwendungsfälle.

LutzB hat geschrieben: ↑Di Feb 16, 2021 6:15 am Wenn ich Dich richtig verstanden habe, ist der zweite Punkt in den SoC Modulen für Opel und Peugeot umgesetzt.

Danke für den Hinweis. Ich habe mir mal den Code von den SoC Modulen für Opel und Peugeot angeschaut und die scheinen ja tatsächlich genau das zu machen was mein Vorschlag Nummer 1 war.

aiole hat geschrieben: ↑Mo Feb 15, 2021 10:22 pm Na ja - das Auto verursacht das Problem. oWB kann nichts dafür, dass das EV-Entwicklerteam die Pflege der 12V-Batterie nicht ordentlich sicherstellt. Es gibt OEM, die es deutlich besser machen.

Ja, das ist mir klar, aber es ist weniger Aufwand ein paar Zeilen Code zu ergänzen, als das Auto zu wechseln
Da sich das ja anscheinend auch direkt im SoC Modul umsetzen lässt, könnte man es für besonders betroffene Hersteller umsetzen ohne weiteren Auswirkungen auf andere Nutzer.
Wenn ich mal die Zeit finde, kann ich mir auch vorstellen mich da selber ans Coden für das Kia Modul machen.
Als Besitzer einer normalen OpenWB-Custom werde ich das aber wahrscheinlich nicht wirklich im realen Betrieb testen können, oder gibt es da irgendwie eine Möglichkeit eigenen Code drauf zu bekommen?
Könnte mir nen Raspberry Pi zum Testen aufsetzen, aber die Interaktion mit der OpenWB-Hardware fehlt dann natürlich.

aiole hat geschrieben: ↑Mo Feb 15, 2021 10:22 pm Bis 10% Abweichung (90 statt 80%) ist kein wirkliches Problem. Wenn's stört, stelle 75% ein => +6 = 81%.

Gerade habe ich bei einem Abfrage-Intervall von 90 Minuten Warnungen von der UVO-App bekommen, dass die Spannung der 12-V-Batterie wieder zu niedrig ist. Also müsste ich das Intervall dann doch wieder weiter hochsetzen und dann müsste der Puffer schon deutlich größer sein.
Wenn ich das Intervall auf 2 Stunden setze sind wir im Sommer mit einer 10 kWp PV-Anlage schon bei ca. 25% und bei 3 Stunden schon bei ca. 40%.

aiole hat geschrieben: ↑Mo Feb 15, 2021 10:22 pm Was ich sagen will - SoC ist eine Kenngröße (ohne Berücksichtigung weiterer Herstellersicherheitszuschläge), die man nicht überbewerten sollte (sicher auch nicht unterbewerten).

Da würde ich auch so zustimmen, aber man kann ja trotzdem versuchen rauszuholen was rauszuholen ist

LutzB hat geschrieben: ↑Di Feb 16, 2021 6:15 am Vielleicht sollte die Berechnung des SoC während der Ladung optional bei allen Modulen verfügbar sein. Es gibt ja anscheinend viele Anwendungsfälle.

Ja, ich denke das wäre eine gute Idee. Idealerweise könnte man das man+calc SoC Modul einfach so aufrufen und es berechnet dann weiter. Somit wäre es vermutlich vergleichsweise einfach jedem SoC Modul diese Option zu verpassen ohne den man+cal Code in jedes Modul kopieren zu müssen. Letzteres widerstrebt mir einfach

@jss
Für die Fehlerbekämpfung setzt man am sinnvollsten an der Ursache an. => Auto
Spezielle Bugs wie den "12V-Tod" merkt man meist erst nach dem Kauf. Wenn solche essentiellen Dinge nicht seitens Autohersteller behoben werden (und das ist leider oft der Fall), wäre das für mich ein Grund, das nächste Mal den Hersteller zu wechseln.

OpenWB wird sich mit "Softwarekonstrukten" zur Kompensation unzureichender 12V-Akkuabsicherung zusätzlichen Support an Land ziehen, was nicht im Sinne des Projektes ist. Wir benötigen Autos, die sich an den Ladestandard halten und sich selbst überwachen, statt sich selbst entladen.
=> Kundendruck auf Händler und Hersteller aufbauen. Noch ist das für viele Marktteilnehmer Neuland, weshalb man häufig abgespeist wird. Da gilt es ordentliche "Geschütze" aufzufahren und auch mal einen RA zu bemühen.

zu "genauer SoC":
Nein - es ist eben nicht nötig "rauszuholen, was geht", da der SoC kein knallhartes Akkukriterium ist, wie ich Dir versucht habe, zu erklären.

VG aiole

Ich denke auch dass eine Lösung in openWB schneller geht, als wenn man wartet, bis genug Nutzer beim Fahrzeughersteller geheult haben und der dann auch tatsächlich etwas ändert. Für die Hersteller ist das doch fast ein Einzelfall, im Verhältnis zu den verkauften Mengen der Fahrzeuge. Und der Hersteller des Fahrzeugs kann sich stets damit raus reden, daß eine kontinuierliche Abfrage alle x Minuten des SoC gar nicht vorgesehen ist. Für openWB fallen hingegen alle Fahrer eines Betroffenen Modells als potentielle Kunden /Nutzer raus.

Ich sehe jetzt auch nicht, was das Abfragen des SoC via Hersteller API mit dem Einhalten von Ladestandards zu tun hat.

Wenn, wie hier, ein Nutzer der OpenWB sogar anbietet, selbst Code zur Lösung des Problems beizusteuern, hätte ich erwartet, dass die Entwickler von OpenWB den Nutzer mit offenen Armen willkommen heißen und entsprechend unterstützen.

Stattdessen lese ich leider oft "wird von OpenWB nicht kommen", "sollen die anderen sich erstmal an Standards halten", oder "bei Fahrzeug XY geht's aber, daher ändern wir nix".

Ich dachte bisher, openwb ist genau zur Lösung solcher Probleme das perfekte Produkt. Wenn aber bei jedem Problem einzelner Fahrzeuge/Nutzer derart abweisend reagiert wird, stellt sich die Frage, welchen Mehrwert openWB und vor allem die OpenWB Hardware hat, wenn es letztlich nur mit einer Hand voll Autos "richtig" funktioniert? Da kann man dann ja auch zu einer dummen Wallbox greifen. Oder openWB selbst auf einen RaspberryPi installieren und im Zweifelsfall selbst patchen?

Bitte nicht als persönliche Kritik verstehen, ich wollte nur mal zum Überdenken mancher Ansätze anregen, wo ich doch gerade als Neuling und potentieller Käufer sowie SW Entwickler vor der Entscheidung stehe, welche Wallbox ich kaufe.

Freddi69 hat geschrieben: ↑Di Feb 23, 2021 7:07 pm Wenn, wie hier, ein Nutzer der OpenWB sogar anbietet, selbst Code zur Lösung des Problems beizusteuern, hätte ich erwartet, dass die Entwickler von OpenWB den Nutzer mit offenen Armen willkommen heißen und entsprechend unterstützen.

Aber ist nicht genau das auch der Fall? Der gesamte Code der openWB ist auf GitHub https://github.com/snaptec/openWB dort kann sich jeder einbringen, PRs stellen und somit das Produkt weiter entwickeln. Hab ich selber gemacht, hat wunderbar geklappt und die Anpassungen sind nun im aktuellen Release mit drin.

Freddi69 hat geschrieben: ↑Di Feb 23, 2021 7:07 pm Stattdessen lese ich leider oft "wird von OpenWB nicht kommen", "sollen die anderen sich erstmal an Standards halten", oder "bei Fahrzeug XY geht's aber, daher ändern wir nix".

Hier ist es sicherlich so wie bei jeder Softwareentwicklung, es gibt stets deutlich mehr Probleme, wirklich gute Ideen und Herausforderungen als Zeit und Ressourcen diese auch umzusetzen. So muss permanent priorisiert werden was man mit den zur Verfügung stehenden Kapazitäten am besten angeht. Hier spielt dann auch die Tragweite (z.b. Schweregrad, Anzahl betroffener User und Szenarien und Aufwand einer möglichen Umsetzung, und vieles andere mehr) eine Rolle.