Database settings can't be deleted or overwritten from yaml

[KanteTaete]

Describe the bug

If - for Mercedes vehicles - the tokens are re-created and stored in the yaml configuration file, then the respective data in the database can't be overwritten by the data from the yaml file (e.g. by evcc migrate --reset and evcc migrate again).
If the data shall be entered via the UI config, then this is not accepted due to "invalid token".

Steps to reproduce

All steps executed as sudo to prevent access permission problems:

1. Stop evcc service: sudo systemctl stop evcc.service
2. Reset database: sudo evcc migrate --reset
3. Re-generate tokens: sudo evcc token [Mercedes_EQA250]
4. Re-migrate from yaml: sudo evcc migrate
5. restart evcc service: sudo systemctl start evcc.service

Configuration details

Only respective vehicles section:

vehicles:
- name: Mercedes_EQA250
  title: Mercedes EQA250
  type: template
  template: mercedes
  capacity: 66 # battery capacity kWh
  user: <email-address>
  region: EMEA
  accesstoken: ....
  refreshtoken: 23qH...
  phases: 3
  mode: PV
  minCurrent: 6
  maxCurrent: 16

Log details

[main  ] INFO 2024/12/08 19:36:09 evcc 0.131.8
[main  ] INFO 2024/12/08 19:36:09 using config file: /etc/evcc.yaml
[db    ] INFO 2024/12/08 19:36:09 using sqlite database: /root/.evcc/evcc.db
[db    ] TRACE 2024/12/08 19:36:09 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="settings" -1 <nil>
[db    ] TRACE 2024/12/08 19:36:09 SELECT sql FROM sqlite_master WHERE type IN ("table","index") AND tbl_name = "settings" AND sql IS NOT NULL order by type = "table" desc 1 <nil>
[db    ] TRACE 2024/12/08 19:36:09 SELECT * FROM `settings` LIMIT 1 -1 <nil>
[db    ] TRACE 2024/12/08 19:36:09 SELECT * FROM `settings` 35 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="devices" -1 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="device_details" -1 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="configs" -1 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT sql FROM sqlite_master WHERE type IN ("table","index") AND tbl_name = "configs" AND sql IS NOT NULL order by type = "table" desc 1 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT * FROM `configs` LIMIT 1 -1 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="config_details" -1 <nil>
[db    ] TRACE 2024/12/08 19:36:10 SELECT count(*) FROM sqlite_master WHERE type='table' AND name="config_details" -1 <nil>
[main  ] INFO 2024/12/08 19:36:10 listening at :7070
[db    ] TRACE 2024/12/08 19:36:10 SELECT * FROM `configs` WHERE `configs`.`class` = 2 0 <nil>
...
[db    ] TRACE 2024/12/08 19:36:11 SELECT * FROM `configs` WHERE `configs`.`class` = 1 0 <nil>
...
[db    ] TRACE 2024/12/08 19:36:11 SELECT * FROM `configs` WHERE `configs`.`class` = 3 0 <nil>
[mercedes] DEBUG 2024/12/08 19:36:11 identity.NewIdentity - database token found
[mercedes] DEBUG 2024/12/08 19:36:11 identity.NewIdentity - refreshToken started
[mercedes] TRACE 2024/12/08 19:36:11 POST https://id.mercedes-benz.com/as/token.oauth2
[mercedes] TRACE 2024/12/08 19:36:11 grant_type=refresh_token&refresh_token=VM2N...B0
--
{"error_description":"unknown, invalid, or expired refresh token","error":"invalid_grant"}
[main  ] ERROR 2024/12/08 19:36:11 creating vehicle Mercedes_EQA250 failed: cannot create vehicle type 'template': cannot create vehicle type 'mercedes': token expired

What type of operating system are you running?

Linux

Nightly build

• I have verified that the issue is reproducible with the latest nightly build

Version

0.131.8

[KanteTaete]

Refer also discussion #17610

[naltatis]

@KanteTaete Du hast das Fahrzeug nur über yaml konfiguriert, nicht über Config UI angelegt, korrekt?

Hintergrund: Der evcc migrate Befehl macht aktuell (noch) nichts mit Fahrzeugdaten. Aktuell migriert er nur die geräteunabhängigen Einstellungen aus der evcc.yaml. Daher ist das aktuelle Verhalten erst mal erwartungskonform. Perspektivisch wird das migrate Kommande aber auch Fahrzeuge, Zähler, Ladepunkte und Charger mit migrieren.

Zum eigentlichen Problem: @andig das klingt, als ob die Fahrzeugimplementierung beim Wechsel des Tokens in der YAML nicht korrekt mit einem existierenden Wert in der Datenbank umgeht. Das ist unabhängig von Config UI. Falls das nicht automatisch erkennbar ist, könnten wir auch ein dediziertes Token-Reset Kommando einführen. Schöner wäre natürlich ohne.

[KanteTaete]

Das kann ich aktuell leider nicht 100% sicher beantworten.
Soweit ich mich erinnere, hatte ich das Fahrzeug mal in der yaml deaktiviert und in der UI konfiguriert.

Dies würde auch erklären, wenn in der DB schon ein Fahrzeug vorhanden ist, da dort ja - wenn migrate nix einträgt - sonst auch nichts vorhanden sein dürfte, oder?

Bei der Fahrzeug-Konfiguration über UI scheint es aber allgemein noch Probleme zu geben (bei Mercedes). Wenn ich (ohne dass ein Fzg in der yaml konfiguriert ist) dort die neuen Tokens eintragen möchte, kann ich das nicht speichern wegen "expired token". Der gleiche Token in der yaml funktioniert aber.

[andig]

Ich kann zu Mercedes nichts sagen.

[andig]

Das geht so einfach nicht da yaml Daten und migrierte DB Daten nix mit dem Problem zu tun haben. Das Mercedes „Runtime“ Token steht in der settings Tabelle, nicht in config. Daher muss es- um es zu überschreiben- mit

evcc settings

gelöscht werden.

[andig]

Erstmal müsste man im Detail verstehen was hier schief läuft. Eigentlich (tm) sollte das schon so sein. Vielleicht könnte @ReneNulschDE einen Blick drauf werfen.

[KanteTaete]

Was bekomme ich denn mit evcc settings get? Die Konfig aus der yaml oder der DB?
Ich hab's jetzt mal bei funktionierender Konfig ausgeführt. Da werden die "richtigen" Tokens aufgelistet, die in der yaml stehen.

Ich könnte jetzt natürlich auf die alte DB wechseln und das erneut ausführen, um zu sehen, was da reportet wird... falls das weiter hilft.

Die DB über sqlite3 auslesen hab ich ohne längeres einlesen nicht hinbekommen. Ich kann zwar etwas sql aber die DBlite nutzt wohl(?) etwas andere Befehle...

[KanteTaete]

Hab's eben mit der defekten DB nochmals ausgeführt.
Da wird das aktuelle access token (Vergleich der ersten paas Stellen), aber das alte refresh token ausgegeben. Das refresh token wird als abgelaufen angegeben.

[ReneNulschDE]

Die Komponente nutzt immer die Token aus der DB. Ablauf:

Bei Erstinstallation:
Die Komponente sucht Token in DB. Findet keinen und nutzt den Refreshtoken aus der yaml um einen neuen Token zu erhalten und schreibt diesen in die DB. Der Token in der yaml ist damit auch sofort ungültig.

Beim nächsten Start:
Die Komponente sucht Token in DB. Findet einen und nutzt diesen es sei denn der Token ist abgelaufen. Dann wird ein neuer geholt und in der DB gespeichert.

Wenn der Token defekt ist:

1. Stoppe evcc
2. Starte evcc settings get -c [pfad_zu_config]/evcc.yaml
3. Suche den Eintrag mercedes_[email]_[region].
4. Lösche den Eintrag mit evcc settings set mercedes_[email]_[region] "" -c [pfad_zu_config]/evcc.yaml
5. Erstelle einen neuen Token mit evcc token [car_name]
6. Füge den neuen Token in die yaml
7. Starte evcc

[email], [region], [pfad_zu_config], [car_name] sind Platzhalter und müssen basierend auf deiner Installation angepasst werden.

Nutzt bitte meinen Nutzernamen in Fragen zu der Komponente. Dann werde ich informiert. Ich lese hier sonst nicht mit.

[naltatis]

Aber wenn ich @KanteTaete richtig verstanden habe, war sein DB-Token abgelaufen und wurde nicht automatisch ersetzt. Klingt also als ob es da noch ein Problem gibt. Oder verstehe ich das falsch?

[ReneNulschDE]

Ein generelles Problem würde ich ausschliessen. Dafür ist es zu ruhig. Mir fallen folgende Szenarien ein:

1. Es wird ein DB Backup erstellt. Nachdem Backup läuft nochmal der Token ab und wird refreshed. Dann wird das "alte" Backup wird eingespielt.
2. evcc wird auch von der Kommandozeile gestartet. Wenn dies passiert, währen der Token abläuft, wird von dem Kommandozeilen der Token aktualisiert und in der DB bei Prozessende persistiert. Der laufende service-prozess persistiert bei Ende oder nach 1min den alten settings-store in die DB.
3. evcc bricht aus welchem Grund nach einem token-refresh aber vor der Persistierung des settings-store hard ab (das Fenster ist glaube 1min). Es gibt meines Wissens nach keine Funktion, dass eine Komponente das Speichern anfordern kann. (gab mal ein issue dazu im Mai/Juni)
4. (Sehr, sehr selten): Ich hatte 2-3 Fälle in den letzten 4 Jahren wo dass von der MB-API gelieferte Token Material ungültig war. Hier hilf nur neuen Token manuell erstellen, da kein valides Tokenmaterial verfügbar ist.

Mögliche generelles Feature: Eine Komponente kann eine "Reset"-Methode haben. Wenn die vorhanden ist, gibt es im Frontend einen Reset Button und einen command-line option. Die Methode kann dann eine Bereinung ausführen um das evcc settings set ... zu vermeiden.

Was man eventuell auch noch machen könnte. Wenn ein DB-Token da ist, dieser aber ungültig ist, wird nochmal versucht mit dem yaml token einen neuen abzurufen.

[naltatis]

Ok, danke für die Erklärung. Das heißt, eigentlich sollte das bei einem Austausch des Tokens in der Konfigurationsdatei (aus welchem Grund auch immer) keine Probleme machen bzw. sich selbst aktualisieren.

Falls das doch irgendwo nicht funktionieren sollte, bräuchten wir nen konkreten Fall, mit dem man das nachstellen/reproduzieren kann.

[KanteTaete]

Da ich die "fehlerhafte" db noch verfügbar habe, könnte ich versuchen, das Problem ochmals genauer einzugrenzen.
Dazu bräuchte ich aber weitere Infos von Euch, was ich nacheinander tun soll.

...allerdings habe ich dabei das Problem, dass ich die nächsten Tage geschäftlich außer Haus bin und somit vermutlich erst am Wochenende wieder intensiver testen kann.

[KanteTaete]

Ich habe jetzt nochmals mit der defekten DB etwas probiert.
Meine Vermutung war, dass ein (über UI) in der DB korrekt konfiguriertes Fahrzeug über das UI dort auch wieder gelöscht werden können müsste.
Das wäre für den normalen User dann auch eine Möglichkeit, das Problem zu beheben.

Deshalb habe ich - unter Verwendung der defekten DB - das Fzg in der yaml auskommentiert.
Beim Start von evcc kommt der Hinweis bzgl. fehlerhaftem lp - das angemeckerte Fahrzeug gibt mir ein evcc settings get aber aus:

jwtSecretKey: [...] lp1.limitSoc: 0 lp1.maxCurrent: 16 lp1.minCurrent: 6 lp1.mode: pv lp1.phasesConfigured: 3 lp1.planEnergy: 0 lp1.planTime: 0001-01-01T00:00:00Z lp1.smartCostLimit: mercedes.[... Benutzername Mercedes-Account ...]-EMEA: {"access_token":"[...]token_type":"Bearer","refresh_token":"[..]","expiry":"2024-12-01T22:28:01.032140165+01:00","expires_in":14399} [...] vehicle.0.minSoc: 0 vehicle.0.targetEnergy: 0 vehicle.0.targetSoc: 80 vehicle.0.targetTime: 0001-01-01T00:00:00Z vehicle.Mercedes_EQA250.limitSoc: 80 vehicle.Mercedes_EQA250.planSoc: 80 vehicle.Mercedes_EQA250.planTime: 2024-12-02T05:30:00Z

Was mich nochnstutzig macht ist, dass hinter dem refresh token ein "expiry" steht, das in der Vergangenheit liegt, aber danach ein "expires_in" >0 folgt.
Bezieht sich das expiry etwa auf den refresh token und das expires_in auf den access token?

In der UI Konfig wird mir nun aber überhaupt kein Fzg dargestellt - und somit kann ich dann natürlich auch keines über UI löschen...

Ich hoffe, dass Euch das weiter hilft.
Falls ich noch was tun kann, bitte melden.

[naltatis]

Beim Start von evcc kommt der Hinweis bzgl. fehlerhaftem lp

Was für einen Fehler bekommst du da genau?

[KanteTaete]

Fehler lautet:
[main ] FATAL 2024/12/15 10:31:09 failed configuring loadpoints: failed configuring loadpoint: not found: Mercedes_EQA250

Hier nochmals der Ausschnitt aus der yaml:

loadpoints:
- title: Garage
  charger: [...]
  vehicle: Mercedes_EQA250

#vehicles:
#- name: Mercedes_EQA250

Über evcc settings get erhalte ich folgende Fahrzeuge:

vehicle.0.minSoc:                 0
vehicle.0.targetEnergy:           0
vehicle.0.targetSoc:              80
vehicle.0.targetTime:             0001-01-01T00:00:00Z
vehicle.Mercedes_EQA250.limitSoc: 80
vehicle.Mercedes_EQA250.planSoc:  80
vehicle.Mercedes_EQA250.planTime: 2024-12-02T05:30:00Z

In der UI wird mir unter "Fahrzeuge" aber kein Fahrzeug angezeigt.

[PeterPablo]

Wir haben hier mit Version 0.131.11 ein Problem mit einem Mercedes, den wir erst jüngst versucht haben überhaupt einzubinden.
Das Problem scheint meiner Analyse nach zu sein, dass die Token-Anfrage nicht mit dem refreshToken (Nummer 2) des evcc.yaml erfolgt, sondern mit dem ursürnglichen refreshToken (Nummer 1). Das konnte ich nachvollziehen, da ich in der Konsole auch noch den ursprünglichen Token sah und es tatsächlich dieser ist, der verwendet wird. Auszug Log (trace) von eben:

[mercedes] DEBUG 2024/12/15 11:42:15 identity.NewIdentity - database token found
[mercedes] DEBUG 2024/12/15 11:42:15 identity.NewIdentity - refreshToken started
[mercedes] TRACE 2024/12/15 11:42:15 POST https://id.mercedes-benz.com/as/token.oauth2
[mercedes] TRACE 2024/12/15 11:42:15 grant_type=refresh_token&refresh_token=CGRmVojtGb3eVVfslb8Go3L1IaFD9QcrCuh.blabla -- {"error_description":"unknown, invalid, or expired refresh token","error":"invalid_grant"}
[main ] ERROR 2024/12/15 11:42:15 creating vehicle Mercedes-EQV failed: cannot create vehicle type 'template': cannot create vehicle type 'mercedes': token expired

Wir haben bisher zumindest nicht bewusst auf die Verwaltung von evcc mit Datenbank migriert. In der Weboberfläche kann ich das Fahrzeug auch nicht bearbeiten, da es dort heißt, dass es per yaml konfiguriert wird.

"Verschärft" wird die Situation dadurch, dass wir evcc als HassIO laufen lassen und ich daher mit meinem jüngst erlernten Docker-foo mich in das laufende Image einklinken musste, um dort überhaupt evcc token Mercedes-EQV ausführen zu können.

Langer Rede kurzer Sinn:
Wie kann ich ein neu erzeugtes refreshtoken zur Übernahme nach evcc bringen?

Der Befehl evcc settings get hat mich nicht weiter gebracht:

/config # evcc settings get
[main  ] INFO 2024/12/15 11:52:42 evcc 0.131.11
[main  ] INFO 2024/12/15 11:52:42 using config file: /config/evcc.yaml
[db    ] INFO 2024/12/15 11:52:42 using sqlite database: /root/.evcc/evcc.db

Würde hier mehr stehen, falls in der Datenbank Inhalt wäre?
Leer ist sie nicht, aber mit vi kann ich die sqlite-Datenbank nicht sinnvoll ansehen:
-rw-r--r-- 1 root root 12288 Dec 15 11:46 evcc.db
In diesem Docker-Image habe ich nicht sonderlich viele Helferlein zur Verfügung...

Kann jemand auf Grundlage dieser Erlebniserzählung uns einen Tipp geben, wie wir in dieser HomeAssistant + evvc-Addon-Konstellation mit token sinnvollerweise umgehen?
Ich weiß, ihr unterstützt dieses Setup nicht...

[Sweti934]

Hei @ReneNulschDE - danke bei mir liegt die .db schon korrekt. Trotzdem scheint mir immernoch ein altes Token herangezogen zu werden, und da ich auch unter HomeAssistant arbeite, kann ich EVCC nicht stoppen um die alte .db zu löschen / den Eintrag. Geht das auch anders im "Laufenden" Prozess? Ganz lieben Dank!!

[ReneNulschDE]

Hi @Sweti934,

Wenn Du das HA-EVCC-Addon benutzt:

1. Installiere das HA Addon "Advanced SSH & Web Terminal", konfiguriere nach docu und deaktiviere den Protection Mode.
2. Starte das Terminal und gib docker ps ein. Es kommt eine Liste mit allen laufenden containern. Suche den Namen (letzte Spalte) des evcc containers. Sollte in etwa so aussehen: "addon_xxxxxxx_evcc"
3. Starte docker exec -it addon_xxxxxxx_evcc /bin/sh (ersetze xxxxxxx mit deinem Wert)
4. Jetzt bist du mit der Shell des evcc containers verbunden
5. Starte evcc settings get -c /config/evcc.yaml.
   5a. Wenn ein Eintrag mercedes_email_region vorhanden ist, löschen wir den jetzt mit evcc settings set mercedes_DEINACCOUNT_REGION "" -c /config/evcc.yaml (Ersetze DEINACCOUNT_REGION mit den Werten von get)
   5b. Wenn kein Token vorhanden ist, gehe zu 6.
6. Jetzt erzeuge einen neuen Token evcc token CARNAME -c /config/evcc.yaml (Ersetze CARNAME mit dem namen aus deiner config)
7. Füge den Token in deine /config/evcc.yaml ein. (Z.B. mit dem HA-Addon "File Editor")
8. Verlasse die evcc shell mit exit
9. Starte das evcc addon neu.

[andig]

Die Komponente nutzt immer die Token aus der DB.

@ReneNulschDE ohne in den Code geschaut zu haben: bei andere Integrationen versuchen wir, immer erst den Token aus der Config zu nehmen weil das der einzige Weg ist, diesen einfach zu aktualisieren. Wäre das bei MB evtl. auch möglich?

[ReneNulschDE]

@andig: Ich hatte damals den Tesla Code kopiert, aber ja kann man machen. Vorschlag:

Beim Start:

1. Prüfe ob in der instance bereits ein token mit dem aktuellen account/user schon vorhanden ist, wenn ja nimm diesen. (wie bisher)
2. Falls Schritt 1 fehlschlägt, Nutze den RefreshToken aus der Config und versuche ein refresh, wenn das geht, speichere das Tokenset in den settings und nimm diesen.
3. Falls Schritt 2 fehlschlägt, suche das tokenset in den settings und nimm dieses
4. Falls Schritt 3 fehlschlägt, brich ab wie bisher.

[andig]

Lass uns das probieren- für Tesla ist die Reihenfolge andersrum, aber Hauptsache die User-Config kommt irgendwann zum Zug.

[HKOEHL]

Danke an ReneNulschDE, eine Superarbeitsanweisung, auch für LINUX-DAU's wie mich. (EVCC kann ich, HA 2 Wochen Erfahrung).
Ich hatte das Problem durch ein rückgespieltes Backup im HA. Das Zeitaufwändigste war hier wirklich, das abschalten des "Protection Mode" in SSH. Im aktuellen Release (deutsch) in der Info-Kachel unten "Gesicherter Modus".
Aber auch unbedingt den Eintrag der database in die evcc.yaml oben beachten.

Obwohl HA hier die richtigen Werte anzeigt, wurde bei mir die evcc.db aus dem root-Verzeichnis angezogen

[thecem]

Nicht einfach zu erklären, aber es gibt nur eine wenn man sich an die Anleitung hält, außer man ändert den Path. Mehr wenn ich zu Hause bin.

[ReneNulschDE]

Ich hatte das hier mal durchgespielt. Der service nimmt /data/evcc.db. Der Kommandozeilenaufruf im container nimmt /root/.evcc/evcc.db (in der default config, daher empfehle ich in dem obigen post den pfad fest in der config zu setzen)

[thecem]

Was meinst Du? Welcher Service?

[thecem]

Wie geschrieben gibt es im Addon nur eine DB die genutzt wird /data/evcc.db die ebenfalls im Backup Fall von HA oder nur dem Addon persistent ist. https://github.com/evcc-io/hassio-addon?tab=readme-ov-file#how-to-find-and-copy-dataevccdb
Wenn eine Backup, aus einem anderen System eingespielt wird muss die db im Container ersetzt werden.
Bei der Ausführung wie oben hat HA kein Einfluss was der User im Container macht.

[ReneNulschDE]

Als "Service" meine ich die evcc-instanz welche beim Start des Containers ausgeführt wird.

Wie geschrieben gibt es im Addon nur eine DB die genutzt wird

Das stimmt meiner Meinung nach nicht. Wenn Du dich per terminal auf die evcc docker instanz verbindest und dort evcc auf der commandline startest, wird die db von /root/.evcc/evcc.db gelesen.