LoxBerry: Statistik Plugin - Diskussion

[Gerrit]

Hab den ELK Stack auch schon in verschiedenen Projekten eingesetzt. Curator hilft dir nur wie du schon schreibst um Daten komplett zu löschen, aber nicht wie RRD normalerweise entsprechend nach gewissen Zeitabständen zu aggregieren und die Ursprungswerte zu löschen. Beim Strom, Wasser-verbrauch oder PV Anlagen Erzeugung etc. möchte man aber schon Jahre vergleichen. Daten dann doppelt vorzuhalten ist nicht effizient (weil bei PV etc.interessieren dich auch aktuelle Werte in feinerer Auflösung) und kostet Performance. Das ist auch etwas was Loxone auf jeden Fall verbessern müsste.

Ich glaub auch dass ELK einfach zu anspruchsvoll für den Raspi sein wird, insbesondere wenn man ja auch noch andere Dinge darauf laufen lassen will. Viel Daten im RAM cachen geht wegen wenig RAM nicht und SD Karte ist auch im Vergleich zur normalen Festplatte (nicht SSD) im Nachteil.

[Prof.Mobilux]

Also ich habe das Wochenende genutzt um mich ein wenig mehr mit dem RRDTool zu beschäftigen und mich ein wenig einzulesen. Ich bin wirklich begeistert und werde RRD für das Plugin als Datenbank verwenden.

Nun ist es ja so, dass man zum Zeitpunkt der Erstellung der Datenbanken schon sehr viele Vorgaben bzgl. Speicherintervall, Archive, etc. machen muss. Die meisten davon sind später nicht mehr änderbar. Das wird einen Laien mit Sicherheit überfordern (ich habe auch mehrere Anläufe gebraucht, bis ich Step, Heartbeat, RRA, PDP, CDP, XFF usw. voreinander bekommen habe).

Ich möchte daher beim Anlegen der Datenbanken für den Laien sinnvolle Vorgaben machen, die aber dann natürlich per "Expertenmodus" überschrieben werden können.

Christian Fenzl Du hast ja schon Erfahrung mit den RRD-Datenbanken. Kannst Du etwas zu sinnvollen Vorgaben sagen? Wäre das abhängig vom gewählten Erfassungsintervall? Oder besser von der Art des erfassten Messwerts (Temperatur, Energie, etc.)? Auch stelle ich mir die Frage ob man nur Mittelwerte ins Archiv schreibt oder auch gleich Min/Max-Werte.

Ziel müsste es sein Vorgaben zu finden, die einen vernünftigen Kompromiss zwischen Speicherbedarf und Auswertemöglichkeiten bilden und für möglichst viele User brauchbar sind (alle wird man nicht unter einen Hut bekommen und "Experten" können nach herzenslust anpassen).

Ich habe dazu im Netz eunen RRD-Calculator gefunden, mit dem ich schon etwss rumgespielt habe. Die häufigsten Erfassungsintervalle werden sicherlich 1, 3, 5, 10, 15, 30 ,60 Minuten auf dem LoxBerry sein.

[Christian Fenzl]

Hallo Michael,

das gleiche Excel hab ich auch verwendet :-)

Was du dir beim Excel noch dazumachen solltest, ist die Datengröße. Jeder Datenpunkt ("rows") benötigt 8 Byte Diskspace. So kann man sich die Größe jedes RRA und die Gesamtgröße der Datei ausrechnen. Ca. ein Kilobyte größer ist das File wegen der Metadaten danach, aber das ist vernachlässigbar.
Mit den Standardsettings des Excels ist das ca. 110 kB, mal 3 (AVG, MIN, MAX) = 330 kB.

Ich würde in allen Fällen und für alle Detailgrade immer AVG, MIN, MAX nehmen.

Bezüglich Aufzeichnungs-Detailgrad würde ich per Default grundsätzlich auf fünf Minuten gehen, und nur in Ausnahmefällen (als Option) eine Minute ermöglichen. Es kommt bei vielen Statistiken schon einiges an Last am Miniserver zusammen, das darf man nicht außer Acht lassen.

Meine RRA-Intervalle sehen ähnlich aus wie im Excel.

Auf Basis dessen, was ich verwende (und ich heute für Gut oder Schlecht empfinde), würde ich folgendes Set als Default machen:
Tage/Minuten:
31 (1 Monat) / 5 Min.
92 (2 Monate) /15 Min.
365 (1 Jahr) / 60 Min.
7305 (20 Jahre) /1440 (1 Tag)

Das ergibt eine Dateigröße (AVG/MIN/MAX) von ca. 800 kB pro Statistik. In meinen laufenden Statistiken habe habe ich hier teilweise andere Einstellungen, die mich stören (beispielsweise die 5-Minuten-Werte nur eine Woche, stört mich beim Vergleichen von KWs; oder die 60 Minuten-Werte habe ich mehr als ein Jahr, aber völlig nutzlos; den 20-Jahr-RRA habe ich gar nicht, und das stört mich, weil ich mit meinen Daten nur 2 Jahre vergleichen kann).

Eine Erfahrung ist, dass man auch keine größeren Poll-Intervalle als 5 Minuten will. Auch wenn es Daten gibt, wo es keinen Sinn macht, diese so oft abzuholen, will der innere Schweinehund einfach aktuelle Daten sehen, und nicht was, was Stunden her ist. Es gibt auch ein schnelles Erfolgserlebnis (die Diskussionen kennen wir ja vom IRR mit den Fragen, "schaltet zu bald ein" nach 5 Minuten Betrieb... ;-) ).
Vielleicht höchstens noch 60 Minuten, aber das macht (leider) die Generierung und das Polling der Daten komplizierter (STEP und HEARTBEAT).

Den xff-Parameter - wird meist mit 0,5 definiert - solltest du auf 0,08 setzen. Warum 0,08? Stellt man später ein Polling-Intervall von 5 Minuten auf 60 Minuten (1/12), funktioniert das Datenset noch! Ebenso würde ich das beim Heartbeat machen - fix auf stepsize * 13. Man erkennt zwar später, wenn die Datenquelle ausgefallen ist, aber bekommt dafür später NaN-Einträge.

Den --start Parameter bitte unbedingt auf Loxone-Epoch 0 setzen! Das ermöglicht nachträglich den Import z.B. von Loxone-Statistikdaten! Standardmäßig ist die Startzeit die Erstellungszeit, und RRD lässt keine älteren Daten zu!

Du solltest den gesamten Code unter Einbeziehung des rrdcached-Daemons aufbauen. Es muss am System dann nur eine Environment-Variable geben, die Host:Port des Daemons angibt, damit dieser von den Funktionen (vor allem UPDATE) verwendet wird. Das FETCH (egal ob den RRD-Graph oder durch eine andere Visualisierung aufgerufen), triggert vor Abruf von Daten dann automatisch ein Flush. Ob das dateibasierte Journaling von rrdcached auf der SD einen Sinn macht, weiß ich nicht.
Mit rrdcached hab ich selbst jedoch keine Erfahrung, weil Cacti sein eigenes Caching verwendet.
Bei Cacti verwende ich ein Flush-Intervall von 60 Minuten.

Das Pollen von Loxone mache ich mit einer Sekunde Pause zwischen jedem Objekt, damit sich der Miniserver "erholen" kann. Das dauert dann zwar etwas länger, aber sei's drum.

Ich glaub, ich hab alles :-)

lg, Christian

PS beim Testen: Die Intervalle kann man auch human readable angeben, z.B. 5m oder 24h, statt alles mit der Stepsize umzurechnen.

[BSiege]

Nun ist es ja so, dass man zum Zeitpunkt der Erstellung der Datenbanken schon sehr viele Vorgaben bzgl. Speicherintervall, Archive, etc. machen muss. Die meisten davon sind später nicht mehr änderbar. Das wird einen Laien mit Sicherheit überfordern (ich habe auch mehrere Anläufe gebraucht, bis ich Step, Heartbeat, RRA, PDP, CDP, XFF usw. voreinander bekommen habe).

Das ist mit entsprechendem Aufwand schon änderbar mittels dump nach xml. Gewisse Parameter können auch mit rrdtune beeinflusst werden. Ganz wichtig ist auch: das RRD-Format ist stark auf die Architektur optimiert. Wenn von einem 32-Bit auf ein 64-Bit System gewechselt wird, muss auch der Schritt über rrddump und rrdrestore gemacht werden.

[Christian Fenzl]

Es lässt sich sogar mit create ein neues RRD mit Datenquelle altes RRD verwenden. Je nach neuer RRA-Definition werden die Daten dann interpoliert.

[Prof.Mobilux]

Auf Basis dessen, was ich verwende (und ich heute für Gut oder Schlecht empfinde), würde ich folgendes Set als Default machen:
Tage/Minuten:
31 (1 Monat) / 5 Min.
92 (2 Monate) /15 Min.
365 (1 Jahr) / 60 Min.
7305 (20 Jahre) /1440 (1 Tag)

Super, perfekt! Das werde ich als Plugin-Standard verwenden, wer möchte kann dann diese Voreinstellungen nach Herzenslust ändern. Ich werde zudem noch vorsehen, dass man eigene Änderungen dann wiederum als Vorgabe selbst abspeichern kann.

Ich werde jetzt erst einmal den Datenbank-Teil sowie das Pullen vom Miniserver realisieren und als Zwischenstand per GIT veröffentlichen. Wenn das abgeschlossen ist und stabil läuft mache ich mich an die erste Grafik-Engine heran.

[Gast]

Man auf das Plugin freu ich mich schon! Ich hätte noch zwei Ideen, was man auch als Statistik erfassen könnte. Wie würde ich denn die Daten in die Datenbank schießen können? Es handelt sich um den Speedtest (speedtest.net), den man von der CLI her ausführen kann. Am Ende werden die Daten in ein Textfile geschrieben, das könnte ich dann auslesen und in die DB übertragen. Gleiches gilt für ein anderes Script zur Überwachung des Kabel-Anbieter-Backbone (benötigt einen DVB-C USB Stick zum Auslesen der Frequenzkanäle und deren Auslastung). Könnte man in einem Cronjob durchführen lassen und dann auch in die DB übertragen lassen. Ist eine andere Art von Statistik, aber gerade das mit dem Speedtest finde ich sehr aufschlussreich, da viele Probleme mit der Internetperformance haben, könnte man so Statistiken erstellen lassen um die Performance zu tracken.

P.S. So sieht die Ausgabe von Speedtest auf der CLI aus:

Speedtest at Tue Nov 1 12:00:01 CET 2016
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Unitymedia (37.49.87.118)...
Selecting best server based on latency...
Hosted by PfalzKom (Ludwigshafen) [103.94 km]: 21.827 ms
Testing download speed........................................
Download: 191.48 Mbit/s
Testing upload speed............................................. .....
Upload: 9.81 Mbit/s

Ausgelöst wird es in der Crontab durch:
*/30 * * * * echo "Speedtest at $(date)" >> /home/user/speedlog.txt
*/30 * * * * /usr/local/bin/speedtest-cli >> /home/user/speedlog.txt

Im ersten Schritt wird der Zeiteintrag durchgeführt und danach der Speedtest durchgeführt. Die Daten werden dann in die Speedlog.txt eingetragen (>> für das Anhängen der Daten, mit einem > wird dann jedes Mal eine neue Datei geschrieben, was bei Statistiken zu bevorzugen wäre, da braucht man keine Historie im File). Das Speedlog.txt kann dann mit rrd ausgelesen werden.

[Prof.Mobilux]

Prinzipiell kannst du später auch einfach per Cronjob die Werte in die Datenbank schreiben anstelle sie vom Miniserver abzuholen.

[Christian Fenzl]

Wart doch mal ab, bis Michael fertig ist! Hilft nichts, was zu erklären, was noch gar nicht da ist.

Ich dachte, ich könnte mich vorab schon ein wenig einlesen (auf der rrd Webseite habe ich da zuviel gefunden...) Ging mir mehr darum. Gut Ding will Weile habe, das weiß ich ja :-)

[Prof.Mobilux]

Wenn Du Dich einlesen willst: Schau Dir mal das kleine Beispiel an: https://www.heise.de/make/artikel/Ku...r-2714517.html Ich habe es einfach nachgebaut und es hat mir sehr geholfen zu kapieren wie es funktioniert :-)

[Prof.Mobilux]

Kurzes Update:

Das Erstellen von Datenbanken funktioniert jetzt sowohl mit Standardeinstellungen als auch im "Experten-Modus". Als nächstes kommt jetzt das Skript zum Holen der Daten vom Miniserver an die Reihe (zu 60% fertig).



Danach werde ich eine erste Version auf GIT veröffentlichen, mit der man dann schon etwas spielen kann :-)

[Christian Fenzl]

Wow, super!
Ich werde der erste Tester! Ich hab nämlich beim Formatieren und Probieren mit einer externen Platte irgendwann mal unabsichtlich die SD statt SDA erwischt... Und trotz Sicherung zickt jetzt mein Cacti-Poller herum...

Während du am GUI arbeitest, würde ich anbieten, einen Loxone-Import zu bewerkstelligen.

Lg, Christian

[Prof.Mobilux]

Während du am GUI arbeitest, würde ich anbieten, einen Loxone-Import zu bewerkstelligen.

Das ist perfekt - dazu hätte ich keine Lust gehabt Ich hatte sowie schon vorgesehen das Skript zum Hinzufügen von neuen Werten/Datenbanken so zu bauen, dass alle parameter mit HTML-GET übertragen werden können. Ich würde jetzt noch ein Skriptmodus hinzufügen, sodass Dein Parser dann direkt per wget/curl das Skript zum Hinzufügen von Datenbanken aufrufen kann. Damit wäre der Code dann nur an einer Stelle zu pflegen.

[Christian Fenzl]

Prof.Mobilux Ich weiß nur noch nicht, ob das initiale Erstellen von RRDs durch Import gescheit ist. Ich hab noch gelesen, dass man per Update-Command alte Daten nicht mehr hineinbekommt. Würde heißen, RRD-aufgezeichnete Daten wären bei Statistik-Import verloren.
Obwohl, wenn ich darüber nachdenke, wäre das auch egal, weil die Loxone-Statistiken diese Daten dann ja auch enthält.

Gut wäre, wenn der Benutzer übers GUI die Einstellungen festlegen und das RRD gleich anlegen kann, aber das Update pro RRD abdrehen kann. Dann könnte ich - ohne mir wieder Gedanken über die RRA-Einstellungen machen zu müssen - direkt ins fertige RRD hineinfeuern.

Ich weiß noch nicht, ob man das später nochmal brauchen wird, aber vielleicht speicherst du den Anlage-Command für das RRD irgendwo ab.

Und was mir auch noch durch den Kopf gegangen ist, ob data/~plugin~ der richtige Ort für die RRD-Ablage ist, wo dieses Verzeichnis doch bei der Deinstallation gekillt wird (was vielleicht mal unabsichtlich, oder bei Problemen passiert).

[svethi]

Cooler Text, das hat jetzt jeder verstanden *lach* aber bin auch dafür ;-)

Ja, genau das habe ich mir gerade auch gedacht. Ich konnte logisch noch folgen. Aber mehr als verstehen übersteigt dann meinen Horizont. Aber da steht bei Christian auch nicht umsonst "Lox Guru" (wahrscheinlich auch noch Guru in RRD und anderen artverwandten Themen)
Respekt Leute, ohne euch wäre 1. Loxberry nicht hier und 2. würden viele Dinge mir bei Loxone fehlen! Ich wünschte, ich könnte einfach mehr beitragen. Leider reicht mein Programmier-Know-How dafür leider nicht aus.

[Prof.Mobilux]

Christian Fenzl: Ich habe vorgesehen, dass man die Datenaufzeichnung Pausieren (Stoppen) kann. Nach dem Anlegen einer Datenbank ist die Aufzeichnung per Default zunächst gestoppt, sodass man noch den Import von alten Daten erledigen kann und dann erst die Aufzeichnung startet. In den Standardeinstellungen ist das Startdatum der Datenbanken der 01.01.2009. Das müsste also passen.

Ein Import-Modul könnte ich mir so vorstellen: Ich lade das LoxoneConfig-File hoch und kann dann auswählen, für welche Bausteine ich Datenbanken anlegen will. Zusätzlich kann ich anwählen, ob ich die XML-MS-Statistiken mit importieren möchte. Für jeden zu importierenden Baustein habe ich ein DropDown mit den Voreinstellungen zur Datenbank-Erzeugung (siehe mein Screenshot). Mit diesen Einstellungen wird dann für diesen Baustein die Datenbank angelegt und eventuelle alte MS-Statistiken importiert. Die Voreinstellungen muss ich vor dem Import anlegen. Anschließend kann ich in der Übersicht die Datenaufzeichnung starten und neue Daten fließen ein.

Als weiteres Importmodul könnte man sich dann später auch vorstellen die alten Daten aus einer RRD-Datei einzulesen.

Wenn ich eine neue Datenbank erzeuge schreibe ich in ein Info-File zur Datenbank den rrdcreate-Aufruf und eine Ausgabe von rrdinfo - habe mir auch überlegt, dass man das eventuell später nochmal gebrauchen könnte

Aktuell werden die Datenbanken in ~/data/plugin abgelegt, Das ist für mich auch der richtige Ort. Bei der Deinstallation kommt ja auch noch eine Sicherheitsabfrage, ob man wirklich... Ich werde da noch einen rote Zusatz ergänzen, dass ALLE Daten ganz wirklich und im ernst gelöscht werden :-) Im Plugin würde ich zudem noch eine Art Backup oder soetwas vorsehen wollen, sodass man seine Datenbanken sichern kann und z. B. auf einen neuen LoxBerry umziehen kann oder so ähnlich.

[Christian Fenzl]

Bezüglich des eigentlichen Imports würde ich den Weg gehen, nicht die Daten über die Loxone-API zu holen, sondern per FTP die Daten herunterzuladen, und das Loxone Binärformat selbst zu parsen. Das ist vermutlich um den Faktor 10-20 (je nach Pi-Hardware) schneller.
Da ich noch auf Loxone 7.4 bin, das Binärformat hab ich schon, bräuchte ich noch ein 8.x-Statistikfile zum Prüfen.

Wenn mir jemand der Mitleser ein einzelnes, aktuelles Statistikfile der Config V8 vom MS kopieren und hier bereitstellen könnte, mit Zeit des Herunterladens und dem ungefähren letzten Wert (z.B. Außentemperatur ca. 3 Grad), kann ich vergleichen, ob sich eh nichts geändert hat.

Ich ich fang jetzt mal an, die Statistikdaten vom MS aufzubereiten, und sobald du deinen Code bei Github hast, schau ich, wie sich das einfügt.

[Prof.Mobilux]

Bezüglich des eigentlichen Imports würde ich den Weg gehen, nicht die Daten über die Loxone-API zu holen, sondern per FTP die Daten herunterzuladen, und das Loxone Binärformat selbst zu parsen. Das ist vermutlich um den Faktor 10-20 (je nach Pi-Hardware) schneller.
Da ich noch auf Loxone 7.4 bin, das Binärformat hab ich schon, bräuchte ich noch ein 8.x-Statistikfile zum Prüfen.

Das wäre natürlich elegant. Ich dachte bisher, dass das Binärformat noch nicht endgültig entschlüsselt/verstanden wurde. Ich selbst bin auch noch auf 7.4, aber vielleicht findest Du im Thread zum Statistik-Editor noch was brauchbares - ich meine mich zu erinnern, dass da viele ihre Beispiele hochgeladen haben, die der Editor noch nicht einwandfrei gelesen hatte.

[svethi]

Das ist ja die Frage, das ist nicht immer gleich je nachdem wieviele Daten da drin sind.
oder gibt es jetzt doch schon eine Info zu allen Bausteinen/verschiedenen Varianten?!