Änderung des Verhaltens bei SOC-Abfragefehler

Auflistung von gewünschten Features, Ausschreibung zur Umsetzung
therobbot
Beiträge: 256
Registriert: So Mai 16, 2021 6:09 pm

Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von therobbot »

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?
Stevie_AN
Beiträge: 301
Registriert: Di Jan 19, 2021 11:04 am

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von Stevie_AN »

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.
LP1: OpenWB-custom 1p3p; LP2: go-eCharger HOMEfix; PV1: 7,150 kWp Sunny Tripower 7000TL-20, PV2: 4,440 kWp SB 4000TL-20, Sunny Home Manager 2.0; Škoda Citigo e iV, Smart ED3
therobbot
Beiträge: 256
Registriert: So Mai 16, 2021 6:09 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von therobbot »

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.
philipp123
Beiträge: 1032
Registriert: Mi Jul 21, 2021 3:00 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von philipp123 »

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.
LP1: openWB series2 custom mit Phasenumschaltung
LP2: go-e V2
Kostal Plenticore Plus
e-up BJ 2021, SOC mit OVMS
EQB 250 BJ 2023, SOC mit Mercedes ME über Home Assistant
EVU mit Tasmato-Lesekopf auf SmartMeter
9 x Smarthome mit Shellys
therobbot
Beiträge: 256
Registriert: So Mai 16, 2021 6:09 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von therobbot »

Wäre ne Möglichkeit schöner wäre so was, wie NaN oder - 1.
openWB
Site Admin
Beiträge: 7905
Registriert: So Okt 07, 2018 1:50 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von openWB »

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

In der 2.0 kriegen wir das hin.
Supportanfragen bitte NICHT per PN stellen.
Hardwareprobleme bitte über die Funktion Debug Daten senden mitteilen oder per Mail an support@openwb.de
therobbot
Beiträge: 256
Registriert: So Mai 16, 2021 6:09 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von therobbot »

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?
Benutzeravatar
mrinas
Beiträge: 1867
Registriert: Mi Jan 29, 2020 10:12 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von mrinas »

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.
15,2kWp SMA (SB4000TL-21, SB3.0, STP6.0-SE + BYD HVS, EnergyMeter), openWB Standard+, openWB Pro, Peugeot e2008, Tesla Model Y LR.
therobbot
Beiträge: 256
Registriert: So Mai 16, 2021 6:09 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von therobbot »

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.
aiole
Beiträge: 6779
Registriert: Mo Okt 08, 2018 4:51 pm

Re: Änderung des Verhaltens bei SOC-Abfragefehler

Beitrag von aiole »

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 :mrgreen: .
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.
Antworten