Ursprünglich hatte ich beim Auslesen des Smartmeters immer wieder mal falsche Werte in der Datenbank. Die Ursache konnte ich zwar korrigieren, die falschen Werte machen sich aber nicht so gut in der Statistik. Erst nachdem ich einige Zeit damit verbracht habe die Statistik-Daten direkt in der Datenbank zu korrigieren, habe ich entdeckt, dass falsche Statistik-Werte einfach in Home-Assistant geändert werden können.

In den Entwicklerwerkzeugen, im Reiter "Statistik" können die einzelnen Statistik-Werte korrigiert werden:

Weitere Informationen zu den Statistik-Daten, siehe auch: HA Verlauf: mehr als 10 Tage? Long Time Statistic (LTS)

Daten von falschen Einträgen direkt in der Datenbank bearbeiten

Bei der Integration meiner Wasseruhr habe ich die Einheit von m³/h auf Liter geändert und dabei falsche Werte in die Datenbank gespielt. Die SQLite-Datenbank kann über Linux-Board mitteln mit dem Befehl sqlite ausgelesen und bearbeitet werden.

 Zunächst verbinde ich mich in den Docker-Container von Home Assistant: 

docker exec -it home-assistant /bin/bash

Im Docker-Container kann mit folgendem Befehlen sqlite installiert und die Datenbank verbunden werden:

bash-5.1# apk add sqlite
bash-5.1# sqlite3 /config/home-assistant_v2.db

Die Verbindung auf die Datenbank erlaubt es beliebige Datenbank-Queries auszuführen, siehe auch: Home Assistant SQlite - Statistik-Daten ändern

Daten direkt in der SQLite-Datenbank mit VSCode ändern

Etwas komfortabler als Sqlite ist das HA-Add-On: SQlite-Web oder beim direkten Zugriff auf das Host-Filesystem VSCode und die VSCode-Extension SQLite-Editor:

Für das Bearbeiten habe ich nicht den Studio-Code Server in Home-Assistant verwendet, sondern VSCode lokal installiert und eine Remote-Verbindung auf den Host - auf dem der HA-Docker-Container läuft - aufgebaut. Informationen zu VSCode, siehe: "die 4 besten Tools um Text-Dateien zu vergleichen" und "PowerShell Editoren im Vergleich: ISE, Visual Studio Code"

Mit der VSCode-Extension SQLite3 Editor, können die Datenbank-Dateien einfach im Editor geöffnet werden:

Per Dropdown können die einzelnen Tabellen der Datenbank ausgewählt und angezeigt werden:

Zudem kann eine eigene SQL-Query für die Abfrage verwendet werden.

Ausgeführt werden die Queries durch Drücken von Umsch + ENTER:

Metadata_id herausfinden

Für die Daten der Tabelle "states" besitzt jede Entität eine metadata_id, diese ist in der Tabelle states_meta hinterlegt. Die Statistics-Tables verwenden eine eigene metadata_id, diese kann wie folgt herausgefunden werden:

Der Wert "statistic_id" ist dabei der Name des Sensors in der Tabelle "states_meta", die id der Wert metadata_id in den statistics-Tables.

Anzeige aller Statistik-Daten eines Sensors:

SELECT * FROM "statistics_short_term" where metadata_id = "86"

Update eines einzelnen Werts mittels Query

update "statistics_short_term" set state="95197.0" where id=744412;

Hinzufügen von fehlenden Werten

INSERT INTO statistics (created,start,mean,min,max,last_reset,state,sum,metadata_id,created_ts,start_ts,last_reset_ts) VALUES(NULL,NULL,NULL,NULL,NULL,NULL,1027.4,974.44,228,1704970800,1704970800,NULL);

Für das Zusammenstellen von created_ts und start_ts habe ich einen Konverter online gestellt: Datum umwandeln: Unix Timestamp.

Update der Spalte "SUM" in Statistics

Achtung: Vor dem Ausführen muss die metadata_id angepasst werden, im Beispiel 86:

Alle SUM-Werte auf NULL:

update "statistics"  SET SUM = null where metadata_id = "86";

Den ersten Wert mit 0 befüllen:

update "statistics"  SET SUM = 0 where rowid IN (SELECT rowid
                FROM statistics
                WHERE metadata_id = "86"
                LIMIT 1);

Update

WITH t (id) AS (SELECT rowid
                FROM statistics
                WHERE SUM IS NULL
                AND metadata_id = "86")
Update "statistics" SET SUM = (
(SELECT SUM FROM "statistics" where metadata_id = "86" and SUM != "null" ORDER BY "ID" DESC LIMIT 1) +  
(STATE - (SELECT state FROM "statistics" where metadata_id = "86" and SUM != "null" ORDER BY "ID" DESC LIMIT 1))
)
where rowid IN (SELECT id FROM t)

Tabelle statistics_short_term

Alte Daten von statistics_short_term wird ohnehin regelmässig gelöscht, daher ist es meist nicht notwendig diese Tabelle anzupassen, siehe: HA Verlauf: mehr als 10 Tage? Long Time Statistic (LTS).

Alle SUM-Werte auf NULL:

update "statistics_short_term"  SET SUM = null where metadata_id = "86";

Der Update in SQLite kann über die rowid erfolgen, was das Update-Statement im Vergleich zu SQL etwas aufwändiger macht.

Der Anfangswert kann dann wie folgt befüllt werden:

update "statistics_short_term"  SET SUM = "2058.0" where rowid IN (SELECT rowid
                FROM statistics_short_term
                WHERE metadata_id = "86"
                LIMIT 1);

Folgendes Query befüllt die restlichen SUM-Werte erneut

WITH t (id) AS (SELECT rowid
                FROM statistics_short_term
                WHERE SUM IS NULL
                AND metadata_id = "86")
Update "statistics_short_term" SET SUM = (
(SELECT SUM FROM "statistics_short_term" where metadata_id = "86" and SUM != "null" ORDER BY "ID" DESC LIMIT 1) +  
(STATE - (SELECT state FROM "statistics_short_term" where metadata_id = "86" and SUM != "null" ORDER BY "ID" DESC LIMIT 1))
)
where rowid IN (SELECT id FROM t)

Worst Case: Statistikdaten neu aufbauen

Nachdem der Home Assistant Recorder die Details der letzten 10 Tage in die Datenbank schreibt und diese von der History-Integration behandelt werden, können die Statistikdaten der letzten 10 Tage von den Details rekonstruiert werden. Durch das Löschen der History-Tabellen in der Datenbank befüllt Home Assistant diese beim nächsten Start mit den Daten der letzten 10 Tagen neu.

Home-Assistant stoppen:

docker-compose down

Dann mittels SQLite die folgenden Tabellen löschen:

Delete FROM "statistics_runs";
Delete FROM "statistics";
Delete FROM "statistics_short_term";

Home-Assistant wieder starten: 

docker compose up -d

Die letzten Statistikdaten werden jetzt im Hintergrund wieder aufgebaut:

Die Tabelle "statistics_runs" zeigt den Fortschritt:

Die Daten enthalten initial nur 2 Einträge pro Tag ..

Statistik-Daten von einer anderen DB übernehmen

Zudem ist es möglich Daten einer anderen Datenbank, zum Beispiel von einem Backup in die aktuelle Datenbank zu migrieren. Für bestehende Tables kann wie folgt ein Dump erstellt werden: sqlite

user@server:/var/web$ sqlite3
SQLite version 3.37.2 2022-01-06 13:25:41
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open /var/tmp/home-assistant_v2.db
sqlite> .output /var/tmp/export.sql
sqlite> .dump statistics
sqlite> .dump statistics_short_term
sqlite> .quit

Damit der Dump in eine andere Datenbank eingespielt werden kann, habe ich diesen mit einem Editor bearbeitetet. Hauptsächlich um die id aus dem Dump zu entfernen und die Spalten für den Insert hinzuzufügen: 

Regex-Search:

statistics VALUES\([0-9]{1,12},

Replace:

statistics (created,start,mean,min,max,last_reset,state,sum,metadata_id,created_ts,start_ts,last_reset_ts) VALUES(

Im Anschluss können die Einträge des Dumps in eine bestehende Datenbank importiert werden:

sqlite3
SQLite version 3.37.2 2022-01-06 13:25:41
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open /var/tmp/home-assistant_v2.db
sqlite> .read /var/tmp/export.sql

Statistik von einer Entität auf eine andere übertragen

Nachdem ich den Wechselrichter meines Balkonkraftwerks getauscht hatte, wollte ich die Statistikdaten der Anlage nicht verlieren und diese mit dem neuen Wechselrichter weiterführen. Für das Mapping der Statistik-Daten wird rein die ID des Sensors verwendet:

Wird statistic_id, hier "sensor.balkonkw_total_production" mit einem anderen Sensornamen getauscht: im folgenden Beispiel sensor.balkon_yieldtotal, können die Statistikdaten übertragen werden: 

Durch das Umbenennen der statistic_id können sämtliche Werte eines bestehenden Sensors auf einen anderen übertragen werden:

Als zweites Bespiel hatte die ursprüngliche Firmware-Version des Fronius Gen24-Wechselrichters ein Problem mit dem Zähler mit den Ladedaten für meinen BYD-Speicher.

Alternativ können die Werte eines Sensors auch zuvor gelöscht und auf Basis eines anderen Sensors neu erstellt werden

In folgendem Beispiel habe ich die Statistikdaten der Entität: sensor.fronius_mppt_module_2_lifetime_energy gelöscht und mit den Statistikdaten des Sensors sensor.byd_total_charging befüllt.

Tabelle: statistics_meta:

Achtung: Werte in kWh ...

Achtung: Werte in Wh

DELETE FROM statistics WHERE metadata_id = ( SELECT id FROM statistics_meta WHERE statistic_id = 'sensor.fronius_mppt_module_2_lifetime_energy');

WITH target_sensor_statistics_meta_id AS (
    SELECT id FROM statistics_meta WHERE statistic_id = 'sensor.fronius_mppt_module_2_lifetime_energy'
), source_sensor_statistics_meta_id AS (
    SELECT id FROM statistics_meta WHERE statistic_id = 'sensor.byd_total_charging'
)
INSERT INTO statistics (metadata_id, state, sum, created, start, mean, min, max, last_reset, created_ts, start_ts)
SELECT (SELECT id FROM target_sensor_statistics_meta_id), state * 1000, sum * 1000, created, start, mean, min, max, last_reset, created_ts, start_ts
FROM statistics
WHERE metadata_id = (SELECT id FROM source_sensor_statistics_meta_id);

SELECT * FROM statistics where metadata_id = ( SELECT id FROM statistics_meta WHERE statistic_id = 'sensor.fronius_mppt_module_2_lifetime_energy');

Fazit

Einzelne Werte können sehr einfach direkt in Home-Assistant geändert werden. Die von Home-Assistant verwendete SQLite-Datenbank hat im Vergleich zu SQL oder MySQL einige Limitationen, dennoch kann die Datenbank direkt aufgerufen und bearbeitet werden. Als Alternative zu SQLite kann in Home-Assistant auch MySQL als Datenbank verwendet werden, siehe: Home Assistant Datenbank MySQL vs. SQLite.