evcc
evcc copied to clipboard
evcc-io
Persist savings
Persists the savings statistics after restart in a lightwight BoltDB (https://pkg.go.dev/github.com/boltdb/[email protected]).
DB file evcc_savings.db is stored in OS temp directory.
Statistics can be resetted by simply deleting the db file.
Fix https://github.com/evcc-io/evcc/issues/2919
Fehlende Error Behandlung wird noch eingebaut. Warte aber erst mal euer generelles Feedback zur Lösung ab.
Würd es nicht Sinn ergeben, ein Interface für den Store zu bauen, dann könnte man später auch andere DB Implementierungen unterstützen und würde es nicht auf boltdb einschränken… nur so ein Gedanke. 😇
Würd es nicht Sinn ergeben, ein Interface für den Store zu bauen, dann könnte man später auch andere DB Implementierungen unterstützen und würde es nicht auf boltdb einschränken… nur so ein Gedanke. 😇
Die store Funktionen bilden ja quasi das generische Interface. Diese kann man dann zukünftig auch in store.go so erweitern, dass man verschiedene Datenbanken anbinden kann.
Mein Focus ist im ersten Schritt eine einfache, lean, lightweight Lösung ...
Ich mag die Idee mit dem `UserCacheDir. Wo würde das unter Linux landen? Teilen sich alle Settings eine DB bzw. eine Datei oder werden das mehrere? Eine wär für Docker wünschenswert.
Bzw. gem. https://github.com/golang/go/issues/29960 erscheint mir UserConfigDir fast noch geeigneter?
Ggf. wäre es auch schön, ein menschenlesbares Dateiformat zu nutzen (yaml haben wir schon...). Das würde es auch ermöglichen, mal Daten aus unterschiedlichen Quellen zusammen zu bringen etc. Die Entscheidung für ein Dateiformat lässt sich natürlich auch später noch ändern.
/cc @xantalor wär das auch für die MB Tokens nutzbar? Sind Ordner und Zugriffsrechte hinreichend sicher?
Würd es nicht Sinn ergeben, ein Interface für den Store zu bauen, dann könnte man später auch andere DB Implementierungen unterstützen und würde es nicht auf boltdb einschränken… nur so ein Gedanke. 😇
Das lässt sich ja jederzeit nachreichen. Wir bauen ja hier kein API an das wir gebunden sind :)
Ich mag die Idee mit dem `UserCacheDir. Wo würde das unter Linux landen?
$HOME/.cache
Bin mal auf den Nachfolger des boltDB Repos geswitched: https://github.com/etcd-io/bbolt Das Readme dort ist sehr informativ.
Code ist auf os.UserConfiDir geändert ($HOME/.config).
Als bucket habe ich in der aktuellen Version "simple" gesetzt. Damit kann @naltatis zukünftig innerhalb der savings noch differenzieren, indem er andere Bucket Namen verwendet (dazu muss ich allerdings noch den CreateBucketIfNotExists Aufruf auslagern, und in die Put, Get und Delete Funktion auslagern, damit man ein neues Bucket ohne Probleme nutzen kann.
Beschreibung von Buckets: Buckets are collections of key/value pairs within the database. All keys in a bucket must be unique.
Ich komme nochmal hier drauf zurück:
Ggf. wäre es auch schön, ein menschenlesbares Dateiformat zu nutzen
Wie wäre es denn, JSON zu nutzen? Hier gehts ja nicht um Performance. Ein einziges JSON Dict würde den Zweck ja auch erfüllen, selbst wenn es immer komplett gespeichert werden müsste.
Vorteil: man käme auch mit anderen/einfachen Werkzeugen an die Daten.
Ich würde die Parameter pro Modul/Package in einer eigenen DB persistieren. Aktuell sind es nur die savings die in /home/xxxx/.config/evcc_savings.db persistiert werden. Innerhalb dieser savings db, kann sich @naltatis austoben ... ;-)
Für andere Modul/Package Parameter/Configs sollten dann eigene DBs angelegt werden (bspw evcc_config.db).
@andig : Ich finde, dass wir diese evcc "Registry"-Daten nicht im Klartext (bspw. yaml) ablegen sollten. Für ein Backup oder Austausch würde ich dann eher die Möglichkeit einbauen über das Frontend einen Dump zu erzeugen (siehe https://github.com/etcd-io/bbolt#database-backups). Kann man auch als Funktion ins evcc CLI einbauen.
Kann man auch als Funktion ins evcc CLI einbauen.
Export, import, merge? Wär mir viel zu kompliziert.
Ich finde, dass wir diese evcc "Registry"-Daten nicht im Klartext (bspw. yaml) ablegen sollten.
Warum?
PS.: hier ist eine schöne Kriegsgeschichte dazu: https://tailscale.com/blog/an-unlikely-database-migration/
OK, d.h. du schlägst die JSONMutexDB vor, oder etcd?
JSONMutexDB: The object holding all the data was wrapped in a sync.Mutex, all accesses went through it, and on edit the whole structure was passed to json.Marshal and written to disk. This gave us data model persistence in ~20 lines of Go.
Ggf. wäre es auch schön, ein menschenlesbares Dateiformat zu nutzen (yaml haben wir schon...). Das würde es auch ermöglichen, mal Daten aus unterschiedlichen Quellen zusammen zu bringen etc. Die Entscheidung für ein Dateiformat lässt sich natürlich auch später noch ändern.
/cc @xantalor wär das auch für die MB Tokens nutzbar? Sind Ordner und Zugriffsrechte hinreichend sicher?
Da das Token/RefreshToken schon ziemlich sensibel sind, wäre ich nicht wirklich glücklich über diese Umsetzung aber als ersten start kann man das schon machen.
Ggf. wäre es auch schön, ein menschenlesbares Dateiformat zu nutzen (yaml haben wir schon...). Das würde es auch ermöglichen, mal Daten aus unterschiedlichen Quellen zusammen zu bringen etc. Die Entscheidung für ein Dateiformat lässt sich natürlich auch später noch ändern. /cc @xantalor wär das auch für die MB Tokens nutzbar? Sind Ordner und Zugriffsrechte hinreichend sicher?
Da das Token/RefreshToken schon ziemlich sensibel sind, wäre ich nicht wirklich glücklich über diese Umsetzung aber als ersten start kann man das schon machen.
Ein anderes Dateiformat macht es nicht sicherer (security by obscurity?). In jedem Fall sollten wir aber die Rechte der Datei korrekt setzen. Bei SSH ist das m.W. 0600?
Bei SSH ist das m.W.
0600?
Ja, gibt nur dem anlegenden User Lese- und Schreibrechte. Keine Leserechte für die UserGruppe und Others.
Ggf. wäre es auch schön, ein menschenlesbares Dateiformat zu nutzen (yaml haben wir schon...). Das würde es auch ermöglichen, mal Daten aus unterschiedlichen Quellen zusammen zu bringen etc. Die Entscheidung für ein Dateiformat lässt sich natürlich auch später noch ändern. /cc @xantalor wär das auch für die MB Tokens nutzbar? Sind Ordner und Zugriffsrechte hinreichend sicher?
Da das Token/RefreshToken schon ziemlich sensibel sind, wäre ich nicht wirklich glücklich über diese Umsetzung aber als ersten start kann man das schon machen.
Ein anderes Dateiformat macht es nicht sicherer (security by obscurity?). In jedem Fall sollten wir aber die Rechte der Datei korrekt setzen. Bei SSH ist das m.W.
0600?
Hatte da eher an eine geschütze und/oder encrypted DB gedacht ;) Die Berechtigung sollte passen.
Hatte da eher an eine geschütze und/oder encrypted DB gedacht ;)
Wir können dazu auch auf https://github.com/jrapoport/chestnut switchen ...
Kein Bedarf. Was für SSH gut genug ist sollte für uns auch erstmal reichen...
Das MB Token gehört mMn genau an die gleiche Stelle, wo wir auch Passwörter und andere Vendor Tokens (Tesla) halten. Aktuell ist das die evcc.yaml. Wir werden für die Web-Konfiguration sowieso einen Weg brauchen diese Konfiguration zur Laufzeit zur verändern.
Wie steht ihr denn zu SQLite? Bei einer JSON/Yaml Datei kommen wir glaube ich relativ schnell an Probleme, wenn die Datenmengen größer werden (Ladelog, Historien). SQLite ist abgehangen und verbreitet genug, dass man im Notfall immer noch an die Daten kommt, auch wenn das Dateiformat nicht Plaintext ist. In der iOS/Mac Welt ist das inzwischen ja auch der Standard.
Eine extra Verschlüsselung würde ich auch eher nicht als sinnvoll sehen und mich hier auf die Sicherheitsmechanismen aufs OS verlassen.
JSON erlaubt Hierarchien, SQlite nicht. Lasst uns das Performanceproblem lösen wenn es eins wird.
Soll ich den PR schließen? Bin noch nicht der go-Crack, der den JSONMutexDB Ansatz einfach aus der Hüfte schießt. ;-)
Warum nicht einfach die Werte auf den MQTT Broker schreiben und nach einem Neustart schauen, ob da was steht, wenn ja, einfach übernehmen.
Nur so eine Idee.
Sebastian
Warum nicht einfach die Werte auf den MQTT Broker schreiben und nach einem Neustart schauen, ob da was steht, wenn ja, einfach übernehmen.
Nur so eine Idee.
Sebastian
Hab gerade gesehen, das die ja schon auf dem Broker landen. Fehlt also nur das Zurücklesen nach dem Neustart.
Sebastian