Skript um Energy-Dashbord zu korrigieren - Alte Daten hinzuzufügen DIE LÖSUNG

Bei einer Home Assistant (HA) Neuinstallation wollen viele ihre alten Energiedaten ins Dashboard übernehmen. Das ist nicht trivial. Hier erkläre ich, warum es oft scheitert und wie meine Lösung mit zwei Python-Skripten das Problem löst.

1. Das Problem: Warum alte Daten nicht einfach übernommen werden
Bei einer HA-Neuinstallation vergibt HA neuen Sensoren neue META_IDs in der State-Tabelle (egal ob HA-DB oder MariaDB). Alte Daten sind nicht mehr kompatibel oder fehlen. Ein SQL-Import aus einem Backup scheitert, da die META_IDs nicht übereinstimmen. Selbst wenn die IDs per Skript angepasst werden, ignoriert das Energie-Dashboard die Daten, da es spezifische Formate erwartet.

2. Meine Lösung: Zwei Python-Skripte
Ich habe zwei Skripte entwickelt (eins für HA-DB, eins für MariaDB), die alte CSV-Daten mit dem Energie-Dashboard synchronisieren. Keine Programmierkenntnisse nötig. Hinweis: Am einfachsten auf Mac/Linux.

3. Schritt-für-Schritt-Anleitunga) Backup auf Zweitsystem wiederherstellen

  • HA auf einem zweiten System neu installieren.

  • Beim Startbildschirm das Backup auswählen. Wichtig: Kein Backup über eine bestehende Installation ziehen, da HA sonst nur etwa 80 % der Daten herstellt oder Meta-Daten ignoriert.

b) CSV-Daten exportieren

  • Auf dem wiederhergestellten System das Energie-Dashboard öffnen.

  • Monatsansicht wählen und jeden benötigten Monat als CSV herunterladen.

  • Auf dem neuen System die aktuelle Monatsansicht (auch wenn leer) als CSV exportieren.

c) Skripte ausführen

  • Alte CSVs in den Import-Ordner des Skripts kopieren.

  • Aktuelle CSV in master_energie_import.csv umbenennen und in den Ordner legen.

  • Skript starten.

4. Was macht das Skript?

  • Es merged alte CSVs mit der master_energie_import.csv. (die muss zwingend vom aktuellen System kommen, in das importiert werden muss Stichwort “ Meta_id und recorder”

  • Bei Sensoren ohne Zuordnung fragt es, ob sie neu angelegt oder zugeordnet werden sollen.

  • Fehlerhafte Werte (unknown, not available etc.) werden bereinigt.

  • Ergebnis: Eine saubere master_energie_import.csv, die mit dem zweiten Skript in HA importiert wird.

5. Fertig
Nach dem Import HA neustarten. Das Energie-Dashboard zeigt wieder alle Daten. Tipp: Skripte in einer Testumgebung ausprobieren. Bei Fragen gerne melden.

Also keine Hudelei mit SQL Befehlen, Datenbank-Emulatoren .. Einfach und simpel

6 „Gefällt mir“

Ich vergebe den neuen Sensoren dann einfach die Entity-ID der alten.
Funktioniert auch gut. :wink:

Gruß Osorkon

Ja-Ein.. ich erkläre es noch einmal genauer :wink: Wir reden hier über eine Neuinstallation / Datenverlust - Dein Ansatz funktioniert da nicht.

Das Problem: HA vergibt neuen Sensoren eine neue META_ID in der State-Tabelle (egal ob HA-DB oder MariaDB). Man muss hier ganz deutlich unterscheiden zwischen “Entity /Name des Sensors” und dessen meta_id in der Datenbank. Das sind zwei grundverschiedenen Dinge. Aus diesem Grund kann man auch nicht einfach Sensoren” importieren sondern immer nur meta_id und die Tables müssen auch stimmen. Es ist nicht trivial! Das ist ein tiefer Eingriff in die grundlegende Struktur der Datenbank, mittels SQL-Befehlen. - Von der ich dringend abrate!

Selbst wenn du die IDs per Skript in der Tabelle mappst, tauchen die Sensoren nicht im Energie-Dashboard auf. Warum? Das Energie-Dashboard tickt anders. Kurz gesagt: Auch wenn du alte Daten (Recorder, Statistiken, etc.) per SQL importierst und die IDs zuordnest, ignoriert das Dashboard diese Daten.

Meine Lösung:
Ich habe zwei Python-Skripte entwickelt, die genau dieses Problem lösen. Sie mergen alte CSV-Daten, matchen die Sensoren und schreiben die Daten automatisch in die Datenbank – speziell fürs Energie-Dashboard. Es gibt ein Skript für HA-DB und eines für MariaDB, da beide unterschiedlich arbeiten.

Eine Neuinstallation im Sinne einer Erstinstallation, da gibt es ja noch keine Historie?
Bei einer Migration auf einen neuen Host, verwende ich ein Backup.
Bei Datenverlust fehlt doch auch die db?!

Ein Anwendungsfall wäre, mein Home Assistant Host macht die Kretsche und ich kann nur die db aus dem Backup retten. → ziemlich unwahrscheinlich.

Oder ich wiederherstelle nur die db aus dem Backup → aber warum?

Aber Du hast bestimmt eine Motivation gehabt, sonst hättest Du Dir ja sicher nicht die Arbeit gemacht.

Gruß Osorkon

Wenn du ein Backup einspielst, dann fehlen die Aktuellen Daten! Daher ist dieser Weg besser, er behält die aktuellen Daten und fügt historische hinzu UND versetzt das Datum des entsprechenden Riemann in die Vergangenheit (!!!)

Somit gibt mehrere Anwendungsfälle für die Anpassung von Riemann-Sensoren im Energie-Dashboard:

  1. Neuinstallation: Ein neuer Sensor wird hinzugefügt, geändert

  2. Falscher Purge-Befehl: Daten wurden versehentlich gelöscht und müssen wiederhergestellt werden. Klassische Beispiel: Im Energie-Dasbord sind die Daten vorhanden, nicht jedoch in der Einzelstatistik des Sensors :wink:

  3. Korrekturen an Energiesensoren: Anpassungen an bestehenden Sensoren, z. B. bei fehlerhaften Messwerten.

  4. Startwertproblematik bei Riemann-Sensoren: Riemann-Sensoren erlauben keine nachtragende Definition eines Startwerts. Eine Alternative zum Einfügen eines Offsets via SQL ist daher notwendig.

Lösungsansatz für eine lineare und konsistente Historie:

Änderungen im Energie-Dashboard, wie das Hinzufügen oder Korrigieren von Sensoren, führen automatisch zu einer Aktualisierung der Riemann-Sensoren. Dabei wird eine Neuberechnung der Daten ab einem früheren Datum angestoßen.

Dies ist derzeit die einzige bekannte Methode, um das Startdatum eines Riemann-Sensors in die Vergangenheit zu verlegen und historische Daten konsistent zu integrieren.

Technische Einschränkung von HA:

  1. Es ist nicht möglich, einen neuen Riemann-Sensor direkt mit historischen Daten zu initialisieren. Die Neuberechnung der Daten ist daher unerlässlich, um eine korrekte und konsistente Datenhistorie zu gewährleisten.

  2. HA Rieman-Sensoren erwarten in der Energy Dashboard statistics Tabelle kumulative (immer steigende) Werte:

    Tag 1:  2.42 kWh
    Tag 2:  5.28 kWh  (2.42 + 2.86)
    Tag 3:  8.42 kWh  (5.28 + 3.14)
    Tag 4: 11.04 kWh  (8.42 + 2.62)
    ...
    Tag 12: 50.00 kWh
    Tag 13: 51.06 kWh  (50.00 + 1.06) ← NICHT zurück auf 1.06!
    
  3. Man kann theoretisch mit einem Flag und entsprechender Datei eine Base-Line setzen, die in einem Skript nur einmal laufen lassen und dann weiter aufsummieren. Problem: Differenz zwischen dem Datum der Base-Line und weiterführenden Daten. Ergo, alles nach der Base-Line stimmt, alles davor nicht.

  4. Manuelles korrigieren mit Hilfe der Entwickler-Tools würde gehen, aber bei vielen Daten sehr mühsam.

Ein weiterer persönlicher Punkt:
Ich nutze keine Templates zu Berechnungen / Statistiken / Umrechnungen/.. das ist viel zu umständlich und verbraucht zuviel Ressourcen! Ich mache das alles via SQL das ist viel genauer und einfacher. Daher sind korrekte Daten mehr als wichtig. UND ich mag keine halben Sachen.
Wie ich das mache, ist noch einmal eine andere Story da ich das mit einem PI mache der auf den Rechner mit HA und die Datenbanken zugreift und mittels Skripten das berechnet was ich wissen will und via MQTT an den HA zurückgibt - PERFEKT!

Nachtrag:
Da die Frage nun mehrfach nach einem Offset für einen Sensor kam… es gibt zwei Möglichkeiten (aber keine bei einem Riemann Sensor! )

Option 1)

den Sensor via SQL abfragen (zum Beispiel mit der SQL-Intergation. Dem Befehl einen Offset hinzufügen. Dann entsteht ein “ Neuer Sensor” mit einem Offset von dem Weitergezählt wird.

HINWEIS:
Riemann Sensoren sind grundsätzlich die schlechteste Wahl um kWh Sensoren zu erstellen. Eben durch die Limitation sie nicht einfach verändern lassen - keine Baseline zulassen (Anfangswert).

Der bedeutet bessere Weg ist eine SQL-Abfrage die automatisch in kWh umrechnet (das macht sie bei jedem Abruf / kontinuierlich). Ändert man nun einen Wert in der Vergangenheit, rechnet sie den einfach mit. - Easy und smart!

Das geht übrigens auch ohne Probleme wenn man mehrere Sensoren zusammenrechnen will - oder zusammenrechnen und dann kWh.

z.B.
PV1 + PV2 + PV3 + PV4 = Gesamt-PV > als kWh

Hier die Anleitung wie es funktioniert. Wen der Technische Hintergrund nicht interessiert einfach weiter nach untern scrollen.

Problem: Ein leeres Energie Dashboard nach Datenverlust, Neuinstallation, Sensor-Problemen.
Aufgabe: Wiederherstellen der historischen Daten ohne Zerstörung der Datenbank. des Verantwortlichen Riemann-Sensors.

Herausforderung / Einschränkungen:
Kurze Einführung in die Tiefen der Datenbank und Funktionsweise (wen es nicht interessiert bitte einfach weiterscrollen)

  • Riemann Sensoren erlauben keinen Offset oder Startwert > Im Moment des Erstellen fangen sie bei Null an
  • In älteren HA-Versionen, war es möglich einen Riemann via Yamll zu basteln incl. einem Startwert. Das geht nicht mehr.
  • Eine Historie kann man Riemann Sensoren nicht nachträglich “verpassen”
  • Das Einspielen eines Backups überschreibt die Datensätze nach dem Datum des Backups
  • Datenbankmanipulationen führen zum Absturz des Riemann Sensors oder negativen Sprüngen.
  • Das benennen eines Neuen Sensors mit dem Namen des ursprünglichen Sensors hilft nicht, da die META_ID des Sensors in der Tabelle der Knackpunkt ist und nicht der Name.
  • Der Ansatz ach vorherigen extrahieren der Historie der Bezugssensoren und Mapping dieser auf die aktuelle META_ID im Neuen System wird vom Riemann ignoriert. > Man hat dann zwar eine Historie der Quell-Sensoren - die Riemann ist das aber egal.
  • Manipulation in der Datenbank mittels SQL und Skripten kann zwar Historien kurzfristig ändern, aber nach einem Neustart verwirft HA die Werte wieder

Kurzum, egal was man versucht man bekommt keine Historie zurück (eines Riemann Sensors) die vor dem Zeitpunkt des erstellen des Sensors liegt.

  1. Herausforderung: Meistens haben nach einem Crash, einer Neuinstallation die Sensoren andere Namen ganz sicher jedoch andere META_ID in der Tabelle und der Kurzzeittabelle. Ja, man kann die Mappen via SQL - aber ich denke die wenigsten hier haben das Wissen das zu tun. - Ändert aber nichts an der Ausgangslage - Unmöglich den Berechnungszeitpunkt eines Riemann Sensors zurückzuverlegen.
  2. Man muss irgendwie verschiedene RS mergen auf den aktuellen (neuen) RS im Energie Dashboard.

Lösung:

Zunächst einmal muss man verstehen, dass das Energie Dashboard ein altes Relikt aus vergangenen Jahren des HA ist. Das bedeutet, es ist nicht direkt via SQL ansprechbar da es sich aus allen Ecken der Datenbank Werte zieht und die unabhängig berechnet. Das allerwichtigste ist (EIN GRUNDLEGENDER UNTERSCHIED ZU DER AKTUELLEN ARCHITEKTUR) das das Energie Dashboard mit anderen Klassifizierungen arbeitet. Nicht mit META_ID`s / ENTITIES / sondern mit sogenannten Types. Genau das ist der Angriffspunkt zur Manipulation. Da die Types überhaupt nichts mit den Sensoren zu tun haben. Die Entities im Energie-Dashboard sind quasi nur Namen ohne weiteren Bezug sondern nur zum Abgleich.

Genau hier ist der Schwachpunkt - den ich nutze um folgendes zu erreichen:

Man muss also die “Types” in die versteckte Struktur des Energie-Dashbord laden. Da ich ein ziemlich Fauler Hund bin.. habe ich dafür folgende Lösung für euch.. “ quick and dirty”

ANLEITUNG Step by Step

Schritt 1:
Geht auf dem neuen (leeren System) auf das Energie Dashboard WICHTIG nachdem ihr eure neuen Sensoren dort hinterlegt habt und die zumindest ein paar Werte geschrieben haben.

Schritt 2:
Wechselt zur Monatsansicht und ladet den aktuellen Monat als CSV auf euren Rechnen. WICHTIG es funktioniert ausschließlich (stabil) mit Monat-Exporten. Kopiert diese Datei den Skript-Ordner und nennt sie: master_energie_import.csv

Schritt 3:
Wechselt zu dem alten System (sofern vorhanden) oder macht eine neue (frische) Installation und wählt aus das ihr ein Backup wiederherstellen möchtet (eines das die Daten enthält die euch fehlen) WICHTIG: Es MUSS eine komplette neue Installation sein, da ein “ Drüberbügeln” eines alten Backups auf eine bestehende Installation nicht alles wieder herstellt. Die Backup- Funktion von HA ist gelinde gesagt “Mistig”.

Schritt 4:

Geht in das Energie Dashboard und wechslet in die Monats-Ansicht und ladet dieser herunter für jeden einzelnen Monate den ihr im Neuen System wieder importieren möchtet. kopiert die Dateien in den Ordner “ Import” in den Script-Ordner (es ist völlig egal wieviele CSV das sind..

Schiritt 5:

Nun beginnt die Magie, führt das Skript merge_script.py aus und innerhalb weniger Sekunden habt ihr eine passende und funktionierende Importdatei.

Schritt 6

Meldet euch via SMB auf euren HA an und und kopiert die gerade erstelle Datei “ master_energie_import.csv “ in den config Ordner. Zusätzlich kopiert ihr das 2 Skript “ ha_energy_import.py “ in den Ordner config. HINWEIS: Wenn ihr euren HA nicht in der Netzwerkumgebung seht, könnt ihr die beiden Dateien auch mit dem File-Explorer And-On in HA einfach “uploaden”.

Schritt 7

Nun kommt der kniffelige Part :slight_smile: verbindet euch via SSH mit eurem Ha zb: SSH NAME@192.67.46….. (deine IP)

Zur Sicherheit HA stoppen mit dem Befehl:

HA core stop

Wechselt dann das config Verzeichnis mit “ cd config” und führt das Skript aus “python ha_energy_import.py

Los geht die wilde Fahrt…

Je nach Anzahl der Daten dauert es ca. 10 - xx Minuten. Am Ende steht da:

==================================================

Import abgeschlossen!

Importiert: 10276 Datenpunkte

Übersprungen: 1624 (bereits vorhanden)

Entities ohne ID: 0

Fehler: 8

==================================================

✓ Import erfolgreich abgeschlossen!

Du kannst Home Assistant jetzt wieder starten (falls gestoppt).

➜ config ha core restart

Processing… Done.

HINWEIS:
Ihr werdet immer auch Fehlermeldungen bekommen, dass ist völlig normal - Einfach ignorieren…
Zum Abschluss “ ha core restart” eingeben

Nun kurz zum Skript:

a) Ich übernehme keine Verantwortung für irgendwelche Schäden die Nutzung ist auf eigene Gefahr!
b) Leider kann ich es hier nicht anhängen… wer es haben möchte einfach PN und ich schicke es.
c) Wichtig, es gibt einen Unterschied zwischen MariaDB und der HADB, also bitte mitgeben welche DB ihr benutzt. Ich rate dringend zu der MariaDB da man mit der noch einiges Anderes anstellen kann - ziemlich cooler Sch**** der da möglich ist.

FAQ / Bekannte Probleme (User-Feedback)

Es kann zu unrealistischen Werten kommen / Außreißern. Die Entsprechenden " Daten / Werte" im Entwickler Menü unter Statistik korrigieren.

Kann ich das Skript unter Windows nutzen?
Ja, mittels der Eingabeaufforderung > die Befehle bleiben die Selben (bitte sicherstellen das Python installiert ist)

Mein Solarsensor hieß im alten System anders - ist das ein Problem?
Nein, da das Skript es korrigiert und nach type zuordnet.

im Neuen System heißen die Verbraucher anders, zum Beispiel Shelly-Wohnzimmer (zuvor Wohnzimmer) werden die erkannt?
Ja, das Merge-Skript fragt Dich ob du einen bisher unbekannten Sensor neu anlegen oder einem bestehenden zuordnen willst. HINWEIS: Neu Anlegen geht nicht immer je nach DB da eine META_ID erzeugt werden muss. Skript läuft aber weiter.

Kann ich auch Tageswerte exportieren und mit dem Skript importieren anstatt Monatswerte?
Ja und Nein, je nach Datenbank kann es den Riemann-Zerstören. Ich empfehle ganz klar die Monate zu bevorzugen - ist stabiler

Ich habe mit SQL die Datenbank angesehen und habe festgestellt das der Riemann nun auch negative Werte hat - wie kommt das ist das ein Problem?
Das ist normal, da das Energie-Dashboard eben nicht in die klassische DB schreibt, aber die Werte an den Riemann “übergibt”. Um Probleme zu vermeiden (das der Riemann abstürzt) übergibt das Skript die Werte absichtlich mit einem “Komma” und nicht einem “Punkt” also als String und nicht value. Sollten trotzdem Ausreißer entstehen, da der Riemann nicht korrekt kumuliert, einfach in mit den Entwickler Tools " Statistik) den entsprechenden Tag heraussuchen und von negativ in positiv ändern mit der korrekten Formatierung (Punkt statt Komma) das Dashboard rechnet dann neu und korrigiert es OHNE den Riemann zu beschädigen.

@harryp bitte den ersten Post löschen und diesen an den Anfang verschieben DANKE!

1 „Gefällt mir“

Zuersteinmal möchte ich meinen Respekt zollen für jemandem der so tief einsteigt und sein Wissen teilt. :+1: :flexed_biceps:

Auch ich werde bald mein HA erstmalig auf einen neuen Host migrieren und werde ein Backup vom vorheriger Instanz einspielen. Ich frage mich ähnlich wie mein Vorredner in welchem Szenario ich Dein Vorgehen einsortieren muß?

1 „Gefällt mir“

Diese Anmerkung kann ich nicht nachvollziehen. Bei mir wurde bisher immer alles komplett wiederhergestellt. In wiefern ist das bei dir nicht der Fall?

Mich interessiert außerdem, wo genau der Vorteil deiner Methode liegt. Für mich sieht es so aus, als würden, im Gegensatz zum Einspiele eines Backups, nur die Daten, die ab dem Aufsetze einer neuen Instanz von HA zusätzlich erhalten bleiben. Allerdings muss ich bei mir, damit HA überhaupt neue Daten schreiben kann, erst ein Backup einspielen. Sonst laufen die ganzen Integrationen nicht, die Daten liefern.

1 „Gefällt mir“

Hallo Bacardi

Vielen Dank für deinen Kommentar und die Beteiligung an diesem Thread. Ich habe die Gründe bereits benannt. Ein weiterer Klassiker ist auch, du hast " rumporobiert " und des System läuft nicht mehr > Du spielst ein Backup ein im Anschluss stellst du fest das Daten fehlen. Nun hast Du zwei Optionen

a) Du nimmst ein noch älteres Backup - Verlust der aktuellen Daten
b) Du nimmst es einfach so hin

Hier greift die Methode - BTW ich kann auch gerne erklären wie man jeden Sensor den HA mal kannte wie SQL-Mapping nachträglich wieder herstellen kann oder die Werte (recorder, Statistik,..) einem anderen Sensor zuschreiben kann. Hierfür ein Szenario:

Du hast vor einem Jahr ein sauberes System aufgesetzt und nun fällt die auf das Du doch noch die Werte von Sensor XYZ von vor 3 Jahren benötigst..

Beste Grüße

Hallo 73ymw

Vielen dank für Deinen Beitrag!

Die Backups von HA sind super wenn man diese direkt bei einer Neuinstallation verwendet - keine Frage! Nutze man diese jedoch in einem laufenden System sind sie “augenscheinlich” - okay- aber.. in Wirklichkeit erzeugen Sie eine Menge Datenmüll in den den Datenbaknen, da die “Sensoren” der Instanz über die sie gezogen wurden bestehen bleiben - ohne sie ansprechen zu können. Ich müsste mir das mal genauer ansehen, aber es scheint so dass die betroffenen ID in eine “Geistertabelle” verschoben werden. D.h sie sind noch da aber nicht funktional. Besonders betrifft das InfluxDB. So kommt es das sich die Backups ziemlich aufblähen und locker 6GB nach mehrfachen einspielen erreichen. Mit einem PURGE Befehl kommt man hier nicht weiter. Möchtest Du das ich das noch tiefer erkläre / meine Beobachtungen schilder?

Ich habe Backups analysiert da war die HADB 1,xx GB und die InfluxDB fast 5GB.. ich habe die Datenbank(en) auch mal lokal eingebunden (influxDB, MariaDB, HADB) und das bestätigt meine Vermutung. Kurzum spielt man ein Backup in einem laufenden System ein " schleppt" man Bein nächsten Backup die Daten des aktuellen Systems und des Neuen Systems mit.. “sehr sehr vereinfacht ausgedrückt” - ohne die “Leichen” ansprechen / nutzen zu können.
Besser wären inkrementelle Backups statt “stumpfer” Kopien.
Ich erstelle daher Datenbank Dumps - was deutlich eleganter ist.

Okay, InfluxDB hat ja aber erst mal nichts generisch mit HA zu tun. Ich wollte nur wissen, was du mit „Misti“ meinst. Auch ein einspielen von Backups im laufenden Betrieb hat noch nie zu den von dir beschriebenen Problemen (Influx nutze ich nicht) geführt.

Hey 73ymw

Es ist immer eine Frage der Betrachtung und der vorhandenen Gegebenheiten. M.E. nutzen sehr viele die InfluxDB zur Virtualisierung von Sensorwerten mittels Grafana. Auch spreche ich hier von Datenbanken und was Backups mit denen machen - das fällt einem “normalen Nutzer” bestimmt nicht auf. Somit hast Du von deiner Position nicht unrecht, da du es nicht trackst, anschaust, dich nicht in der Datenbank bewegst - Alles gut!

Hallo,

ich hätte Interesse an Deinem Script.
Es geht um Daten eines Shelly 3EM, den ich durch einen Pro ersetzt habe und dann in HA gelöscht habe. Das ist allerdings auch schon fast ein Jahr her. Die Daten habe ich noch vorliegen. Ich bin auch mit HA vor drei Monaten von der Synology NAS auf einen Pi5 umgezogen, daher bin ich unsicher ob ,an die Daten vielleicht auch widerherstellen könnte..

Danke schonmal!

Verstehe ich das richtig, auch bei eingespieltem Backup werden im Energydashboard dann keine Daten aus der Vergangenheit mehr angezeigt?
Ich will demnächst von meinem HA Green auf einen neuen Mini-PC umziehen. Dazu will ich an Tag X den Bruch machen und ein Backup erstellen, aufm Mini einlesen und den Green erstmal ausschalten.

Das führt zu Datenverlust im Energy?

Hallo @Tobias75,

da damals kein großes Interesse an dem Skript bestand und die Notwendigkeit nicht wirklich gesehen wurde, habe ich die Arbeit daran eingestellt. Ich nutze es mittlerweile nur noch lokal für mich. Tut mir leid!

Hallo @kaison91,

Jein. Es kommt ganz darauf an, wie man vorgeht.

Grundsätzlich ist es so: Wenn du Home Assistant neu installierst und später einrichtest, vergibt HA neue Meta-IDs. Wenn du also umziehst, solltest du auf keinen Fall zuerst HA neu installieren und danach erst ein Backup einspielen. Dabei gehen die historischen Daten meistens verloren.

Genau an dieser Stelle hat mein Skript angesetzt: Damit konnte man die alte Meta-ID (zum Beispiel sensor.kwh-std-solar) mit der neuen Meta-ID (sensor.solar-gesamt) zusammenführen. Das sorgt für eine lückenlose Historie. Das ist besonders praktisch, wenn man die Hardware wechselt oder historische Daten auf eine neue Installation übertragen möchte.

Ein Beispiel: Du wechselst den Wechselrichter von EcoFlow zu Anker. Das sind zwei unterschiedliche Integrationen, die auch unterschiedliche Entitäten und Meta-IDs erzeugen. Möchtest du nun die alte Historie mit dem neuen Wechselrichter (Anker) vereinen, geht das nur, indem man die Datenbank manipuliert und die alten Daten auf die neue Identität umschreibt.

Zweites Beispiel:
Du installierst HA neu, da er zuviele Fehler hat, zuviel alter Müll rumliegt und du möchtest nur gezielte Daten wieder herstellen.

Drittes Beispiel:
Deine Datenbank ist abgeraucht und du möchtest aus einen Lokalen Backup nur gezielt nach einer Neuinstallation Daten in der DB wiederherstellen…

Viertes Beispiel:
Du wechselst von MariaDB zu HADB oder umgekehrt…

Gefährlich wird es, wenn man “Zombie-Finder” wie Spook oder HAGHS benutzt. Diese markieren die alten Entitäten als “verwaist”, weil die Daten zwar noch in der Datenbank liegen (z. B. durch ein Backup), aber nicht mehr aktualisiert werden. So oder so ist das Thema nicht einfach. Gleiches gilt auch für Temperatur-Sensoren, ect…

Genau dafür war mein Skript gedacht:
Es hat alte Entitäten anhand der Meta-ID zusammengeführt.

Aber wie oben schon geschrieben, wurde es kaum genutzt und nicht als Lösung anerkannt – deshalb habe ich das Projekt eingestellt.

Sorry..

Mein Vorschlag: Neuninstallation und dann an “aus altem Backup wiederherstellen” auswählen. Dann hast Du die alten Daten zurück, aber das verhindert nicht 1-4.

Beim Wechsel des Wechselrichter reicht es aus die alte Entität zu löschen und die neue auf den alten Namen umzubenennen.
Seit HA Core 2023.4 benutzt HA intern eine numerische Meta-ID und bindet diese an den Sensor Namen.
Das bedeutet gleicher Sensorname gleiche Id

Hallo @Thomassh

Deine Aussage ist nur teilweise richtig.
Der von dir beschriebene Weg funktioniert in manchen Fällen, führt aber bei Wechselrichtern (die meist über eine Integration mit unique_id angebunden sind) häufig zu Problemen oder Datenverlust.

Du vermischst dabei zwei unterschiedliche Konzepte. Die zwei wichtigen IDs in Home Assistant

  1. Die unique_id (der Integration)
    Jede Entität aus einer Integration (SolarEdge, Fronius, SMA, Modbus etc.) hat eine einzigartige unique_id, die meist an die Seriennummer oder Geräte-ID gekoppelt ist.
    Ein neuer Wechselrichter bekommt eine andere unique_id → Home Assistant erkennt ihn als komplett neue Entität, auch wenn der entity_id (z. B. sensor.wechselrichter_leistung) identisch ist.

  2. Die interne metadata_id (seit Core 2023.4)
    Seit dieser Version speichert der Recorder die Historie und Long-Term-Statistics nicht mehr nur unter dem entity_id, sondern verknüpft ihn über eine numerische metadata_id in der states_meta-Tabelle.
    Das bedeutet: Gleicher entity_id allein reicht nicht immer aus – besonders wenn die unique_id unterschiedlich ist.

Warum „alte Entität löschen + neue umbenennen“ oft nicht reicht

  • Löscht du die alte Entität, wird die Verknüpfung zur alten Historie teilweise aufgehoben.
  • Fügst du den neuen Wechselrichter hinzu und benennst ihn um, erhält er meist eine neue metadata_id.
  • Folge: Die alten Langzeitstatistiken (wichtig für das Energie-Dashboard) gehen verloren oder es entsteht eine Lücke. Das Dashboard zeigt dann ab dem Tausch-Tag keine oder nur unvollständige Werte.

Der Trick funktioniert zuverlässiger bei reinen MQTT-, Template- oder manuellen Sensoren ohne feste unique_id. Bei echten Geräte-Integrationen wie z.b. Wechselrichtern mit eigenen Integrationen meist nicht.Der zuverlässigste praktische Weg (Stand 2025/2026)

Genau hier hat mein Skript angesetzt und die MetaID in der DB gemappt, bzw die Datensätze mit der aktuellen MetaID aufgefüllt.
Durch das Umschreiben der metadata_id in den Tabellen states_meta (und den dazugehörigen Statistik-Tabellen wie statistics_meta, statistics und statistics_short_term) habe ich das Backend ausgetrickst.

  1. HA legt für den neuen Wechselrichter eine neue metadata_id an.
  2. Mein Skript nimmt die alten historischen Daten (die noch unter der alten metadata_id laufen).
  3. Es schreibt die ID dieser alten Datensätze auf die neue metadata_id um (oder migriert sie sauber herüber).

Ergebniss 100% sichere Migration ohne Datenverlust und das für JEDE MetaID! Auch verhinderst Du auf diesem Weg die Lücken und ggf durch Purge verloren gegangenen Daten.

Privater Hinweis:
Genau wegen solcher Diskussionen und Verständnisprobleme habe ich das Skript eingestellt und nutze es nur noch privat. Da ich für meine KI-Entwicklungen häufig Testumgebungen aufsetze, funktionieren normale Backups oder das Umbenennen für mich nicht – besonders wenn ich eine lückenlose Historie an Lerndaten benötige oder Datensätze absichtlich „vergifte“, um die Reaktionen der lokalen KI darauf zu testen. → ich brauche verschiedene WR-Integrationen, Wetter-Sensoren, Änderungen von Panelgruppen ect.. und muss die Mergen.. eben genau den Fall der hier beschrieben wurde.