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).

[Tom Bombadil]

Hinweis: Das InfluxDB Add-on wurde heute Morgen durch Frenck 'un-deprecated' (ist das ein gültiges Wort?), nachdem die Jungs von InfluxData direkt Kontakt zum HA Core Team aufgenommen haben. Es bestehen wohl keine Pläne seitens InfluxData, den 1.x Support in absehbarer Zeit einzustellen. So zumindest das offizielle Statement. Damit ist der Hauptgrund für die deprecation eigentlich hinfällug.

Details hier auf Discord: https://discord.com/channels/3309442...93427031515188

/tom

[r4id]

Zumindest wird v1 ja immernoch fleißig gepflegt https://github.com/influxdata/influx...elease-v1.13.1

https://endoflife.date/influxdb

[Tom Bombadil]

Ja, hatte Cole als Vertreter von InfluxData auch geschrieben:

InfluxDB v1 is still getting routine updates - it had one at the end of July, and there will be more coming down the line.

Und:

we've had a lot of users in our community confused and concerned about the deprecation of the InfluxDB v1 addon.
[...]
The abrupt deprecation of something connecting two actively-supported technologies is leaving a ton of users high and dry with no clear solution for where they should go or what they should do, and that's really not great for anyone.

Da lief wohl der Draht vor lauter User-Anfragen heiss ...

/tom

[gbglace]

Hast du die HASS-DB (SQLite) umgestellt?

Ich habe gar kein HA / HASS produktiv am Laufen.

Eventuell kann es der EMQX Broker?

Genau der kann das.

Ich habe da einige Rules gebaut die mir erstmal alles grob in einem JSONB Format in je Quelltechnik/Gerät in eine Tabelle schreibt (Schema raw). dann sind auf der Datenbank trigger die diese JSONB auseinander nehmen und ggf gleich noch passende Umrechnugnen machen (aus W >> Wh) und damit quasi normieren. Das landet wieder in einem Schema. Ein weiterer CRON trigger in der Datenbank baut dann aus diesen normierten Daten die eigentliche Timeseries Tabelle mit den automatischen Aggregaten. da werden dann gerade solche Sachen wie Energiewerte auf 15-Minuten Aggregate aufbereitet. Die Aggregation ist da quasi eine Art View.
Je nach eingestellten Retentions habe ich so automatisch eine endlose Historie in 15 Minuten Zeitfenster normiert auf Senkunde 0. Und auf den letzten 2 Tagen davon die Dichte der Rohdatenzykliken um in einem Chart auch mal tiefer zu schauen in Sekunden. Aber das interessiert mich nur für die letzten 2 Tage. Danach reichen die Abrechnungsrelevanten 15-Minuten. Die JSONB Roh Daten bleiben 30 Tage in den raw Tabellen, um Fehler nachvollziehen zu könenn und ggf einzelne Werte zu löschen und dann die Folge Kette neu rechnen zu können.

So habe ich aus meinen Energiedaten sehr viele abgleitete kWh Daten erzeugt um wirklich alle Kanten die sich aus einer Kombination Netz-Anschluss, Speicher, diverse AC-PV-WR, 2 Haushalte, DC-PV WR, zu berechnen inkl. der Verlustleistungen der verschiedenen WR. Mit HA fehlt mir jedwede Vorstellung wie ich das da berechnen sollte mit den Logiken, weil rein auf Eventbasierten Datenpunkte lässt sich das alles nicht sauber berechnen. Und mit den Zahlen muss da im Grafana nix berechnet werden. jede Kante liegt direkt als Datenpunkt in der Tabelle vor und alles schön zu einem Zeitstempel nebeneinander. Und Energiewerte eben in anderen Tabellen als Temperaturen. usw.

Viele Lösungen sind leider meist eine relativ schmale Timeseries und dann hast sehr viel Logiken im Select beim Weg auf den Bildschirm.

Postgress kannst auch per API vollständig von der Ki bedienen lassen wenn man sich den Aufbau der Berechnungen und Views und sonstigem nicht nativ direkt zutraut.
Ich lasse mir das mittlerweile per lokaler KI bauen. und die KI baut auch direkt passende Dokus aus allem was da gebaut / verformelt wird. Parallel pflegt die Ki auch alle Datenbank Artefakte in einem lokal gehosteten Repo. Github ist schön, aber nicht meine privaten auf mich abgestimmten Formeln.

Mein Wechselrichter und meine Lüftung ModbusTCP. Ein paar Stromwerte usw. aus KNX-GAs möchte ich auch speichern.

mein Modbus-TCP Fronius WR liefert die relevanten AC Werte direkt ans Victron GX Device, Victron schickt mir alle Datenpunkte alle 2 Sekunden per MQTT in einer Message in einem JSON. Die DC-Werte und ein paar Stammdaten hole ich mir mit NR aus dem Fronius und pushe die unterteilt nach hochfrequenten Daten (5Sekunden) und eher statischen Daten per MQTT weiter.

Meine diversen Modbus-RTU Stromzähler gehen über ein Waveshare Modul auf MQTT.

Der KNX-Bus geht derzeit noch per einem KNX_Ulitmate Node decodiert 1:1 jedes Telegramm an MQTT.

Ja man könnte auch in NR ein Ingest bauen aber so ist mir das einheitlicher alles auf MQTT und KNX via NR auf MQTT will ich noch durch etwas anderes erstzen.
Da hoffe ich das z.B. eines der neuerlichen KNX-Monitor Projekte auch einfach etwas anbieten, die ETS Projektdatei einzulesen und dann die vollständig dekodierten Telegramme, die sonst in voller Breite in deren Busmonitoren erscheinen, als JSON auf MQTT einfach weiter reichen. Dann hätte ich damit einen schicken KNX-Monitor der das was er eh tut auch einfach ans MQTT weiter reicht.

In meiner Datenbank per MQTT Gefüttert, habe ich dann alle Möglichkeiten und Freiheiten das für Endlos aufzubereiten und bin recht unabhängig vom eigentlichen Lieferanten.

Für meine Viessman Heizung habe ich die vcontrold Beispiele von der KI anpassen lassen und um einen MQTT Adapter erweitern. Damit kommen die auch decodiert in der Datenbank an.

Alles was ich mir so für Dashboards an Werten ausdenke bilde ich dann schon lieber als SQL Code/Function in der Datenbank ab. dann ist es auch egal ob das mal in Grafana oder sonstigen Systemen Visus ausgegeben werden soll, weil das dann auf den Tabellen im Reporting Shema recht simple SQLs sind und da keine großen Konvertierungen mehr notwendig sind.


PostgreSQL und Timescale sind schon ein ziemlicher Brocken. Aber das Ding beherrscht mittlerweile nicht nur Timesereis und realtionale Daten, auch eben sowas wie die JSONS und Grafen Systeme werden möglich. Damit kannst Dir ein einer zentralen instanz für dein gesamtes Smarthome auch ein umfangreiches Metadaten universum pflegen.
Wenn Du dann eine KI gegen diese Datenbank schickst und im repo die Doku und DDLs vorliegen, dann beantwortet Dir da auch jedes realtiv kleine LLM lokal interessante Fragen zu Deinem Smarthome und was da so passiert.

Ich bleibe damit insgesamt recht modular und bei spezialisierten Tools.
Die gut allein klarkommen und prinzipiell austauschbar bleiben.

Ist aber auch etwas mehr Aufwand als ein HA aber mit dessen Logiken usw. kann ich mich noch nicht so recht anfreunden. und selbst wenn die KI das Ding voll bedienen kann, hilft es mir ja nicht wenn ich es selbst nicht auch verstanden habe wenn ich da durchs HA ui mich klicke. Bei SQL basierten Plattformen bin ich halt diesntlich zu hause und komme damit gut klar.
Wenn ich SQL Code sehe spricht das quasi mit mir.

Und die Rules im EMQX sind auch alles sehr an SQL angelegt. Damit kann ich das alles beim lesen auch schnell verstehen was das tut.

Sorry falls das bissl OT ist.

[scw2wi]

Sorry falls das bissl OT ist.

bissl?