SoC-Berechnung wenn Online-Abfrage zu alt

[zut]

Ich habe wohl reproduzierbar ein Problem mit dem MQTT-Modul und der Berechnung des Ladezustandes:

Der berechnete SoC wird wieder zurückgesetzt, wenn ein Phasenwechsel oder Ladeende erfolgt. Dies führt zu einer Ladung über den Ziel-SoC hinaus, da nach Ladeende der SoC vom Beginn der Ladung wieder eingetragen wird:

Bildschirmfoto_20260326_121752.png (161.65 KiB) 92 mal betrachtet

Phasenumschaltung ist gegen 12 Uhr, dabei springt der SoC von berechneten ~43% wieder auf die 38% vom Beginn der ladung.

[rleidner]

Ich habe wohl reproduzierbar ein Problem mit dem MQTT-Modul und der Berechnung des Ladezustandes:

Der berechnete SoC wird wieder zurückgesetzt, wenn ein Phasenwechsel oder Ladeende erfolgt. Dies führt zu einer Ladung über den Ziel-SoC hinaus, da nach Ladeende der SoC vom Beginn der Ladung wieder eingetragen wird:

Bildschirmfoto_20260326_121752.png

Phasenumschaltung ist gegen 12 Uhr, dabei springt der SoC von berechneten ~43% wieder auf die 38% vom Beginn der ladung.

Was steht im SoC-Log (Level Info)?
Kannst Du mit MQTT-Explorer unter openWB/mqtt/vehicle/<vehicle-id>/get nachsehen? Dort sollten bis zu 4 topics sein: soc, range, soc_timestamp, odometer.
Das MQTT-SOC-Modul funktioniert in 2 Stufen:
1) Externes System schreibt die Werte in die o.g. topics - siehe auch die Doku auf der Einstellungsseite
2) Das Modul fragt in den konfigurierten Intervallen die Daten aus den o.g. topics ab und schreibt diese als CarState in die topics openWB/vehicle/<vehicle-id>/get/...
Mit diesen Informationen können wir hoffentlich feststellen, was da passiert und warum.

[zut]

Was steht im SoC-Log (Level Info)?
Kannst Du mit MQTT-Explorer unter openWB/mqtt/vehicle/<vehicle-id>/get nachsehen? Dort sollten bis zu 4 topics sein: soc, range, soc_timestamp, odometer.
Das MQTT-SOC-Modul funktioniert in 2 Stufen:
1) Externes System schreibt die Werte in die o.g. topics - siehe auch die Doku auf der Einstellungsseite
2) Das Modul fragt in den konfigurierten Intervallen die Daten aus den o.g. topics ab und schreibt diese als CarState in die topics openWB/vehicle/<vehicle-id>/get/...
Mit diesen Informationen können wir hoffentlich feststellen, was da passiert und warum.

Ich muss den nächsten Ladevorgang abwarten um mit Loglevel Info ein Log zu bekommen.

Die Topics für soc und odometer kommen unter openWB/mqtt/vehicle/<vehicle-id>/get/ an:

Bildschirmfoto_20260326_165227-1.png (113.92 KiB) 68 mal betrachtet

Da diese Werte nur einmal beschrieben werden, bleiben sie während der Ladung unverändert. Muss ich ein timestamp mit ablegen, damit die Werte als alt erkannt werden? Wenn ja - wäre es nicht möglich, den timestamp automatisch zu generieren aus dem Zeitpunkt, an dem die Werte im set-Zweig geschrieben werden?

[zut]

Eben nochmal auf Sofortladen gestartet. Der SoC von 79,6 wurde übertragen und abgelegt:

Bildschirmfoto_20260326_170736-1.png (15.31 KiB) 58 mal betrachtet

Die Ladung startete mit 39% und rechnete langsam hoch (40% habe ich gesehen.
Unter openWB/vehicle/1/get/soc kamen die 79,53% nicht an, dort stand 39, dann 40%
Nach Beenden der Ladung wurden die 79,53% dorthin übertragen.

Im SoC-Log steht:

Code: Alles auswählen

2026-03-26 16:55:18,591 - {modules.common.fault_state:46} - {ERROR:fetch soc_ev3} - MQTT: FaultState FaultStateLevel.ERROR, FaultStr <class 'Exception'> ("Der SoC kann nicht ausgelesen werden: 'NoneType' object has no attribute 'odometer'. Die Berechnung vom letzten bekannten Soc ist nicht möglich, weil kein Fahrzeug eingesteckt ist.",), Traceback: 
Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 132, in _get_carstate_by_source
    _odometer = _carState.odometer
AttributeError: 'NoneType' object has no attribute 'odometer'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 82, in update
    car_state = self._get_carstate_by_source(vehicle_update_data, source)
  File "/var/www/html/openWB/packages/modules/common/configurable_vehicle.py", line 175, in _get_carstate_by_source
    raise Exception(f"Der SoC kann nicht ausgelesen werden: {e}. {_txt1}{reason}")
Exception: Der SoC kann nicht ausgelesen werden: 'NoneType' object has no attribute 'odometer'. Die Berechnung vom letzten bekannten Soc ist nicht möglich, weil kein Fahrzeug eingesteckt ist.

2026-03-26 17:03:41,423 - {modules.common.store._api:31} - {INFO:store soc_ev1} - Saving CarState(soc=39.22309000000078, range=89, soc_timestamp=1774541021.344467, odometer=None)
2026-03-26 17:04:41,718 - {modules.common.store._api:31} - {INFO:store soc_ev1} - Saving CarState(soc=39.38184999999916, range=90, soc_timestamp=1774541081.661977, odometer=None)

(Die Meldung von 16:55 Uhr entstand, nachdem ich die bis dahin laufende Ladung gestoppt hatte. Fahrzeug wurde nicht abgesteckt.)
Softwareversion ist 2026-03-25 13:58:08 +0100 [f3983a443]

[zut]

Ich rate:

Bei Ladungsende oder Unterbrechung (Phasenumschaltung) wird der Inhalt von openWB/mqtt/vehicle/1/get/soc auf openWB/vehicle/1/get/soc kopiert. Das würde erklären, warum der am Anfang per MQTT geschriebene SoC-Wert immer wieder auf den Startwert gesetzt wird, wenn die Ladung endet oder unterbrochen wird.

[rleidner]

OK, als soc_timestamp im carstate wurde die aktuelle Zeit genommen, das ist default:
1774540083.28 = Donnerstag, 26. März 2026 um 16:48:03.280 GMT+01:00

Das Problem wird sein, dass der alte soc in openWB/mqtt/vehicle/id/get/soc immer wieder mit dem dann wieder aktuellen Zeitstempel als aktueller interpretiert wird als der berechnete...
Meine Tests mit MQTT-Quelle, die soc_timestamp setzt haben sauber funktioniert.
Ich habe aber noch keine wirklich gute Idee, wie das ohne soc_timestamp zuverlässig gelöst werden kann.
Man müsste die Ergebnisse der Berechnung im MQTT-SoC-Modul verfügbar machen und berücksichtigen...

Am einfachsten wäre es, wenn die MQTT-Quelle einen zuverlässigen Zeitstempel liefern könnte.
Die Autos haben die aktuelle Zeit ja verfügbar, das sollte doch über die OBD-Schnittstelle auch abfragbar sein, alternativ über wifi von einem timeserver.

[zut]

Dann werde ich den SoC-Helpeer mal entsprechend ergänzen und sehen was passiert.

Dass ein Fahrzeug die aktuelle Uhrzeit auf einem Messkanal der OBD2-Bichse ausgibt halte ich für nicht wahrscheinlich. Die Lesegeräte kennen die Uhrzeit in der Regel selber.

Kann man nicht beim Auslesen des set-Topics den Zeitstempel durch die Wallbox setzen? Wenn danach ein Timestamp gestzt wird, kann man ja den übernehmen.

[ChristophR]

Ich verstehe das Problem ehrlich gesagt nicht ganz. Wenn wir keinen timestamp senden, gibt es den nicht:
openWB/mqtt/vehicle/<id>/get/soc_timestamp

Das führt dazu, dass der timestamp unter:
openWB/vehicle/<id>/get/soc_timestamp
In jedem Zyklus vom MQTT-Modul neu gesetzt wird und es nur eine geringfügige Abweichung gibt zu diesem Wert:
openWB/vehicle/<id>/get/soc_request_timestamp
Daher erfolgt nie eine Berechnung, da der SOC auch nie zu alt werden kann.

Wenn ein timestamp gesendet wird unter:
openWB/set/mqtt/vehicle/<id>/get/soc_timestamp
landet er zunächst unter:
openWB/mqtt/vehicle/<id>/get/soc_timestamp
Im nächsten Zyklus wird dieser dann hierher geschrieben:
openWB/vehicle/<id>/get/soc_timestamp
Dieser kann nun älter werden als:
openWB/vehicle/<id>/get/soc_request_timestamp
Da er nicht automatisch aktualisiert wird, wenn nicht ein neuer Wert oben geschrieben wird.
Erst dann kann eine Berechnung erfolgen.

Nach meinem Verständnis hätte es bei Dir gar keine Berechnung geben dürfen, wenn Du keinen timestamp sendest.

P.S.: Oder hast Du die Option "während der Ladung berechnen" aktiviert? Die hat aber mit dieser Umsetzung hier nichts zu tun.