Zielladen trotzdem durchführen obwohl SOC fehlt

[Scusi83]

Moin,
ich bitte euch, dass Zielladen muss trotzdem ausgeführt werden auch wenn keine Soc vorhanden ist. Der Hyundai Soc ist heute oder gestern ausgefallen und es steht eine Error Meldung im Status. Die OpenWB sollte bis 6 Uhr per Tibber auf 60% laden. Jetzt steht er hier mit 9% und meine Freundin muss zur Arbeit. Lieber dann durchladen als nicht zur Arbeit kommen. Das Gleiche sollte er auch machen wenn die Tibber Daten fehlen. Was sicherlich auch ab und zu mal passieren kann.

Vielen Dank

[mrinas]

Hast Du Logs von dem Zustand? Denn eigentlich ist es so das bei mehrfach fehlgeschlagenem SoC dieser auf 0 gesetzt wird um genau solche Szenarien zu verhindern.

Kenne jetzt alle Details und Szenarien nicht, hier könnten die Logs helfen zu verstehen warum nicht geladen wurde.

[aiole]

Moin,
ich bitte euch, dass Zielladen muss trotzdem ausgeführt werden auch wenn keine Soc vorhanden ist. ....

Und ich bitte dich, das hier zu beachten viewtopic.php?t=1526
Versetze dich bitte immer in die Lage der Lesenden. Danke.

[Eckhard]

Hallo zusammen,

wenn ein SoC nicht ermittelt werden kann, darf die openWB nicht einen SoC von Null annehmen. Aus meiner Sicht muss der letzte SoC-Wert solange bestehen bleiben, bis ein neuer, gültiger Wert ermittelt wurde. In allen Fällen (Mindestladestand, Zielladen, etc.) ist das die beste Option.

Ich hatte den Fall, dass die openwb das Laden begonnen hat, weil sie meinte, dass der Minimalladestand unterschritten sei.

Grüße Eckhard

[mrinas]

Hallo zusammen,

wenn ein SoC nicht ermittelt werden kann, darf die openWB nicht einen SoC von Null annehmen. Aus meiner Sicht muss der letzte SoC-Wert solange bestehen bleiben, bis ein neuer, gültiger Wert ermittelt wurde. In allen Fällen (Mindestladestand, Zielladen, etc.) ist das die beste Option.

Ich hatte den Fall, dass die openwb das Laden begonnen hat, weil sie meinte, dass der Minimalladestand unterschritten sei.

Grüße Eckhard

Ich kann durchaus nachvollziehen dass hier der SoC von 0 nach mehreren fehlgeschlagenen SoC Versuchen gesetzt wird. Zu viel laden ist definitiv besser als zu wenig laden. Sonst verlässt man sich auf die Automatik, bekommt nicht mit dass der SoC Abruf irgendwann nicht mehr funktioniert und steht dann am besten früh morgens mit leerem Auto da.
Und womöglich ist es dann auch noch nicht das eigene Auto sondern der des Partners, was dem eigenen Wohlbefinden durchaus abträglich sein kann.

Wird zuviel geladen ist das vielleicht unschön, aber sonst weiter kein Problem.

[Eckhard]

Es ist ein Grundsatz in der IT, niemals Daten zur verfälschen, um einen bestimmten Zweck zu erreichen. Wenn Daten veraltet oder ungültig sind, müssen sie entsprechend gekennzeichnet werden. Dass die Missachtung dieses Grundsatzes ein Fehler ist, zeigt sich sehr schön an den genannten Beispielen: Der eine will, dass sein Auto bei unklarem SoC weiter geladen will (beim Zielladen), der andere nicht (beim PV-Laden mit Minimalladestand).

Ein SoC von Null hat ganz klar eine andere Bedeutung als ein nicht ermittelbarer SoC. Die openWB erfasst richtigerweise den Timestamp der SOC-Ermittlung. Der darf nur gesetzt werden, wenn der SoC erfolgreich ermittelt wurde. Auf Basis des Alters des SoC kann man immer noch definieren, wie mit zu alten Werten zu verfahren ist.

Das gilt übrigens nicht nur für den SoC. Bei allen Daten, die die openWB für ihre Regelung verwendet, muss die Aktualität und Verlässlichkeit der Daten geprüft werden und festgelegt sein, was passiert, wenn dies nicht der Fall ist. Daten als gültig anzusehen, obwohl sie falsch, nicht ermittelbar oder veraltet sind oder einen geschätzten bzw. wegen Datennichtverfügbarkeit festgelegten Wert wie einen aktuellen, richtig ermittelten Wert zu behandeln, ist grob fahrlässig. Das sind Grundsätze der professionellen Datenverarbeitung.

[mrinas]

Ich als IT'ler halte das aktuelle Verhalten als fail-safe. Die gute Nachricht ist dass openWB open source ist und sich jeder gern mit einbringen kann um das weiter zu verbessern.

[Eckhard]

Liebe/r mrinas,

nein, das ist nicht fail-safe. Bei dynamischen Stromtarifen wie Tibber & Co. kann ein unerwünschtes Laden zu erheblichen Kostennachteilen führen, aber auch sonst ist es blöd, wenn ich das Auto eigentlich von der PV laden lassen möchte, es aber bereits nachts aus dem Netz geladen wurde. Genau dafür habe ich doch die openWB. Die Aussage "lieber Laden als nicht Laden" bildet genau einen Anwendungsfall ab.

Natürlich ist es richtig, im Fehlerfall zu entscheiden, wie damit umgegangen werden soll. Aber einfach festzulegen, dass ein nicht ermittelbarer SoC ein SOC von Null bedeutet, ist definitiv falsch. Und mal ehrlich: Der SoC von Null ist der wirklich unwahrscheinlichste Zustand.

Viele Grüße,
Eckhard

[rleidner]

Die openWB erfasst richtigerweise den Timestamp der SOC-Ermittlung.

Soweit ich das sehe ist der Zeitstempel, den die openWB speichert der, an dem das SOC-Modul zum letzten Mal aufgerufen wurde. Das Ergebnis des SOC-Abrufs hat auf den Zeitstempel keinen Einfluss. Auch wenn der SOC-Abruf mit Fehler endet und 0 angenommen wird, wird der Zeitstempel aktualisiert. Die Intervall-Logik der openWB benutzt diesen Zeitstempel um den nächsten SOC-Abruf zu starten.
Nach Deiner Logik müsste man dann erst mal unterscheiden: letzter Abruf vs. letzter erfolgreicher Abruf...

Daneben gäbe es weitere Daten, die man m.E. zusätzlich abbilden sollte.
z.B. der Zeitstempel an dem das Fahrzeug den SOC an den Server des Herstellers gemeldet hat.
Dieser Zeitstempel ist momentan nicht in openwb abgebildet.
In den SOC-Modulen, die ich pflege, schreibe ich diese, sofern vorhanden, in den SOC-Log.
Eine weitere Info wäre z.B. der km-Stand, der im Ladelog brauchbar wäre.

[Eckhard]

Das ist ja dann um so schlimmer: Wozu speichert man einen Timestamp, wenn er nicht mal zu den Daten gehört? Aber grundsätzlich ist das der richtige Ansatz: Der Timestamp ist bei allen Daten vorhanden, man muss ihn nur richtig setzen. Damit kann man dann auch entscheiden, ob man sich auf diese Daten noch verlassen kann.