Als ich dieses Thema im Simon-Newsletter gelesen habe, habe ich auch erstmal ein Schreck bekommen. Nach Prüfung in HA habe ich keinen Reparaturhinweis gefunden.
Ich habe die “InfluxDB v2”-App installiert aus diesem Repo:
https://github.com/danieloldberg/addon-influxdbv2/
Ich hatte migriert als ich mit meinen PV-Daten noch ziemlich am Anfang war (ich hatte noch weniger als 1 Jahr Daten). Der Link gibt auch einen kurzen Migrationshinweis.
Vielleicht hilft das ja den ein oder anderen.
Mich hat das gleiche Schicksal ereilt wie dich.
Nach einiger Recherche habe ich mich für einen (hoffentlich) extrem zukunftssicheren Weg entschieden:
Ich bin von InfluxDB auf TimescaleDB (eine leistungsstarke Zeitreihen-Erweiterung für PostgreSQL) in Kombination mit Scribe umgestiegen.
Aktuell laufen InfluxDB und TimescaleDB bei mir parallel.
Ich stelle nun Stück für Stück meine Grafana-Dashboards um.
Sobald alles läuft, wird InfluxDB einfach gelöscht.
Falls du den gleichen Weg gehen möchtest, hier mein Setup und wie die Migration der Altdaten klappt.
Um Netzwerkprobleme zu vermeiden, habe ich die Daten mit dem Tool Outflux direkt innerhalb von Home Assistant OS (HAOS) von Docker-Container zu Docker-Container migriert.
Outflux ist zwar schon etwas älter, aber für die alte InfluxDB-Struktur einfach ausentwickelt und läuft grundsolide.
Gerade bei sehr großen Tabellen benötigt InfluxDB bei der Abfrage extrem viel RAM – da ist TimescaleDB deutlich effizienter.
Da das TimescaleDB-Add-on bei jeder regulären Installation die identische interne ID nutzt, lautet der Hostname im Docker-Netzwerk immer 77b2833f-timescaledb.
Der finale Migrationsbefehl im Terminal sieht so aus:
bash
./outflux migrate INFLUX_BUCKET
–chunk-size 1000
–batch-size 1000
–input-server=“http://<INFLUXDB_IP>:8086”
–input-user=“dein_influx_user”
–input-password=“dein_influx_passwort”
–output-connection=“user=POSTGRES_USER password=POSTGRES_PWD host=77b2833f-timescaledb port=5432 dbname=homeassistant sslmode=disable”
–schema-strategy=create-if-not-exists
Nach dem Import wirst du feststellen, dass Outflux die Daten 1:1 spiegelt.
Es entstehen in TimescaleDB einzelne Tabellen, die nach den Einheiten deiner Sensoren benannt sind (z. B. A, V, W, °C…).
Das musst du beim Wechsel beachten:
Die Migration hat zwar ordentlich Zeit gedauert, lief aber absolut fehlerfrei durch.
Das Schöne an diesem Weg ist:
Sollte beim ersten Mal etwas schiefgehen, kannst du die TimescaleDB jederzeit einfach leeren und den Outflux-Befehl neu starten.
Keine Panik vor Datenverlust – durch den Parallelbetrieb geht nichts verloren und es entstehen keine Zeitlücken!
Ergänzung:
TimeScaleDB nutzt eine Komprimierung um massive Speicherpaltz zu sparen(macht influx auch).
Für die aktuellen Daten macht das Scribe alles sauber.
Die alten Daten musst du selber komprimieren.
Mit dem Script werden die komprimierungsregeln für alle hyper_tables erstellt
Das ist der Kern und für die alten Influx Tabellen perfekt. states_raw ist von scibe, der macht das alles selber.
timescaledb.compress_segmentby = ''entity_id'',
timescaledb.compress_orderby = ''time DESC''
DO $$
DECLARE
t text;
BEGIN
FOR t IN
SELECT hypertable_name
FROM timescaledb_information.hypertables
WHERE hypertable_name <> 'states_raw'
LOOP
EXECUTE format(
'ALTER TABLE %I SET (
timescaledb.compress,
timescaledb.compress_segmentby = ''entity_id'',
timescaledb.compress_orderby = ''time DESC''
)',
t
);
END LOOP;
END $$;
Für die Komprimierung habe ich eine Prozedure angelegt die das im Hintergrund gemacht hat.
Ist ja eine einmalige Sache nur für diese Altdaten. Hat bei mir so 93 Prozent komprimiert, war schon echt klasse und ca 2-3 besser als Influx(bei mir).
Scripe macht das mit einer policy die 2 mal am Tag schaut ob was zu tun ist
influx 2 würde ich abraten. Die Firma dahinter (influx data) hat inzwischen influx 3 veröffentlicht und sich von flux verabschiedet und empfehlen selbe sql.
Influx v3 kann kein flux.
Offiziell
An BuFisch
Influx v1 und auch v2 sind vom Herstellerin den Maintenance Mode gesetzt. Nur Pflege, keine Weiterentwicklung, das ist V3.
Und HomeAssistant hat nur reagiert, da InfluxData nix mehr an v1 macht.
Ich habe jetzt drei Tage lang versucht influxdb v3 im proxmox zu installieren und bin kläglich gescheitert.
Ich habe es nicht hin bekommen eine Enterprise Home Version zu lizenzensieren.
Entweder es funktioniert gar nicht oder es wird die Trial Version lizenziert obwohl explizit Home ausgewählt wurde.
Ein Kontakt mit dem Entwickler ist auch nicht möglich, da ich mich auf der Webseite nicht anmelden kann.
Ich gebe jetzt frustriert auf und hoffe dass nicht irgendwann die Datenbank im HA von allein verschwindet.
Ist ja nicht so, dass es keine Alternativen zum InfluxDB geben würde. VictoriaMetrics, TimescaleDB.
Beide wurden hier im Thread ja schon mehrfach gennant.
Gruß Osorkon
Ich habe mich eine Weile mit Gemini unterhalten und habe es von meinem Raspberry 4 auf meinen PC exportiert bekommen. Im Nachhinein recht einfach.
Hier ist die ultrakurze Schritt-für-Schritt-Anleitung für Ihr manuelles InfluxDB-Backup auf dem Raspberry Pi 4b.
Speichern Sie sich diese Befehle für zukünftige Backups ab:
Öffnen Sie das Advanced SSH & Web Terminal und führen Sie nacheinander diese drei Befehle aus:
mkdir -p /share/influxdb_export
docker exec -it app_a0d7b954_influxdb influxd backup -portable /share/influxdb_export
ls -lh /share/influxdb_export
#Aus eigener Erfahrung:
Bei Fehlermeldung: Error response from daemon: No such container: addon_a0d7b954_influxdb
Die Fehlermeldung verrät, dass der Container auf Ihrem System einen leicht abweichenden internen Namen hat.
Da der Supervisor den Namen dynamisch generiert (oft abhängig davon, ob das Add-on mal als lokaler Fork oder aus einem spezifischen Branch installiert wurde),
benennen wir den Befehl einfach um.
Finden wir zuerst heraus, wie der Container bei Ihnen genau heißt, und führen dann den Export durch.
docker ps --format “{{.Names}}” | grep Influx
Dieser Befehl filtert alle laufenden Container nach dem Wort „influx“. Sie erhalten als Ausgabe den exakten Namen
(z.B. addon_local_influxdb oder app_a0d7b954_influxdb oder eine andere Zahlenkombination).
Den “docker exec -it (richtiger App-Name) influxd backup -portable /share/influxdb_export”-Befehl mit dem richtigen App-Namen versehen und erneut ausführen.
Öffnen Sie an Ihrem PC den Netzwerk-Ordner von Home Assistant (VPN aus, über das Samba Share Add-on,
Samba Share muss auf Home Assistant unter Apps installiert und ausgefürt werden).
Kopieren Sie den Ordner “influxdb_export” aus dem Verzeichnis “share” auf die Festplatte Ihres Computers.
Sobald die Daten sicher auf Ihrem PC liegen, löschen Sie den Export-Ordner auf dem Pi im Terminal wieder:
rm -rf /share/influxdb_export
“Und HomeAssistant hat nur reagiert, da InfluxData nix mehr an v1 macht.”
ist ja schön und gut aber bieten keinerlei Alternativen ohne großartigen Aufwand vom User seinen Jahren von Daten zu migrieren, nein einfach platt machen unter dem Motto was gehen uns die Daten der User an sollen zusehen wie sie klar kommen. und das man mit einem Klick der getarnt als Reparatur auf poppt auf einen schlag alles weg und das ist keine Reparatur das ist vernichten von Daten
Ich habe nur auf “was ist eigentlich das Problem mit influx” geantwortet.
Und der Hinweis als Reparatur der die db löscht ist problematisch und wurde daher auch geändert.
Ich hätte mir tatsächlich gewünscht das dieses App stärker als demnächst EOL markiert wird. MIt Warung und Zeithorizont. Theoretisch könnte es sein das beim nächsten größeren Update die APP nicht mehr funktioniert. Das ist nicht gut, auch bei einer Kostenlosen Software.
Deine Erwartungshaltung das HA für dich eine APP in eine andere migriert, kann ich nicht teilen.
HA ist eine kostenlose Software, kein kostenloser Servicedienstleister. Ich hätte mich riesig darüber gefreut. Aber in welche?
Die Migration der Zentralen Datenbank wird von HA bisher sehr gut gewährleistet. Einen Anspruch hat der Nutzer trotzdem nicht.
Auch gibt es sehr gut und einfache Möglichkeiten die InfluxDaten zu migrieren. siehe im Thread.
Also ich habe meine InfluxDB1 Daten als Backup gesichert und in meinem Proxmox kurzerhand einen neuen Container hochgezogen, dort ebenfalls InfluxDB1 installiert und das Backup dort importiert. Damit habe ich alle meine Daten in einem neuen System, über welches ich die Hoheit habe. Hier wurden allerdings schon ein paar Stunden fürs lesen und verstehen investiert.
Wer versehentlich auf o.k. geklickt hat, seine Daten damit gelöscht hat, hätte ja auch jederzeit ein Backup einspielen können. Wie heißt es so scjön “Kein Backup, kein Mitleid”
Die App hätte drin bleiben können mit verweis drauf das V1 keine Unterstützung mehr erhält statt Sie einfach rauszuschmeissen
Aber eine Veröffentlichung zu diesem Thema und was mit den Daten geschieht hätte man eventuell machen könnte und es wäre niemanden ein Zacken aus der Krone gebrochen so hätte jeder schauen können wie er es macht.
Das hat nichts mit Open Source oder Kostenlose Software zu tun das hat was mit Umgang seinen Benutzer zu tun.
und hinterher, wenn das Kind im Brunnen liegt, hilft es dem Kind auch nicht wenn es im Brunnen liegt.
Und was spricht den dagegen das Influx weiter besteht?, lief und läuft anstandslos und hat nie mir Ärger gemacht oder gezickt.
Ich bin nun auf Victoria Metrics umgestiegen. War ein wenig Aufwand mit der Migration, aber nun läuft es auf dem rPi4 und alles ist erst mal gut.
Das habe ich auch, habe halt 6 Tage Daten PV/Wasser/Heizung + Heizölverbrauch verloren weil ich nur Sonntags immer um 20:00 Full-Backup mache und kein inkrementell Backup machen kann.
Ich frage mich halt was schlecht an der 1.80.10 schlecht sein soll.
Die Reparaturmeldung besagt ja nur, dass die App nicht mehr weiterentwickelt wird und somit auch keine Aktualisierungen mehr erfolgen. Das ist eine Standmeldung. Sie funktioniert ja erstmal weiter, außer man löscht diese.
Es ist also jedem einzelnen überlassen, alles so belassen wie es ist. Oder sich nach alternativen umzuschauen.
Gruß Osorkon
Bin komplett bei dir, das entfernen war Müll und mit Sicherheit so nicht gewollt, daher auch die sofortige Änderung. Influx tut es ja weiterhin, läuft tadellos bei mir.
Es sind unnötige Dinge komplett zusammengefallen. Das sollte das Team unbedingt ändern.
Die ersten beiden sollten mit einem ordentlichen Zeitlichen Versatz auftreten. Das löschen gar nicht.
Danke für diese ausführliche Erläuterung und für mich sehr akzeptable Lösung! Werde ich, wenn Zeit dafür ist, direkt umsetzen! Für mich aktuell auch die zukunftsorientierteste Lösung.. 
Ich lese nun schon ein Moment mit.
Mit dem Update auf 2026.9.0 konnte die Meldung nun ignoriert werden. Somit besteht die Gefahr, die InfluxDB zu löschen nicht mehr so einfach.
Ich bin nun auf mariaDB umgestiegen. Passt für mich und funktioniert. Es gab ein paar Stunden Arbeit alles in Grafana zu visualisieren, zumal dort anders programmiert wird als mit InfluxDB. Aber sobald man das Grundgerüst des SQL-Codes hat, geht es dann mit kopieren und anpassen recht schnell. Als Hilfe nahm ich eine KI.
Das heißt ich kann mal gefahrlos auf 2026.9.0/1 wechseln ohne das InfluxDB gelöscht wird und ich meine Langzeitdaten verliere? Seit ich die Warnung mit EOL bekomme habe, habe ich nämlich keine Updates mehr gemacht.
Ja, kannst du.
Im Zweifelsfall hilft lesen bevor man klickt. Es wurde nichts automatisch entfernt, dies geschah immer durch die Zustimmung des Anwenders.
Lieben Gruß Christopher
SO, ich habe mich gestern auch an die Umstellung auf TimescaleDB und die Migration der Daten gewagt. Dabei habe ich festgestellt, dass scribe ein eigenes Skript (siehe Doku) mitbringt um die Daten aus Influx direkt in scribe und die damit verbundenen Datenstruktur zu migrieren. Das lief tatsächlich problemlos durch und die Daten sind direkt, ohne nachträgliches Zutun in der TimescaleDB gelandet. Dauert je nach Datenmenge natürlich seine Zeit aber lief sauber im Hintergrund durch.
Weißt du, ob die Influx-Daten direkt durch das Entfernen der Integration / App entfernt werden? Oder muss man hier noch manuell Hand anlegen um die Datenbank sauber zu entfernen?