openWB Forum

Ich lasse den SOC über ein OVMS-Modul abfragen, das nur im Hausnetz über WLAN erreichbar ist, wenn das Auto zuhause ist. Das funktioniert auch größtenteils stabil, aber ab und zu kommt es doch mal zu Fehlern bei der Abfrage.

Ich habe eingestellt, dass der SOC nur abgefragt wird, wenn das Auto angesteckt wird, damit gleich losgeladen wird, wenn das Auto angesteckt wird. Wenn aber der SOC in diesem Moment nicht korrekt abgefragt werden kann, oder noch schlimmer, wenn das Modul sich mal aufgehängt hat und gar nicht mehr antwortet, dann kann es passieren, dass das Auto gar nicht lädt. Ich habe als Ladegrenze 80% SOC eingestellt. Wenn der erreicht war, wenn das Auto weggefahren ist und dann beim Wiederkommen die Abfrage nicht funktioniert, geht die OpenWB davon aus, dass weiterhin 80% SOC vorliegen und lädt nicht. Dieses Verhalten finde ich ziemlich unschön, denn ein leeres Auto ist doof. Im Zweifel sollte m.E. lieber die SOC-Grenze nicht eingehalten werden.

Ich hätte also gerne, dass z.B. bei einer fehlerhaften Abfrage einige erneute Versuche gemacht werden und zwar in schnellerem Takt, als die eingestellte Zeit, also z.B. jede Minute. Wenn dann nach z.B. 10 Abfragen immer noch kein Ergebnis zurückgekommen ist, dann sollte m.E. angenommen werden, dass der SOC nicht verfügbar ist und jegliche Grenzen ignoriert werden.

Aus meiner Sicht wäre das für alle SOC-Modul-Varianten das korrekte Verhalten, denn wenn nichts abgefragt werden kann, dann ist es auch nicht sinnvoll, eine Grenze einzuhalten. Dann im Zweifel lieber das EV vollladen.

Gibt es Chancen, dass so etwas in der 1.9 noch implementiert wird oder könnte man es sonst bitte zumindest für die 2.0 entsprechend vorsehen?

Das finde ich persönlich einen sehr guten Vorschlag. Nur… was ich nicht verstehe: Wenn sich das OVMS aufhängt und somit auf dem letzten bekannten SOC hängen bleibt, woher soll die OpenWB denn wissen, dass der rückgemeldete Wert unplausibel ist?

Für den Fall, dass eine Ladung ohne Beachtung des SoC aktiv ist, fände ich auf jedem Fall einen Hinweis auf dem Display / Webinterface wichtig (z.B. durchgestrichene SoC-Anzeige). So kann man das einfach erkennen und ggf. manuell eingreifen.

Nein, die OVMS Box bleibt nie auf dem SOC hängen. Was passieren kann ist, dass sie sich komplett aufhängt oder das WLAN zu schwach ist. Dann bekommt die Openwb keine Antwort mehr (im SOC Modul tritt ein Fehler wegen Zeitüberschreitung auf. Das ungünstige Verhalten ist, dass die Openwb jetzt einfach annimmt, dass der SOC sich nicht geändert hat. Das ist ein ähnliches Problem, wie beim Lastmanagement, wo sie nicht abschaltet, wenn keine Daten mehr vom Wechselrichter kommen.

therobbot hat geschrieben: ↑Sa Jan 22, 2022 2:28 pm Wenn dann nach z.B. 10 Abfragen immer noch kein Ergebnis zurückgekommen ist, dann sollte m.E. angenommen werden, dass der SOC nicht verfügbar ist und jegliche Grenzen ignoriert werden.

Hier wäre ja das einfachste, nach x Fehlern 0% zu liefern? Dann wären automatisch alle Grenzen ignoriert, ohne andere Stellen als die SOC-Module anzupassen.

Wäre ne Möglichkeit schöner wäre so was, wie NaN oder - 1.

Aber was genau sollte dann passieren?
Genau genommen braucht man einen Faultwert der dann angenommen wird.

In der 2.0 kriegen wir das hin.

Naja, im Grunde genommen sollte sich die WB dann so verhalten, als ob kein Modul konfiguriert ist, oder? Da wird ja dann momentan glaube ich auch 0 angezeigt. Stattdessen würde ich auch da so etwas wie NV (nicht verfügbar) anzeigen. Und wenn der SOC mit dem konfigurierten Modul nicht abgefragt werden konnte (und es noch ein paar mal erfolglos versucht wurde), dann wird auch NV angezeigt. Dann wird wieder in den eingestellten Abständen ein Versuch gestartet und wenn wieder eine Antwort kommt, dann kann mit dem SOC wieder gearbeitet werden.

Im Grunde genommen würde es für meine Belange auch einfach erst einmal reichen, wenn der SOC nach dem neu anstecken erst einmal auf 0 gesetzt wird, bis er wieder erfolgreich gelesen wurde. Wenn eingestellt ist, dass der SOC nur gelesen wird, wenn das Auto angesteckt ist, wäre das sowieso aus meiner Sicht ein sinnvolles Verhalten, oder?

openWB hat geschrieben: ↑So Jan 23, 2022 6:32 pm Aber was genau sollte dann passieren?

Ich könnte mir folgendes gut vorstellen:
Fehlgeschlagener SoC wird erstmal ignoriert und mit dem zuletzt bekannten weitergearbeitet. Abfrage noch n-mal wiederholen, ggf. mit erhöhter Frequenz.
Das Verhalten nach dem dauerhaften Fehlschlag sollte m.E. konfigurierbar sein, die einen möchten dann auf 0 setzen im Zweifel einen Ladevorgang zu starten, andere möchten möglicherweise genau das vermeiden und würden es vorhziehen auf dem zuletzt bekannten SoC stehen zu bleiben.

Wobei ja ein verharren auf dem letzten bekannten SOC auch nur einen Ladevorgang vermeiden würde, wenn der letzte bekannte SOC über einer Grenze lag.

Hier könnte ich mir eher noch ein bisschen ein intelligentes Verhalten vorstellen.

Vorschlag: im Fehlerfall wird der SOC auf NV gesetzt. Wird das Auto erst danach angesteckt, dann wird SOC 0 angenommen, denn dann weiß man ja wirklich nichts. Tritt der Fehler im angesteckten Zustand auf, liegt also noch ein letzter zuverlässiger SOC während des aktuellen Ladezustands vor, gibt es 3 konfigurierbare Verhalten:

1. Ohne SOC Begrenzung weiterladen
2. Laden stoppen
3. Fallback auf manuell + Berechnung, ausgehend von dem letzten bekannten SOC.

therobbot hat geschrieben: ↑Mo Jan 24, 2022 5:04 am Wobei ja ein verharren auf dem letzten bekannten SOC auch nur einen Ladevorgang vermeiden würde, wenn der letzte bekannte SOC über einer Grenze lag.

Oder durchladen würde, wenn der Wunsch-SoC noch nicht erreicht wurde .

therobbot hat geschrieben: ↑Mo Jan 24, 2022 5:04 am Hier könnte ich mir eher noch ein bisschen ein intelligentes Verhalten vorstellen.

Vorschlag: im Fehlerfall wird der SOC auf NV gesetzt. Wird das Auto erst danach angesteckt, dann wird SOC 0 angenommen, denn dann weiß man ja wirklich nichts. Tritt der Fehler im angesteckten Zustand auf, liegt also noch ein letzter zuverlässiger SOC während des aktuellen Ladezustands vor, gibt es 3 konfigurierbare Verhalten:

1. Ohne SOC Begrenzung weiterladen
2. Laden stoppen
3. Fallback auf manuell + Berechnung, ausgehend von dem letzten bekannten SOC.

Ganz schön komplex. Vor allem die Detektion im gesteckten Zustand und die Definition, was ein zuverlässiger SoC ist.

Zum Anfang würde ich es daher einfach halten und z.B. bei konfiguriertem SoC + Nichtauslesemöglichkeit eine gut sichtbare Warnmeldung ausgeben.