andig
commented
1 year ago Und worin besteht das Problem?
Closed droerich closed 1 year ago
andig
commented
1 year ago Und worin besteht das Problem?
droerich
commented
1 year ago Das Problem besteht im Verlust der Daten über die insgesamt bezogene Energie aus dem Netzt und aus der PV-Anlage in der Größenordnung von mehreren Dutzend kW. Die in der Datenbank gespeicherten Werte von savings.gridCharged und savings.selfConsumptionCharged entsprechen einem Stand, der mutmaßlich mehrere Wochen alt ist (genau konnte ich es nicht herausfinden) und nicht den Werten, die zuletzt, also vor dem harten Abschalten, auf der UI angezeigt wurden. Ich hätte erwartet, dass diese Werte regelmäßig in die Datenbank persistiert werden. So verstehe ich im Übrigen auch den Code: Update(..) wird regelmäßig aufgerufen und aktualisiert sowohl die UI als auch die entsprechenden Daten in der Datenbank. Da das bei mir aber offensichtlich nicht so funktioniert hat, gehe ich von einem Bug aus.
andig
commented
1 year ago Dann brauchts ein trace log für db um das nachvollziehen zu können.
droerich
commented
1 year ago Kann man das Log-Level für einzelne Komponenten individuell einstellen?
andig
commented
1 year ago Ja, siehe levels
droerich
commented
1 year ago Ich konnte das Verhalten gerade mit 0.118.10 reproduzieren.
Vor hartem Abschalten auf Web-UI
Nach Neustart auf Web-UI
Leider noch keine Tracing-Logs für die DB, denn dazu hätte ich meine Konfig ändern und evcc neu starten müssen, was das Experiment verfälscht hätte durch das reguläre Beenden von evcc.
andig
commented
1 year ago Was ist denn "reguläres" Beenden im Vergleich? In jedem Fall brauchts mal logs von regulär und dem Fehlerfall zum Vergleich.
droerich
commented
1 year ago Mit regulärem Beenden meine ich ein systemctl stop evcc sprich ein SIGTERM an evcc.
Ich habe jetzt trace-Logs für DB aktiviert und werde das Experiment wiederholen, sobald ein neuer Ladevorgang hinzugekommen ist.
andig
commented
1 year ago Wir behandeln die eigentlich alle gleich:
// catch signals
go func() {
signalC := make(chan os.Signal, 1)
signal.Notify(signalC, os.Interrupt, syscall.SIGTERM)
<-signalC // wait for signal
once.Do(func() { close(stopC) }) // signal loop to end
}()Beendest Du es vllt. per SIGKILL?
droerich
commented
1 year ago Der Fehler tritt auf, wenn ich das Gerät, auf dem evcc läuft, hart abschalte, indem ich die Stromversorgung trenne.
andig
commented
1 year ago In dem Fall... mache ich hier zu- denn darauf kann keine SW der Welt reagieren.
droerich
commented
1 year ago Das kann ich nicht nachvollziehen. Es geht hier ja nicht um Daten aus den letzten Sekunden vor dem Abschalten, sondern um Daten aus einem Zeitraum von mehreren Wochen. Daten aus solchen Zeiträumen kann man ja wohl persistieren ohne dass sie bei einem Stromausfall verlorgengehen. Klappt ja übrigens mit den Ladevorgängen in der sessions-Datenbank auch, die in meinem Fall erhalten blieben -- trotz Trennung der Stromversorgung.
andig
commented
1 year ago Klick. Jetzt hab ichs verstanden.
droerich
commented
1 year ago Ich habe den Fehler mit trace-Level-Log für DB reproduziert
Hier die Logs: evcc.log.gz
droerich
commented
1 year ago Heute habe ich evcc zum Vergleich nochmal regulär heruntergefahren (systemctl stop evcc)
systemctl stop evcc am 26.7.23 ca. 22:26Logs (Trace-Level für DB): evcc-230726.log.gz
andig
commented
1 year ago Und?
droerich
commented
1 year ago Und die letzten Logs, die ich gepostet habe, sind nutzlos, weil durch einen Fehler von mir die Datenbank für evcc nicht schreibbar war. Muss das Experiment wiederholen.
andig
commented
1 year ago Ich muss es auch nochmal wiederholen: hartes Abschalten ist kein Case, auf den wir optimieren wollen...
droerich
commented
1 year ago Zwischen Optimierung für einen Edge-Case und Berücksichtigung eines Edge-Cases gibt es ja auch eine gewissen Bandbreite. Plötzliches Abschalten/Stromausfälle sind eine Realität von Embedded Devices, die eine robuste Anwendung meiner Meinung nach berücksichtigen sollte.
Ich mache diese Auswertungen, weil ich euch dabei helfen will, die App zu verbessern. Wenn daran kein Interesse besteht, akzeptiere ich das natürlich. Dann behalte ich halt im Hinterkopf, dass man evcc immer sauber runterfahren muss, um solche Datenverluste zu vermeiden. Aber sagt es mir halt bitte, damit ich hier keine Arbeit für die Tonne mache.
naltatis
commented
1 year ago @droerich danke für die Analyse. Ich bin da total bei dir. Wir sollten alle zu persistierenden Daten in regelmäßigen Abständen (bspw. alle 30min) auch wirklich auf die Platte schreiben. Stromausfall und Stecker-Ziehen beim Raspberry sind in der Praxis nicht vermeidbar.
RTTTC
commented
1 year ago I have also lost some data, noticed that my total solar energy % went down after a power outage. It was slowly going up the last few months, as there is plenty of sun. (97% Solar for July, but was pretty bad during winter months.) Good catch and good effort @droerich ! 😎
PeterPablo
commented
1 year ago Let me describe a related use case / issue: Currently, ongoing charging sessions are not persisted (written to the database) as long as the sessions is has not ended. For the main use case of a car charging, this is typically not an issue as it only takes some hours. In contrary to that my use case has several load points instantiated to record the energy consumption of apartments (with their actual price due to PV being available). Recently, there was a house wide power outage due to a service technician. This led to instantaneous power loss of the Raspberry Pi and consequently evcc did not end the sessions properly and write the data. Thus, several days of power consumption of the apartments were not logged at all.
Possible solution: Also write the ongoing charging sessions with an interval (e.g. 30mins) to the database by updating the last session's entry.
There was recently a similar request, which did not yet get much attention: https://github.com/evcc-io/evcc/issues/8788 The root cause is the same.
ignazhabibi
commented
1 year ago Ich habe das gleiche Problem auch schon mehrfach erlebt. Schade wenn die Statistiken dann mehrere Wochen alt sind, weil man den Raspi mal vom Strom trennen musste.
Passiert übrigens auch wenn man einen Home Assistant Restore macht und da evcc Add-on verwendet. Dies aber nur am Rande.
Describe the bug
I cut the power of the device (Raspi) evcc is running. After restarting the device and thus evcc the values of database keys
savings.gridChargedandsavings.selfConsumptionChargedare smaller than before the shutdown. As far as I can tell, no loading sessions in the recent past are missing in thesessionsdatabase though.Steps to reproduce
I don't know if this always reproduces the described behavior.
Configuration details
Log details
What type of operating system are you running?
Linux
Version
0.118.1