HA Recorder, SQLite, InfluxDB, Grafana

[gbglace]

PostgreSQL+ Timescale und ingest direkt aus MQTT Broker.

Auch der KNX Adapter-Teil in Telegraf hat keine Zukunft mehr im Support. Und wer bitte will da schon für jede GA irgendwelche Regeln ins Telegraf basteln.

[tsb2001]

Also ich wollte die Daten von der Influx-DB auf die Version 2 oder 3 hochziehen.
Ich habe die Daten aus dem Backup extrahiert (mittlerweile 6GB groß) und dann mittels zeilenbasiertem Export einen Tag (24 Stunden) zum importieren generiert. Der eine einzige Tag erzeugte eine Datei mit 79GB und meine Platte war schlagartig voll.
Ich habe dann einfach im NAS im Docker die Influx-dB in Version 1.8 aufgesetzt, die Daten da ohne Migration reinkopiert und die Konfiguration vom HA auf den Docker-Container umgebogen.
Das ist zwar auch keine Lösung auf ewig aber hat nur 1 Stunde gedauert und alle Daten sind noch da. Neue werden einfach weiter angehangen.
Wenn ich mal viel Zeit habe, versuche ich mich mal an der Streaming-Methode zur direkten Migration von 1 auf 2.

[r4id]

PostgreSQL+ Timescale[...]

Bin auch gerade am grübeln das über PostgreSQL+ Timescale zu machen. Ich seh den Vorteil, dass man HASS auch gleich auf PostgreSQL schreiben lassen kann.
Hast du die HASS-DB (SQLite) umgestellt?

[...]ingest direkt aus MQTT Broker. Auch der KNX Adapter-Teil in Telegraf hat keine Zukunft mehr im Support.Auch der KNX Adapter-Teil in Telegraf hat keine Zukunft mehr im Support.

Welcher Broker unterstützt das direkte pollen in eine Datenbank? Bei Mosquitto geht es ohne Telegraf nicht.
Eventuell kann es der EMQX Broker?

Meine Wärmepumpe spricht MQTT. Mein Wechselrichter und meine Lüftung ModbusTCP. Ein paar Stromwerte usw. aus KNX-GAs möchte ich auch speichern.
Hast du eine Empfehlung wie ich das dann ohne Telegraf umsetzen kann?

[r4id]

Ich würde heute das VictoriaMetrics Add-On (sorry, App) verwenden

Ich finde direkte Datenbank-Apps in HA immer etwas ungünstig, auch wenn sie einfach zu konfigurieren sind.
Bei einem HA Neustart entstehen immer Lücken in der Datenbank.

[xnet]

InfluxDB 1.x & 2.x sind am Ende
InfluxDB 1.x wird seit Längerem nicht mehr weiterentwickelt. Nun trifft InfluxDB 2.x dasselbe Schicksal: Die aktive Entwicklung wurde weitgehend eingestellt, und auch die Abfragesprache Flux wird von InfluxData nicht mehr gepflegt.

InfluxDB 3.x setzt wieder voll auf SQL
Die neue Engine (InfluxDB 3.0) unterstützt Flux überhaupt nicht mehr. Stattdessen kehrt der Hersteller vollständig zu standardisiertem SQL (und InfluxQL für Legacy-Abfragen) zurück.

Starke Open-Source-Einschränkungen
Durch angepasste Lizenzmodelle und beschnittene Open-Source-Varianten (z. B. fehlende automatische Datenkomprimierung/Compactor-Services oder eingeschränkte Langzeitspeicherung) ist InfluxDB 3.0 für viele Community- und Hobby-Projekte unattraktiv geworden.

Bewährte Alternativen:

• TimescaleDB: Starke, auf PostgreSQL basierende Zeitreihendatenbank.
• VictoriaMetrics: Extrem ressourcenschonend, performant und einfach zu betreiben.
• SQLite / MariaDB: Ausreichend und pflegeleicht für leichtere Anwendungsfälle (z. B. Smart Home).