SoC-Berechnung wenn Online-Abfrage zu alt

[rleidner]

Ich habe zum Test im MQTT-SoC-Modul eine Erweiterung eingebaut, die den fehlenden externen soc_timestamp simuliert:

Das Modul merkt sich in jedem Durchlauf den aktuellen soc und soc_timestamp als previous.*.
Wenn previous.* nicht existiert werden soc und soc_timestamp auf 0 gesetzt.
soc und soc_timestamp sind die aus dem mqtt-Ast.
Wenn "soc_timestamp is None or (soc_timestamp == previous.soc_timestamp and soc != previous.soc)" wird soc_timestamp auf den aktuellen timestamp gesetzt, in den mqtt-Ast geschrieben und soc und soc_timestamp als previous.* gemerkt.

D.h. wenn sich soc_timestamp nicht ändert aber der soc schon wird soc_timestamp auf die aktuelle Zeit gesetzt und im mqtt-Ast eine externe Versorgung simuliert. Auch mit einer (lückenhaften) externen Versorgung des soc_timestamp sollte das klarkommen. Es gewinnt immer die externe Versorgung.

Das funktioniert hier im Test, ist aber erst mal ein "Proof of Concept" und "quick and dirty".
Das mqtt-Modul wird offiziell von openWB gepflegt, daher ist es fraglich ob es Aussicht auf Erfolg haben würde.
Es wäre m.E. immer sinnvoller, soc_timestamp von der externen Quelle versorgen zu lassen.

[Ihaglc]

Kleiner Verbesserungsvorschlag/Anmerkung:
Wenn die OWB für den SOC 100% anzeigt, wird z.Z. der Range eingefroren und nicht weiter berechnet, obwohl das Auto noch nicht 100% erreicht hat und weiter lädt, also eine höhere Reichweite erreicht. ( die Ladeenergie hingegen wird weiter aktualisiert )

Vorschlag zur besseren Nachjustierung auf die realen Autodaten:
auch SOC Werte in der openWB höher 100% zulassen, so kann man besser Eingabewerte von Ladeverlusten und Kapazität anpassen, damit das Auto selbst und die openWB gleichzeitig 100% SOC anzeigen.

[rleidner]

Kleiner Verbesserungsvorschlag/Anmerkung:
Wenn die OWB für den SOC 100% anzeigt, wird z.Z. der Range eingefroren und nicht weiter berechnet, obwohl das Auto noch nicht 100% erreicht hat und weiter lädt, also eine höhere Reichweite erreicht. ( die Ladeenergie hingegen wird weiter aktualisiert )

Vorschlag zur besseren Nachjustierung auf die realen Autodaten:
auch SOC Werte in der openWB höher 100% zulassen, so kann man besser Eingabewerte von Ladeverlusten und Kapazität anpassen, damit das Auto selbst und die openWB gleichzeitig 100% SOC anzeigen.

Danke für den Vorschlag.
AFAIK lässt die openWB generell keinen SoC > 100% zu - macht ja "real" auch keinen Sinn.
Ich würde die "Angaben zur Batterie" im Fahrzeugprofil entsprechend anpassen.
Kapazität und Wirkungsgrad zur Anpassung des berechneten SoC.
Durchschnittsverbrauch zur Anpassung der berechneten Reichweite.

[zut]

Ich merke auch, wie die Akkukapazität im Winter sinkt (oder der Ladewirkungsgrad steigt, evt durch weniger Kühlpumpen): wenn es warm ist, steigt der SoC langsamer als berechnet, in der Kälte schneller.
Ich glaube es ist halbwegs sinnfrei, das letzte % bei der Berechnung herausholen zu wollen.

[ChristophR]

Hallo rleidner,

ich konnte jetzt ein paar mal den Ausfall des Cupra Online SoC beobachten.
Dabei ist mir folgendes aufgefallen:
Die berechnete Reichweite führt dazu, dass in der Übersicht des Ladepunkts eine negative Reichweite für die Ladung ausgewiesen wird.
Das stört mich nicht weiter, die Reichweite müsste aus meiner Sicht nicht unbedingt berechnet werden, das ist ja nur eine grobe Schätzung.

Was mir aber noch aufgefallen ist:
Wenn man unter Status -> Fahrzeug sich den SoC anschaut, wird dort im Normalfall stets der Timestamp des letzten erfolgreichem Abrufs von den Servern angezeigt.
Wenn dann die Server keine Lust mehr zum Antworten haben, wird an dieser Stelle der Timestamp des letzten Durchlaufs angezeigt, man sieht also leider nicht mehr, wann der letzte erfolgreiche Abruf war.
Es wird dann in der Meldung auch angezeigt, dass innerhalb der letzten x Minuten der SoC nicht abgerufen werden konnte, wenn man dies mit dem angezeigten Zeitstempel vergleicht, stimmt das natürlich nicht.
Ich vermute mal, dass dies technisch nicht anders geht, da sonst die Berechnung nicht erfolgreich durchgeführt werden kann?
Es wäre eigentlich ganz nett, wenn man dort sehen würde, wann der Abruf das letzte Mal erfolgreich war.

[rleidner]

Die berechnete Reichweite führt dazu, dass in der Übersicht des Ladepunkts eine negative Reichweite für die Ladung ausgewiesen wird.
Das stört mich nicht weiter, die Reichweite müsste aus meiner Sicht nicht unbedingt berechnet werden, das ist ja nur eine grobe Schätzung.

Ja, die berechnete Reichweite ist "nice-to-have", aber ich finde es besser als gar keine Info.
Wenn ich das richtig verstehe, wird die geladene Reichweite negativ angezeigt? Das habe ich bisher nicht beobachtet.
Das sollte eigentlich von der berechneten Reichweite nicht beeinflusst sein.
Ich schau mal bei Gelegenheit ob ich das reproduzieren kann.

Was mir aber noch aufgefallen ist:
Wenn man unter Status -> Fahrzeug sich den SoC anschaut, wird dort im Normalfall stets der Timestamp des letzten erfolgreichem Abrufs von den Servern angezeigt.
Wenn dann die Server keine Lust mehr zum Antworten haben, wird an dieser Stelle der Timestamp des letzten Durchlaufs angezeigt, man sieht also leider nicht mehr, wann der letzte erfolgreiche Abruf war.
Es wird dann in der Meldung auch angezeigt, dass innerhalb der letzten x Minuten der SoC nicht abgerufen werden konnte, wenn man dies mit dem angezeigten Zeitstempel vergleicht, stimmt das natürlich nicht.
Ich vermute mal, dass dies technisch nicht anders geht, da sonst die Berechnung nicht erfolgreich durchgeführt werden kann?
Es wäre eigentlich ganz nett, wenn man dort sehen würde, wann der Abruf das letzte Mal erfolgreich war.

Guter Vorschlag; ich muss mal sehen wie ich den Zeitstempel des letzten erfolgreichen Abrufs ohne allzu großen Aufwand zusätzlich speichern kann. Dann könnte man den in der Statusmeldung anzeigen.
Ansonsten könnte man in den SoC-Log (Level Info) sehen; da sollte man das finden können.

[ChristophR]

Die berechnete Reichweite führt dazu, dass in der Übersicht des Ladepunkts eine negative Reichweite für die Ladung ausgewiesen wird.
Das stört mich nicht weiter, die Reichweite müsste aus meiner Sicht nicht unbedingt berechnet werden, das ist ja nur eine grobe Schätzung.

Ja, die berechnete Reichweite ist "nice-to-have", aber ich finde es besser als gar keine Info.
Wenn ich das richtig verstehe, wird die geladene Reichweite negativ angezeigt? Das habe ich bisher nicht beobachtet.
Das sollte eigentlich von der berechneten Reichweite nicht beeinflusst sein.
Ich schau mal bei Gelegenheit ob ich das reproduzieren kann.

Wenn Du dazu Logfiles gebrauchen kannst, welche würden helfen? Von gestern müsste ich noch welche "finden".
P.S: Es ist nicht immer negativ, wir also vermutlich nicht zu ändern sein, wenn der letzte Verbrauch nicht gleich dem Durchschnittsverbrauch ist.

Guter Vorschlag; ich muss mal sehen wie ich den Zeitstempel des letzten erfolgreichen Abrufs ohne allzu großen Aufwand zusätzlich speichern kann. Dann könnte man den in der Statusmeldung anzeigen.
Ansonsten könnte man in den SoC-Log (Level Info) sehen; da sollte man das finden können.

Im SoC Log steht es, daher bin ich überhaupt darauf gekommen, wie es zustande kam.
Danke für Deine Mühe.

[rleidner]

Wenn Du dazu Logfiles gebrauchen kannst, welche würden helfen? Von gestern müsste ich noch welche "finden".

Ich bin nicht sicher ob das aktuell in einem Log zu sehen ist.
Was helfen würde wäre ein Screenshot so einer Situation.