openhabforum.de

Hallo Liebe Community,

Ich hab natürlich bereits die bestehenden Beiträge etwas durchforstet, bin aber entweder nicht schlau daraus geworden oder es waren so viele Antworten dass ich gefühlt ewig lesen müsste um dann evtl. festzustellen dass ich auch nicht die richtige Antwort finde...

Falls bereits passende Antworten verfügbar sind bin ich auch für Hinweise auf andere Foreneinträge dankbar.

Zu meiner Erfahrung mit Openhab:
Ich verwende zZt. Openhab 5.0.0 via Openhabian auf einem RaspberryPi 5 mit 8GB RAM;
gestartet habe ich damals mit Openhab 3;
Mein Haus habe ich mittlerweile gut in Openhab abgebildet (KNX Anbindung (Licht, Verdunkelung), alter Scheitholzkessel via Modbus-Seriell, einige Tapo Strommesssteckdosen, Telegram Benachrichtigungen, Chromecast Wiedergabegeräte, Denon Heimkinoreciever,...)

Womit ich keine bzw. wenig erfahrung habe sind Datenbanken, bzw. Persistence.


Zu meinem Problem:
Am besten sieht man es in angehängten Screenshots von einem Chart der Temperaturen meines Warmwasser Pufferspeichers.

Wenn ich mit der Maus "darübergleite" sollte man eigentlich den aktuellen Wert aller Datenpunkte zu dem jeweiligen Zeitpunkt sehen, leider gibt es anscheinend nicht bei jedem Datenpunkt zur gleichen Zeit einen Wert, daher kann ich nicht zu jedem Zeitpunkt die Werte vergleichen.

Außerdem kann es passieren das wenn ich einen Zeitbereich im Chart wähle in dem es an einem Datenpunkt keine Werte gibt, ich gar keine Linien sehe, oder zumindest keine durchgängigen Linien.

Des weiteren bin ich mir nicht sicher ob RRD4J irgendwann ältere Werte zusammenfasst (das hab ich irgendwo mal gelesen) also aus einigen 5-Minuten-Werten z.B. einen Stundenwert abspeichert. Dies möchte ich eigentlich auch vermeiden.

Ziel soll es sein dass die Temperaturen bei jeder Änderung und fix zu jeder vollen Minute einen Wert abspeichern und diese Werte für die Ewigkeit gespeichert werden um Konsistente Linien in den Charts zu erhalten und auch nach (z.B.) einem Jahr Aufzeichnung die genauen Werte vom Vorjahr verkgleichen kann.

Mit der Bitte um Unterstützung wünsche ich euch einen schönen Nachmittag!
Besten Dank und freundliche Grüße
Philipp

Also, Persistence...

Eigentlich kein Hexenwerk, aber wie immer liegt der Teufel im Detail.
"Eingebaut" in openHAB gibt es

• MapDB - speichert exakt einen Wert mitsamt Zeitstempel; gewöhnlich nur für restoreOnStartup interessant
• rrd4j (RoundRobinDatabase for Java) - speichert die Daten in einer Datenbank fixer Größe, der jeweils älteste Wert wird automatisch gelöscht, wenn ein neuer Wert hinzu kommt. Um sowohl eine möglichst lange Historie als auch eine überschaubare Dateigröße zu erreichen, werden die Werte abhängig vom Zeitraum gemittelt. Die Standard Konfiguration nutzt dabei fünf "Buckets", und zwar mit einer Granularität (G) von 10 Sekunden für die vergangenen 60 Minuten, G von 1 Minute für die vergangenen 7 x 24 Stunden, G von 15 Minuten für die letzten 365 Tage, G von 1 Stunde für die letzten 5 Jahre und G von 24 Stunden für die letzten 10 Jahre.
  Die Datenbank kümmert sich selbsttätig darum, die Werte zu berechnen, zu speichern und zu löschen. Vorteil ganz klar, die fixe Dateigröße. Als openHAB startete, war die einzige sinnvolle Anwendung die Erzeugung von Charts, wobei die rechte Seite des Charts immer "jetzt" symbolisierte. Somit konnten für lange Zeiträume auch nur Mittelwerte über verschieden lange Intervalle dargestellt werden, weshalb rrd4j ideal geeignet war.
• InMemory soll nicht unerwähnt bleiben, jedoch ist diese Datenbank flüchtig, d.h. sie verliert ihren Inhalt bei einem Neustart. Damit scheidet sie als Langzeitspeicher aus

Sollen die Daten über lange Zeiträume in hoher (zeitlicher) Auflösung gespeichert werden, bleibt also nur eine externe Datenbank. Dort hast Du eine große Auswahl, weil Du ja vielleicht schon eine Datenbank nutzt
Grob kann man hier zwischen drei Datenbanktypen unterscheiden, nämlich die Cloud-Variante (Amazon DynamoDB), die auf Messwerterfassung und Auswertung spezialisierte Variante (InfluxDB) und als große Restmasse die SQL-artigen Datenbanken (wobei damit eigentlich relationale Datenbanken gemeint sind, die werden hier über JDBC angesprochen, am bekanntesten dürften hier PostgreSQL und MySQL sein.
Die SQL Variante speichert traditionell die Daten "wie sie rein kommen" und "auf ewig", es sei denn, man richtet selbst entsprechende Routinen ein, die die Daten regelmäßig bereinigen.
Und das ist schon ein wichtiger Punkt, meine gesammelten Daten (nur openHAB) umfassen beispielsweise momentan knapp 3 GByte, dazu kommen über 6 GByte von meinen Stromzählern (dort habe ich Messwerte zum Teil im Sekundentakt seit ~ 2017) sowie etwa 6 GByte epg Daten für das Fernsehprogramm (incl. Bildvorschau) - die epg Daten werden dabei automatisch bereinigt, denn die 6 GByte sind nur zwei Wochen Programm...

Wenn es um wenige Messpunkte geht, die über einen langen Zeitraum vorgehalten werden sollen, ist die SQL-Variante sicher gut geeignet, weil die Datenmenge dennoch überschaubar bleiben wird - etwa 526.000 Messpunkte pro Jahr bei einem Messwert pro Minute. Allerdings müssen auch solche Datenmengen erst mal eingelesen werden, wenn man Datenabfragen auslöst - ein weiterer Grund für RRD-Varianten, weil die Abfragen typischerweise recht flott bearbeitet werden, egal wie lang die betrachteten Zeiträume sind.

InfluxDB kann man als Kompromiss zwischen rrd4j und SQL betrachten, diese Datenbank ist spezialisiert auf Messwerterfassung, sie ist "rasend schnell", auch mehrere tausend Messwerte pro Sekunde können von vergleichsweise kleiner Hardware leicht verarbeitet werden, auf einem Pi5 sollte InfluxDB ausreichend performant auch für wirklich große openHAB Installationen mit vielen Messpunkten sein.
Die Messwerte werden in "Buckets" vorgehalten, ähnlich rrd4j, allerdings kann man ein Bucket auch als "unendlich" definieren, also so dass keine Messwerte gelöscht werden. Die Physik kann InfluxDB aber auch nicht austricksen, je mehr Daten für eine Abfrage genutzt werden, umso länger dauert die Abfrage, wenn auch wesentlich kürzer als bei den SQL-Varianten. Auch bei InfluxDB kann man mehrere Buckets definieren und InfluxDB beauftragen, automatisch reduzierte Datensätze zu erstellen (z.B. Mittelwerte über x Messwerte usw.) Allerdings muss man das dann auch selbst konfigurieren.

InfluxDB war früher ein Muss, wenn man die Daten mit Grafana visualisieren wollte. Inzwischen kann Grafana aber auch mit diversen anderen Datenquellen umgehen, auch MySQL, wenn auch nicht so flott wie mit InfluxDB.

Bei jeder externen Datenbank kommt Arbeit auf Dich zu und eine gehörige Portion Wissen, welches darauf wartet, dass Du es Dir aneignest. Ohne Letzteres wirst Du mit hoher Wahrscheinlichkeit früher oder später scheitern, was dann schon sehr ärgerlich sein kann, wenn es (Datenverlust) "später" passiert

Da ich momentan kein openHABian System aufgesetzt habe, bin ich nicht sicher, ob dort neben InfluxDB auch MariaDB zur Auswahl steht - MariaDB ist ein Fork von MySQL, der kompatibel mit der GNU GPL ist. Deshalb kann man MariaDB direkt mittels apt installieren - im Gegensatz zu vielen anderen DB-Lösungen, bei denen man meist externe Paketquellen einbinden oder gar eine Entwicklungsumgebung einrichten muss.

Meine Empfehlung ist hier tatsächlich MariaDB, wobei, wie erwähnt, ein par Dinge wirst Du erst lernen müssen, um erfolgreich damit arbeiten zu können.
Es gibt mit phpMyAdmin ein Webfrontend für MariaDB, von welchem ich aber abraten möchte. Ich setze seit etlichen Jahren HeidiSQL ein, das ist ein SQL Client, der nativ auf Windows installiert werden kann und alle Funktionen bietet, die mit phpMyAdmin zur Verfügung stehen. Man benötigt aber keinen Webserver für den Betrieb Pferdefuß: MariaDB beschränkt als default den Zugriff auf localhost, das muss man zunächst ändern. Auch einen User mit entsprechenden Rechten muss man erst einrichten, und das geht gewöhnlich nur über das CLI. Wie erwähnt, Du musst Dir dafür einiges an Wissen aneignen.
Steht erst mal die Verbindung zwischen MariaDB und HeidiSQL, kannst Du alle administrativen Aufgaben recht komfortabel über HeidiSQL erledigen - z.B. komplexe Abfragen erstellen, um Daten zu entfernen oder anderweitig auszuwerten.