Auswertung Ladeenergie: minimale Summendifferenz bei Netzbezug

[An-Wi]

Describe the bug

Ich versuche schon eine ganze Weile die Ursache einer ca. 12,7-kWh-Differenz bei mir bei der Summenbildung vom Netzbezug zu finden, die im Vergleich zu den CSV-Daten auftritt.
Die Summenbildung der "Sonne" passte zunächst augenscheinlich, wurde mir aber bei genauerer Analyse der CSV-Datei verständlicher.

Aus mir nicht bekannten Gründen habe ich 3 Einträge in der Ladehistorie, die keine Endzeit und keinen Solar-%-Eintrag aber einen Wert für die geladene Energie besitzen:
23.12.2023 12:39
16.12.2023 10:10
14.10.2023 10:13 (nicht im Screenshot: geladene Energie ist sehr gering)

Diese 3 Einträge werden vermutlich bei der Summenbildung nicht berücksichtigt, wodurch die besagte Differenz bei mir entsteht...

Da das hier "Jammern auf sehr hohem Niveau" ist, habe ich mich bemüht, die Ursache zu finden und daher bis jetzt mit der Meldung gewartet.

Der richtig Umgang mit solchen unvollständigen Datensätzen ist wahrscheinlich "ignorieren", oder?
Frage: Könnte ich das bei mir "heilen", da ich sowohl die fehlende Endzeit als auch die fehlende Solar-% "manuell ermitteln" könnte?

Steps to reproduce

...

Configuration details

-

Log details

-

What type of operating system are you running?

Windows

Version

0.121.0 - 0.126.6

[naltatis]

Danke für die Analyse. Generell gibt es schon einen Prozess, der unvollständige/abgebrochene Einträge bei einem Neustart vervollständigt. Siehe hier

evcc/core/session/db.go

Lines 56 to 81 in b995404

	func (s *DB) ClosePendingSessionsInHistory(chargeMeterTotal float64) error {
	var res Sessions
	if tx := s.db.Find(&res, map[string]interface{}{"finished": "0001-01-01 00:00:00+00:00", "Loadpoint": s.name}); tx.Error != nil {
	return tx.Error
	}
	for _, session := range res {
	var nextSession Session
	var tx *gorm.DB
	if tx = s.db.Limit(1).Order("ID").Find(&nextSession, "ID > ? AND Loadpoint = ?", session.ID, s.name); tx.Error != nil {
	return tx.Error
	}
	if tx.RowsAffected == 0 {
	// no successor, this is the most recent session and it is open
	session.MeterStop = &chargeMeterTotal
	} else {
	session.MeterStop = nextSession.MeterStart
	}
	if session.MeterStart != nil && session.MeterStop != nil {
	session.ChargedEnergy = *session.MeterStop - *session.MeterStart
	s.Persist(session)
	}
	}

Wenn ich das richtig sehe, korrigieren wir hier aber "nur" die Energiemenge und Zählerstände, nicht aber die finished Zeit. Das scheint bei deinen Einträge auch passiert zu sein.

/cc @GrimmiMeloni

[naltatis]

Bzgl. Abweichung Auswertung im UI: Bei den fehlerhaften Einträgen fehlt ja nicht nur die Endzeit, sondern auch Details wie Preis und Sonnenanteil. Demnach würde ich das jetzige Verhalten, unvollständige Einträge zu ignorieren auch als korrekt ansehen. Konsequenterweise sollten wir sie dann auch in der CSV nicht mit exportieren.

Grundproblem ist aus meiner Sicht eher das Speicherverhalten. Wir sollten Werte wie Ladedauer, Sonnenanteil, ... einfach in regelmäßigen Abstände (alle 15min würd ja schon reichen) in die DB schreiben. Dann wären solche Abweichungen, wenn sie denn mal passieren, immer relativ klein und wir könnten die Logik von oben (rückwirkendes Errechnen von Energiemenge) entfernen und beim Neustart einfach alle "Unfinished" Ladevorgänge auf die aktuelle Zeit setzen.

Zur Tragweite: Ich hab mal meine Datenbank überprüft. Dort habe ich knapp 1000 Einträge. Davon ist in diesem Jahr einer ohne Endzeit. Im letzten Jahr waren es vier. Aber das hängt natürlich auch vom technischen Setup und den genutzten Geräten ab.

[An-Wi]

Bzgl. Abweichung Auswertung im UI: Bei den fehlerhaften Einträgen fehlt ja nicht nur die Endzeit, sondern auch Details wie Preis und Sonnenanteil. Demnach würde ich das jetzige Verhalten, unvollständige Einträge zu ignorieren auch als korrekt ansehen. Konsequenterweise sollten wir sie dann auch in der CSV nicht mit exportieren.

Das würde ich nicht machen, da somit u. U. größere "Lücken" im Zählerstand auftreten. Die Energie ist nun mal "geflossen" und sollte auch irgendwie gezählt, gespeichert und exportiert werden...

Grundproblem ist aus meiner Sicht eher das Speicherverhalten. Wir sollten Werte wie Ladedauer, Sonnenanteil, ... einfach in regelmäßigen Abstände (alle 15min würd ja schon reichen) in die DB schreiben. Dann wären solche Abweichungen, wenn sie denn mal passieren, immer relativ klein und wir könnten die Logik von oben (rückwirkendes Errechnen von Energiemenge) entfernen und beim Neustart einfach alle "Unfinished" Ladevorgänge auf die aktuelle Zeit setzen.

Ok, ich dachte, dass wurde bereits irgendwann in letzter Zeit implementiert? Hatte mal ein Issue im Februar dazu verfasst, als mir 53 kWh Ladeenergie verloren gingen: #12253. Danach hatte ich keine Probleme mehr an dieser Stelle (oder die Konstellation kam nicht nochmal genauso vor).
Gestern hab ich mehrfach im "laufenden Ladevorgang" evcc neu starten lassen (über UI mit zeitverzögertem Autostart durch Aufgabenplanung). Dabei sind tatsächlich "kleinere" Lücken im Zählerstand entstanden, aber die Aufzeichnungen sind bis zum "Klick auf Neustart" vollständig.
Meldet sich das System auf diesem Weg noch "sauber ab" und schreibt den Ladevorgang in die Datenbank zurück?

Zur Tragweite: Ich hab mal meine Datenbank überprüft. Dort habe ich knapp 1000 Einträge. Davon ist in diesem Jahr einer ohne Endzeit. Im letzten Jahr waren es vier. Aber das hängt natürlich auch vom technischen Setup und den genutzten Geräten ab.

Bei mir war glücklicherweise Dezember letztes Jahr der letzte Eintrag ohne Endzeit.

[naltatis]

Meldet sich das System auf diesem Weg noch "sauber ab" und schreibt den Ladevorgang in die Datenbank zurück?

Ja. Nur wenn du hart den Stecker ziehst, geht was verloren. Neustart via UI oder OS schreibt vorher noch in die DB.

[naltatis]

Bei mir war glücklicherweise Dezember letztes Jahr der letzte Eintrag ohne Endzeit.

Ah gut. Ich hatte nicht genau aufs Datum geschaut. Vielleicht haben wir dann auch kein wirkliches Problem mehr.

[StefanSchoof]

Mit 0.121.3 wurde Session log: close unfinished sessions on startup. Das ist vom Release ist vom 28.10.23. Je nachdem wann das Update auf die Version gemacht wurde, kann das der Fix gewesen sein.

[GrimmiMeloni]

Wenn ich das richtig sehe, korrigieren wir hier aber "nur" die Energiemenge und Zählerstände, nicht aber die finished Zeit. Das scheint bei deinen Einträge auch passiert zu sein.

Ja, guter Punkt. Wir haben uns damals in der Diskussion primär auf die Energiewerte konzentriert.

Mir scheint als wäre das hier aber bereits geklärt, bzw. wenn überhaupt sind die fehlenden Endstände nicht das Problem? Oder ist in der Sache jetzt doch noch was zu tun (z.B. das Schließen von offenen Sessions beim Start um einen Endzeitpunkt erweitern)?

[naltatis]

Ich würde sagen, wir haben hier aktuell kein (relevantes/akutes) Problem. Gerade, weil die Unstimmigkeiten vor dem Fix waren.
Daher würd ich vorschlagen, es erstmal beim Status quo zu belassen und das Issue zu schließen.

[An-Wi]

Wenn der Fix bereits von 28.10.23 war und ich noch 2 Einträge mit fehlende Endzeiten in Dezember 23 hatte, dann könnte nach wie vor das Problem bestehen, denn ich spiele immer zeitnah (innerhalb 1-2 Tagen) die Updates ein. Möglicherweise kann aber auch ein weiteres Fix nach Dez. 2023 das Problem endgültig behoben haben... von dieser Seite sehe ich hier zunächst keinen Handlungsbedarf.

Zu meiner 2. Frage nochmal: Wie kann ich die DB manuell nachbearbeiten und die 3 Problemfälle bei mir händisch korrigieren?

[An-Wi]

Issue auch aus meiner Sicht abgeschlossen. Behalte es trotzdem im Auge und melde mich, falls erneut unvollständige Einträge auftauchen sollten.

Meine DB konnte ich Dank "DB Browser for SQLite" nun korrigieren - meine Abweichungen sind somit nicht mehr existent.
Danke euch für den schnellen Support.