Sessions: close last charging session on restart if open

[ThinkEV]

Describe the bug

Wenn die Wallbox während der Ladung abstürzt, weil die Sicherung rausfliegt, an der auch der evcc hängt, dann führt das dazu, dass in der Datenbank evcc.db nur der Stromzählerstand vom Anfang der Ladung eingetragen wird. Es fehlt dann meter_end_kwh, charged_kwh und solar_percentage usw.

Ich stelle mir vor, dass evcc solche fehlerhaften Einträge im Log (nach dem Start von evcc) sucht und automatisch repariert, indem er die vorherige Ladung in der Datenbank beendet, indem es den aktuellen Zählerstand nachträgt (wenn der Fehler bei der letzten Ladung aufgetreten ist, höchste id in der sessions-Tabelle) als meter_end_kwh und dann auch charged_kwh ergänzt.

Im Prinzip kann es auch ältere Ladungen in der Datenbank ohne meter_end_kwh usw. geben. Ich hatte davon noch ein zweien zweiten unvollständigen Datensatz bei mir. Da müsste man dann für meter_end_kwh den Wert von meter_start_kwh der Folge-id nehmen.

Natürlich gibt es dabei eine sehr geringe Abweichung, aber wenn das zum Neustart nachgetragen wird, sollte man damit sehr gut leben können.

Egal wie es umgesetzt wird, Hauptsache das Ladelog wird nicht unvollständig gelassen.

Steps to reproduce

...

Configuration details

/

Log details

# Ein alter fehlerhafter Eintrag im Log aus Dezember:
> select * from sessions where id=19 or id=20;
19|2022-12-21 22:52:46.407466926+01:00|0001-01-01 00:00:00+00:00|Garage||ZOE|1182.40100097656|0.0|0.0|0.0||||
20|2022-12-22 08:50:39.002141127+01:00|2022-12-22 09:02:38.592301774+01:00|Garage||ZOE|1208.96496582031|1211.64501953125|2.64697265625|19188.83||||

# Ein aktueller fehlerhafter Eintrag von Version 0.118.1
# Die Sicherung ist während der Ladung rausgeflogen!
> select * from sessions where id>=170;
170|2023-07-02 14:00:28.432215708+02:00|0001-01-01 00:00:00+00:00|Garage||ZOE|2806.86889648437||0.0|28725.75||||
171|2023-07-02 15:22:24.982809287+02:00|2023-07-02 16:25:24.969106882+02:00|Garage||ZOE|2833.166015625|2854.46997070312|21.302001953125|28725.75|0.065456354489728|||

What type of operating system are you running?

Linux

Version

0.118.1

[andig]

Alternative: root cause beheben und fehlerhaften Datensatz löschen.

[ThinkEV]

Ich habe den Smiley gesehen...

Dann ist aber der Datensatz zu der Ladung weg. Das wäre schade, weil die Ladung ja stattgefunden hat und die Protokollierung mir wichtig ist.

Ich habe die beiden Datensätze manuell repariert und kann das auch gerne regelmäßig wiederholen, vielleicht sogar ein Skript dafür schreiben, aber schöner wäre es, wenn evcc das selbst könnte, denn so unwahrscheinlich finde ich das Szenario nicht.

Selbst wenn ich den EVCC über eine andere Sicherung betreibe, dann ist beim Stromausfall auf jeden Fall der Stromzähler tot, weil der hinter dem Leitungsschutzschalter der Wallbox in eben jener sitzt. Und dass der Leitungsschutz auslöst, kann ja immer einmal auftreten. Bei meiner ZOE ist das zum Glück erst 2x in 12 Monaten passiert, bei dem Hyundai IONIQ 5 ist das am Ladeende ganz häufig aufgetreten, denn das Auto hat einen Fehler; das Problem haben schon einige bei goingelectric berichtet. Ob und wann der Hersteller es beheben kann und wird - absolut unklar.

Also was haltet ihr von meinem Lösungsvorschlag, den Datensatz bei dem Neustart des evcc (Reboot des Systems nach Rückkehr des Stromes) automatisch zu finalisieren? Was spricht konkret dagegen?

[ThinkEV]

How to repair incomplete charging sessions manually...
Wie man unvollständige Ladesitzungen in der Datenbank manuell reparieren kann...

sudo sqlite3 /var/lib/evcc/evcc.db

# show database schema (for your information only):
sqlite> .fullschema 

#show sessions with no end data:
sqlite> select * from sessions where finished="0001-01-01 00:00:00+00:00";

Your output might look like this:

19|2022-12-21 22:52:46.407466926+01:00|0001-01-01 00:00:00+00:00|Garage||MyCar|1182.40100097656|||0.0|||||
170|2023-07-02 14:00:28.432215708+02:00|0001-01-01 00:00:00+00:00|Garage||MyCar|2806.86889648437|||28725.75|0.0||||
238|2023-09-13 03:45:12.772209573+02:00|0001-01-01 00:00:00+00:00|Garage||MyCar|3332.501953125|||31950.14|||||
259|2023-10-01 14:09:52.824428267+02:00|0001-01-01 00:00:00+00:00|Garage||MyCar|3513.6298828125|||32960.16|||||
262|2023-10-07 00:40:27.396810042+02:00|0001-01-01 00:00:00+00:00|Garage||MyCar|3565.59912109375|||33347.42|||||

Now you need to repair step by step like this: Example for the first ID: Show ID 19 and 20:

select * from sessions where id=19 OR id=20;
19|2022-12-21 22:52:46.407466926+01:00|0001-01-01 00:00:00+00:00|Garage||MyCar|1182.40100097656|||0.0|||||
20|2022-12-22 08:50:39.002141127+01:00|2022-12-22 09:02:38.592301774+01:00|Garage||MyCar|**1208.96496582031**|1211.64501953125|2.64697265625|19188.83|||||

Take the meter_start_kwh value of the next id (20), 1208.96496582031 and add it to id 19:

update sessions set meter_end_kwh = 1208.96496582031 where id=19;
update sessions set charged_kwh = meter_end_kwh - meter_start_kwh where id=19;

Repeat these steps for all sessions with no end data.

If the latest id is incomplete, then you will not get the meter_start_kwh from the next session, because that does not exist yet. Then start a new charging session first and repair it later or read the meter manually by:

sudo systemctl stop evcc
sudo evcc meter
sudo systemctl start evcc

It would be nice, if evcc would repair such incomplete data automatically just after its start.

[GrimmiMeloni]

I'll add missing logic to fix this.
@andig please assign to me

[GrimmiMeloni]

@ThinkEV I have given this a first shot, see #10246

Right now, the PR "only" fixes the history on startup. It does not address if the most recent session is still open. Currently we would still rely on a consecutive session to first be created, and then on next restart it would all fix itself.

Going the extra mile to put code in place that additionally reads the charge meter does not feel like it brings much benefit. The meter value will be the same that is used on next charge start. So the only difference in result would be a different charge stop timestamp. Given we fix the rest of the history in the same way (stop timestamp == start of next charge).

To me this feels "good enough", not sure if others concur.

[ThinkEV]

Thank you very much!

I like your solution from reading your PR, I cannot test it, Ihope its working. :-)