[gelöst] ist das wirklich Tatsache, dass OPENhab keine brauchbare Möglichkeit bietet um Diagramme anzuzeigen?

[franzda]

ist das wirklich Tatsache, dass OPENhab keine brauchbare Möglichkeit bietet um Diagramme anzuzeigen?

Was ist mit HABmin Diagramm Editor. Sollte das nicht dafür geeignet sein? (läuft aber im Moment gar nicht)

Soweit ich gesehen habe sollte Grafana auch mit mysql funktionieren oder nicht?

[hurra]

Für einfachste Diagramme ist das schon Brauchbar mit rrd4j- aber Ansprüche darfst du keine haben

Ich hatte bis vor kurzem auch nur mit den einfachen Darstellungen gearbeitet, bin jetzt bei Grafana mit InfluxDB und es sind hinsichtlich Optik, Einstellmöglichkeiten und der Darstellungsweise Welten dazwischen!!

[franzda]

Brauchbar für mich ist nicht nur Daten Anzeigen: sondern Zeiträume ändern können und automatische Aktualisierung ist Mindesterwartung. (HABmin wäre ok läuft aber z.Zt. nicht)
ich nutze openHAB 2.5.2 Release Build ist dein Vorschlag dafür geeignet und läuft stabil?
Warum wird überall im Netzt InfluxDB als Vorasusetzung genannt?
Hat ggf InfluxDB bestimmte Vorteile gegenüber mysql?

ich habe mich für mariaDB / mysql aus mehreren Gründen entschieden!
Überall lese ich dass GRAFANA mit InfluxDB eingesetzt werden soll. Aber habe auch gesehen dass mysql funktionieren soll.

ALSO: zusätzliche Pakete, Abhängigkeit was eine gewisse Gefahr bietet Wechselwirkungen zu bekommen.

[hurra]

bei 2.5 ist Grafana und InfluxDB schon implementiert. Ich kann mich nicht mehr genau erinnern, wie du die Installation anstößt, aber danach ist auf jeden fall schon die DB in Grafana verknüpft und du kannst loslegen. Ziemlich komfortabel ...! Zeiträume kannst du wählen, wie es dir gefällt!

[udo1toni]

bei 2.5 ist Grafana und InfluxDB schon implementiert.

Nein.

Was hurra meint, ist, dass in openHABian-config schon eine Option vorgesehen ist, Grafana und InfluxDB nachzuinstallieren.

Also grundsätzlich: In openHAB integriert ist in Basic UI eine sehr einfache Darstellung, die aber erstaunlich oft ausreichend ist. Dazu dient das Chart Widget.
Vorteil: Man muss nur die Persistence für die Daten installieren, alles andere geht "von selbst". rrd4j bietet sich hier an, da es eine fixe Dateigröße pro Item aufweist, man bekommt also keine Platzprobleme.
Man kann recht einfach den Zeitraum beeinflussen (letzte Stunde, letzte 4 Stunden, letzter Tag, letzte Woche, letzter Monat...), aber man ist ansonsten sehr eingeschränkt. Die Charts werden automatisch aktualisiert, die Rate kann selbst gesetzt werden.

Wer optisch mehr möchte, muss auf andere Produkte ausweichen. Grafana ist schon seit vielen Jahren als Option bekannt. Dabei konnte Grafana ursprünglich nur mit wenigen Datenquellen umgehen, InfluxDB war die "beste" Datenquelle, (My)SQL stand überhaupt nicht zur Verfügung.

InfluxDB ist auf Messreihen spezialisiert und optimiert, die Engine bietet verschiedene Möglichkeiten, die Daten abzufragen, zu bearbeiten und auch automatisch zu löschen (auch hier wird also aktiv verhindert, dass die Datenmenge zum Problem wird - vorausgesetzt, man nutzt die entsprechenden Funktionen)

Grafana funktioniert in der aktuellen Version auch gut mit (My)SQL, allerdings kommen die Daten tendenziell langsamer als aus influxDB (ich habe beide DB Engines in getrennten VM laufen, ebenso Grafana, der Zugriff erfolgt bei mir also in beiden Fällen über Netzwerk, so dass kein System direkte Vorteile hätte. Trotzdem scheint mir InfluxDB schneller zu sein.) Weiterhin hat man mehr Konfigurationsaufwand, denn man muss die Statements mindestens teilweise händisch anpassen, während man für InfluxDB nur das gewünschte Item auswählen muss. (alle anderen Konfigurationen müssen für beide Datenbanksysteme gleichermaßen vorgenommen werden, also z.B. die Anbindung der DB, Gestaltung der Grafen usw.)

Die Einbindung von Grafana in eine Sitemap ist nicht so geschmeidig wie das Chart Widget, es geht aber auch. Es gibt eine Einschränkung, wenn man extern auf openHAB zugreift (also z.B. über myopenhab oder über einen reverse proxy), dann wird Grafana nicht dargestellt. Einziger Ausweg ist dann, direkt auf Grafana zuzugreifen. Auch die Darstellung von Grafana wird automatisch aufgefrischt.
Ich persönlich habe Grafana nicht in openHAB eingebunden sondern nutze Grafana "standalone" in einem getrennten Tab.

[timo2811]

Hallo udo1toni,
hat man bei der Nutzung von Charts mit Persistence und rrd4j zu befürchten, dass der Speicherplatz des Raspi voll läuft?
Beispielsweise wenn man 5-minütlich Temperaturwerte über einen Zeitraum von einem Monat oder sogar Jahr aufzeichnet?
Muss man den Speicher manuell leeren?

Gruß
Timo

[udo1toni]

Nein, rrd4j ist eine RoundRobin Liste. Die Werte müssen zwingend im Minutenabstand gespeichert werden, da sonst der Graph nicht korrekt gerendert wird. Zusätzliche Speicherpunkte mittels everyChange sind aber in Ordnung.
Die RoundRobin Liste speichert die Werte und dünnt sie automatisch aus. Beispielsweise sind die Werte der letzten 24 Stunden in Minutenauflösung abrufbar, während die Messwerte der letzten 7 Tage (also vor den letzten 24 Stunden...) nur in 5-Minunten-Mittelwerten zur Verfügung stehen. rrd kümmert sich selbst darum. Je länger ein Zeitpunkt her ist, desto ungenauer wird die zeitliche Auflösung.
Der Speicherplatz pro Item ist dabei fix und nur abhängig von der Konfiguration der Auflösungsstufen. Die genaue default Konfiguration habe ich nicht im Kopf, also welche Stufen zu welchen Zeitpunkten Daten ausdünnen.

Die Werte lassen sich in rrd nur ein Jahr aufbewahren, danach werden sie wieder überschrieben. rrd ist an dieser Stelle sicher auch konfigurierbar, aber die Charts lassen noch größere Zeiträume als ein Jahr nicht zu. Dafür müsstest Du dann auf jeden Fall zu Grafana oder einer anderen externen Lösung greifen. Grafana ist halt ganz gut integrierbar und es gibt umfangreiche Erfahrungen und Dokumentation (im Zusammenhang mit openHAB) dafür.

Grafana kann auch mit anderen Datenbanken als influxDB arbeiten, aber influxDB ist wiederum exakt auf die Anwendung hin optimiert, Messreihen zu erfassen. Es ist sehr schnell und kann notfalls tausende Messwerte pro Sekunde aufzeichnen. Auch influxDB kann so konfiguriert werden, dass es die Daten selbsttätig bereinigt. Hier geht es aber ausschließlich um das Löschen alter Daten, nicht um das Ausdünnen, wobei man influxDB wohl auch ähnlich konfigurieren kann (ist aber aufwändiger, man muss verschiedene Retention Policies verwenden und das alles selbst konfigurieren).
Im Gegensatz zu rrd4j kann eine influxDB die Platte/SD-Karte tatsächlich füllen, das sollte man immer im Hinterkopf haben.

[timo2811]

Danke für die ausführliche Erklärung.

[KlausGünther]

Im Gegensatz zu rrd4j kann eine influxDB die Platte/SD-Karte tatsächlich füllen, das sollte man immer im Hinterkopf haben.

Ist das nicht nur ein Problem wenn man wirklich viele Werte über sehr lange Zeit speichert und z.B. einen RPi mit einer kleinen SD-Karte nutzt ?

[udo1toni]

Wearout ist ein grundsätzliches Problem von Flash Speicher, egal ob nun SD-Karte, USB-Stick oder SSD. Im Unterschied zu SD-Karte oder USB-Stick haben SSDs aber sehr ausgeklügelte Mechanismen eingebaut, um das Wearout möglichst gleichmäßig auf den gesamten Speicher zu verteilen - logischerweise werden dabei aber zusätzliche Schreibzugriffe nötig

Es gibt vereinzelt USB-Sticks mit einem speziellen Controller, der so arbeitet wie die SSD-Controller. Erkennbar sind diese USB-Stickt an ihrem exorbitant hohen Preis bei vergleichsweise geringer Kapazität.

Natürlich spielt auch die Art des Speichers, SLC, TLC, QLC... eine große Rolle. Je größer die Kapazität, desto weniger Schreibzugriffe wird das Speichermedium auf die einzelne Speicherzelle bezogen vertragen.

Das Hauptproblem beim Wearout sind dabei aber meist nicht die Datenbanken, sondern das Log (davon gibt es nicht nur das von openHAB).

Die wachsende Größe von Datenbanken wird eher zum Problem, weil irgendwann der Platz auf dem Medium knapp wird.