LoxBerry: Statistik Plugin - Diskussion

[Prof.Mobilux]

Moin zusammen,

ich möchte mich daran machen ein Statistik-Plugin für den LoxBerry zu erstellen. Es gibt/gab ja schon viele Versuche hier im Forum das (mittlerweile leider veraltete) Projekt "Statistiken wie ich sie will" neu aufleben zu lassen, soweit ich das gesehen habe sind aber alle Versuche mehr oder weniger im Sande verlaufen (meist aus Zeitgründen).

Ich möchte das System mögichst modular aufbauen. Erster Vorschlag für ein Grundkonzept:

1. Daten erfassen

Die zu erfassenden Werte sollen per REST Webservice vom Miniserver gepullt werden. Das ist zwar ein gewisser Overhead, aber vermutlich(?) von der SPS unabhängig, sodass es für mich die bevorzugte Variante gegenüber einem Pushen vom Miniserver aus zum LoxBerry ist. Zudem hat es den Vorteil, dass man den Zyklus, wann Werte in die Datenbank geschrieben werden sollen, selbst festlegen kann. Eine SPS-Logik dafür wäre doch recht "teuer" und aufwendig zu programmieren. Jede Änderung eines Analogwertes möchte man mit Sicherheit nicht in der Datenbank haben. Der LoxBerry bietet dazu aktuell die folgenden Möglichkeiten: Minütlich, 3-Minütlich, 5-Minütlich, 10-Minütlich, 15-Minütlich, 30-Minütlich, Stündlich, Täglich, Wöchentlich, Monatlich, Jährlich. ich denke da bleiben keine Wünsche offen.

Als Datenbank würde ich im ersten Schritt MySQL vorsehen (die LoxBerry-eigene MySQL-Datenbank oder eine externe Datenbank). Im zweiten Schritt würde ich gerne noch SQLite hinzufügen, als einfachere Alternative auf Dateibasis (einfacheres Backup, Ändern von Daten, etc.).

2. Grafik-Engine

a) Highcharts

Im ersten Schritt möchte ich Highcharts vorsehen: http://www.highcharts.com/demo Die Diagramme dürften keine Wünsche offen lassen. Highcharts steht unter der Creative Commons (CC) Attribution-NonCommercial licence, darf also ausschließlich nicht-kommerziell eingesetzt werden. Da das Plugin OpenSource sein wird, ist das schon einmal erfüllt. Für alle Privatanwender sollte es ebenfalls kein Problem darstellen. Auch für kommerzielle Anwender sehe ich erst einmal kein problem, solange niemand seine Miniserverstatistiken kommerziell auf seiner Webseite präsentieren möchte.

Die Daten werden bei Highcharts in Echtzeit aus der Datenbank gelesen und die Diagramme per Javascript auf dem Client erzeugt. Man wird sehen ob das von der Performance her ausreicht. Ich sehe da eventuell 2 Probleme: Rapsberry1-Performance (MySQL) und ältere Tablets wie das iPad1 was die Javascript-Performance angeht.

Ich plane eine Art "Chart-Editor" analog des Editors bei FHEM (siehe Screenshot ungefähr auf der Mitte dieser Seite: http://www.meintechblog.de/2013/11/f...visualisieren/), mit dem man sich seine Charts zusammenstellen kann. Diese vorher definierten Charts kann man dann per Browser/App direkt aufrufen.

b) JS-Alternative zu Highcharts: Flot und/oder JqPlots

Nicht so mächtig wie Highcharts, dafür aber komplett OpenSource und durchaus auch ansehnlich: http://www.flotcharts.org/flot/examples/ und http://www.jqplot.com/examples/ Könnte also eine Alternative für alle diejenigen sein, die Highcharts auf Grund der Lizenz nicht einsetzen können/wollen

c) Plot-Tools über Images

Hier wären zu nennen Gnuplot und RRDTools: http://www.gnuplot.info/screenshots/index.html#demos und http://oss.oetiker.ch/rrdtool/ Gnuplot wird aktuell von FHEM verwendet (mittlerweile in einer eigenen Implementierung in Perl) und RRDTool wurde vom projekt "Statistiken wie ich sie will" verwendet. Diese Tools gehen anders vor als die vorher genannten Javascript-Charts: Die Charts werden als statische Image-Datei (z. B. PNG) erzeugt, sind also nicht interaktiv. Sie sehen daher auch nicht so "trendy" und modern aus wie die Javascript-Alternativen sondern bereiten Daten eher wissenschaftlich und schlicht auf - das allerdings äußerst effizient.

Soweit ich es sehe generiert FHEM diese Grafiken auch "Live" auf Anforderung, "Statistiken wie ich sie will" hat die Grafiken zu bestimmen zeitpunkten (nachts, stündlich, etc.) alle erzeugt. Bei der "Live"-Variante könnte es zu deutlichen Verzögerungen beim Betracten kommen (wie sind hier die Erfahrungen mit FHEM?), bei der letzteren Variante dürfte bei vielen Statistiken dem LoxBerry auf älterer Hardware (RaspPi1) schnell die Puste zum Zeitpunkt der Grafik-Erstellung ausgehen und der Speicherplatz wird mit der Zeit deutlich steigen (insbesondere bei vielen Statistiken).


Wie sind Eure Gedanken/Meinungen?

[Christian Fenzl]

Zu "Statistiken wie ich sie will" möchte ich anmerken, dass das einfach grauenhaft implementiert war. RRDTool generiert die Grafiken normalerweise on-demand und in-the-fly. Das Datenmanagement bei RRDTool ist automatisch mit an Bord. Man kann exakt sagen, wie groß die Daten werden, weil man das am Beginn definieren muss. Platz- UND Performanceprobleme sehe ich - ganz im Gegenteil - bei allen eigenen Datenbankimplementierungen.
Ein Chart über Temperaturen der letzten 2 Jahre dauert bei RRDTool eine Sekunde. Viel Spaß mit einer relationalen Datenbank :-)

Was mir bei der Betrachtungsweise nicht gefällt, ist, die Datenbank mal grundsätzlich relational zu machen, und RRDTool als Visu darzustellen. In Wahrheit ist die Stärke von RRDTool das Datenmanagement, und zur Visu kann man alles nehmen, auch mit RRDTool-Daten. Wobei ich auch eine andere Visu dem RRDTool vorziehen würde.

Lg, Christian

[BSiege]

Genau RRD RoundRobinDatabase ist zum Aufzeichnen von Daten immer noch unübertroffen. Was man nicht vergessen darf, ist die Schreibintensität die zwar schlank aber doch häufig ist. Und Flashspeicher haben das bekanntlich nicht so gern. Viele Embedded Systeme lagern das im RAM aus und schreiben die Daten etwas seltener auf Disk. Mit dem Risiko, dass mal wegen Stromausfall 2 Stunden daten mehr fehlen als nötig. Gilt aber für alle Backends die Schreibwütig sind.
Die Grafiken von RRD erscheinen zur heutigen Zeit etwas altbacken, sind aber noch heute an Informationsgehalt fast nicht zu übertreffen. Zumal man beliebige Anzahlen untereinander vergleichen kann. Es gibt nicht wenige Netzwerkprofis, bei denen ein Blick auf den Bildschirm reicht um eine Anomalie im System einzugrenzen. Die OSS Firewall pfSense hat kürzlich das RRD Frontend gewechselt. Das hat an Sexyness 200% zugenommen, der Informationsgehalt ging aber um 90% zurück ;-)

[Christian Fenzl]

Hier noch ein paar Gedanken zum Daten erfassen, worüber ich mir für meine Cacti-Integration schon nächtelang den Kopf zerbrochen habe, teilweise erfolglos. Mal ganz unabhängig von der Speicherart, fehlt hier noch ein GANZ GROSSER Punkt, nämlich die Auswahl der Loxone-Daten.

Dass man Pullen muss, ist Fakt - alles andere wäre sehr kompliziert beim Einrichten in Loxone.
LoxStats wählte den Ansatz, die von Loxone aufgezeichneten Statistiken zu importieren. Das finde ich genau den falschen Weg. Wir alle wissen, dass der Miniserver ich mit den Statistiken sein eigenes Grab schaufelt, und jetzt lagern wir das auf den LoxBerry aus, und müssten erst recht wieder in Loxone noch mehr Statistiken aktivieren.
Es soll also unabhängig von den Statistiken von Loxone gehen, man muss also direkt von den Objekten pullen.

Jetzt hat mir Loxone mit V7 einen neuen Fallstrick gebaut, es wird nämlich seit V7 das Loxplan-File nicht mehr als XML am Miniserver abgelegt, sondern in einem undokumentierten, komprimierten Format. Über den REST-Abruf bekommt man hingegen nur visualisierte Objekte.
Hier wäre zu überlegen, welchen Ansatz man wählt: Statistiken vom MS übernehmen und den MS früh sterben lassen, oder nur visualisierte Objekte aufzeichnen und sich damit die Visu zumüllen, oder mein neuer Ansatz, dass man das LoxPlan-File hochlädt und dieses parst.

Der nächste Punkt ist die Identifizerung der Daten. In Loxone gibt es die (sichtbare) Bezeichnung sowie eine (nicht sichtbare) ID im XML. Beides hat Vor- und Nachteile.
Mit der ID habe ich immer die Daten, auch wenn ich später die Bezeichnung (absichtlich oder unabsichtlich) ändere. Hingegen kommt es vor, dass sich aus der Programmlogik heraus die Erfordernis ergibt, einen Baustein zu ändern (z.B. Virtueller Status durch Merker ersetzen). Mit der ID wäre die Statistik jetzt wertlos, mit der Identifikation des Namens brauche ich meinen Merker nur gleich zu benennen, und alles läuft einfach weiter.
In meiner Implementierung habe ich das auf einen dritten Weg gelöst, nämlich mit einer Matching-Datei. Im Nachhinein betrachtet ist das aber zu viel Komplexität, nochmal eine zusätzliche Konfiguration pflegen zu müssen.

Letzter Punkt, den ich bei der Inbetriebnahme meines zweiten MS über Gateway-Konzentrator festgestellt habe, ist, dass das Gateway (also der Haupt-MS) bei REST-Abruf keine Daten seiner Kollegen liefert. Es muss also explizit beim richtigen MS eingesammelt werden.

Abgesehen von der Speicherung und Präsentation der Daten ist die Einrichtung entscheidend, weil es da eben ein paar Fallstricke gibt. Und es soll benutzerfreundlich und verständlich bleiben. Meine Cacti-Integration ist das leider nicht (Cacti selbst ist selbst schon kompliziert, weil es eben nicht für Einzeldaten, sondern für Templates gedacht ist), sonst hätte ich schon mal was online gestellt.

Michael, ich bin dir beim Entwickeln gerne behilflich für Teilbereiche - eher fürs Konfigurieren und Sammeln als fürs Präsentieren. Bezüglich ALSAMixer-Web habe ich eine fertige Lösung gefunden und deren Bugs gefixt, sodass es am LoxBerry funktioniert. Läuft unabhängig als Daemon (das gefällt mir nicht so), aber ich will dafür nicht so viel Zeit investieren, weil der Nutzen für die LoxBerry Community überschaubar ist.

lg, Christian

[Prof.Mobilux]

Ich wollte dem RRDTool keinesfalls "zu Nahe treten" - habe mich bisher nicht wirklich damit beschäftigt.

MySQL hatte ich ins Auge gefasst, weil es quasi überall verfügbar ist und man per SQL recht einfach gewisse Zeiträume, Mittelwerte etc. abfragen kann, ohne sich selbst die Logik dahinter basteln zu müssen. Und bisher war ich der Meinung, dass es auf jeden Fall performanter als die reinen ASCII-Logdateien von FHEM sein sollte. Aber ich bin da auf keinen Fall festgelegt!

Habe gerade mal etwas gestöbert und folgenden Artikel über RRD gefunden, der sich tatsächlich sehr interessant liest: http://www.linux-magazin.de/Ausgaben...ten-ausgesiebt

Es wäre also auch durchaus denkbar RRDTool als Datenbank zu verwenden und dann die Daten entsprechend an die Grafik-Engines aus der RRD zu füttern. Je länger ich drüber nachdenke desto besser finde ich die Idee

[Prof.Mobilux]

Hier noch ein paar Gedanken zum Daten erfassen

Ich bin absolut dafür das Statistik-Plugin unabhängig von den Statistiken des Miniservers aufzubauen. Sonst macht das in meinen Augen (fast) keinen Sinn.

Meine Vorstellung aktuell ist so, dass die Config-Dateien etc. nicht automatisch geparst werden, sondern dass man jeden Wert, den man statistisch erfassen möchte, explizit im Plugin anlegen muss (so wie das auch bei "Statistiken wie ich sie will" gemacht werden musste). Ich hätte jetzt einfach für jeden Wert einen extra "Virtuellen Status"-Baustein angelegt und entsprechend eindeutig benannt. Den Haken bei "Visualisierung -> Verwenden" deaktivieren, damit der Baustein in der Visu nicht auftaucht. Da der Baustein nur für die Statistiken verwendet wird, habe ich auch keine Gefahr, dass dieser mal umbenannt oder gelöscht wird (selbst dann könnte man sich noch eine Funktion "Statistik übertragen" o. ä. im LoxBerry vorstellen). Ich habe es gerade ausprobiert: Trotz dass der Baustein nicht in der Visu auftaucht konnte ich ihn über USER:PASSWORD@IPMINISERVER/dev/sps/io/Stats4Lox-Fortluft/astate abfragen.

[Christian Fenzl]

Ich habe es gerade ausprobiert: Trotz dass der Baustein nicht in der Visu auftaucht konnte ich ihn über USER:PASSWORD@IPMINISERVER/dev/sps/io/Stats4Lox-Fortluft/astate abfragen.

Ja das geht sicher.
Man kommt nur nicht an die Information, dass es diesen Baustein gibt. Wenn man im UI aber tippen statt auswählen muss, ist das auch egal.

[Gerrit]

Nur als Idee, weil es eventuell wenn es einmal läuft vieles einfacher Macht: Grafana (http://www.grafana.org) als FE für die Graphen: Vorteil wäre dass jeder sich ganz individuell seine Graphen zusammenstellen kann, ohne dass man da etwas dazu programmieren muss.
Als Backend bzw. Datenspeicher dann Prometheus (http://www.prometheus.io), dass wird auch in großen Installationen immer mehr vermehrt eingesetzt. Bietet ebenfalls eine RRD DB im Kern.
Beide Tools sind unter Apache 2.0 Lizenz unbedenklich verfügbar. Zudem sieht Grafana auch sehr schick aus

[Prof.Mobilux]

Ja das geht sicher.
Man kommt nur nicht an die Information, dass es diesen Baustein gibt. Wenn man im UI aber tippen statt auswählen muss, ist das auch egal.

Im LoxPlan ist er ja aber drin, oder?

[Christian Fenzl]

Ja, im Loxplan ist es drin, aber das steht am Miniserver nicht zur Verfügung.
Meine Cacti-Implementierung hat früher per FTP den Loxplan vom MS gezogen und geparst. Als,ich wieder mal einen Graphen dazumachen wollte, funktionierte das nicht mehr. Da bin ich dann drauf gekommen, dass am MS das File nicht mehr da ist, beginnend mit V7.
Es gibt ein komprimiertes File am MS, aber hab nicht herausgefunden, womit es komprimiert ist.

[eisenkarl]

Hab mir prometheus und grafana mal angesehen, bin begeistert. Also ich wäre für diese Kombi

[Prof.Mobilux]

Hab mir prometheus und grafana mal angesehen, bin begeistert. Also ich wäre für diese Kombi

Kann man sicherlich auch als Plugin realisieren, ist aber ein völlig anderer Ansatz mit eigenem Prometheus-Server - soweit ich das verstanden habe: https://prometheus.io/docs/introduction/overview/

Ich möchte Datenerfassung von Grafikengine trennen, damit man später flexibel auch andere Grafikengines dazubauen kann. Auch kann ich (ganz persönliche Meinung!) mit den Dashboards nix anfangen - ich möchte etwas, was ich aus der App aufrufen kann. Da sind Dashboards auf Grund von Platzmangel auf den Tablets suboptimal.

[Christian Fenzl]

eisenkarl Wenn ich lese, 1 GB RAM ist Standard-Cachegröße, und man sollte den Schreibcache auf 1/2 vom Lesecache setzen, das ist ein ganz anderes Kaliber. Ich glaube, selbst auf einem Rasp3 wären wir nicht glücklich über die Performance.
Die Funktionen von prometheus sind sehr einfach zu handhaben, wie sich das liest. Ein Datenaggregierungsmanagement gibt es aber keins (sowas wie, bei Daten älter als 1 Jahr nur noch 24 Datenpunkte/Min/Max/AVG pro Tag speichern). Muss man selbst bauen.
Und was mich immer stutzig macht, wenn alle Beispiele mit 1 Minute oder 5 Minuten sind. Fürs Netzwerk interessant, aber im Haus will ich JAHRE vergleichen, aber trotzdem 5-Minuten-Werte der aktuellen Außentemperatur sehen.

Ich muss wieder LoxStats heranziehen (habe meinem Bruder eine Lizenz eingeredet) - meine Erwartungen sind seit dem schon ganz niedrig, weil selbst die paar Loxone-Daten im Heimnetzwerk nicht zu processen waren. LoxStats hat sich beim initialen Datenimport auf einem PC so oft aufgehängt, bis ich aufgegeben hab. Mein Bruder hat das Webinterface seiner LoxStats-Installation nur einmal gesehen, und für nutzlos empfunden ("Daten von gestern?")

Und Aufwand und Nutzen sollten sich die Waage halten.

[bdaenzer]

erlaube mich auch mal noch einzuklinken...

habe beruflich mit dem sogenannten "ELK-stack" / neu "elastic" zu tun. das wäre ev. auch noch eine interessante variante!
ELK steht für elastic search, logstash und kibana.
wobei jede komponente auch für sich schon brauchbar ist. https://www.elastic.co/de/
performance auf einem rpi3 hab ich aber noch nie getestet..

es lassen sich, wenn mal die daten mal hat, sehr attraktive dashboards etc... erstellen. und auch data-mining ist sehr gut.

wirklich spezifisch für die lox müsste dann nur die datensammelkomponente (wie schon besprochen rest-polling) entwickelt werden.

bezüglich parsen des loxone files zwecks abgreifen der ID's/objekte:
warum nicht zusätzlich ein eigener user/usergroup "statistik" erstellen, welcher auch jedes "versteckte" objekt visualisiert erhält?

und noch ein nachtrag:
kurze erklärung: http://www.intranetofstuff.com/the_tools/elk-stack.html
und eine mischung mit dem auch schon erwähnten grafana: http://www.intranetofstuff.com/2016/07/01/grafana.html

[LoxFFB]

Wago macht das teilweise über den cloud Dienst Microsoft Power BI

[Gerrit]

Ja stimmt bleiben wir besser bei den passenderen und einfacheren Tools (von den HW-Anforderungen her).
Bei Prometheus gibt zwar auch eine ARM-Version und es verwenden auch welche dort und das DB-Format würde es wohl auch zu lassen, die Daten zu aggregieren, aber sie bieten es aktuell nicht automatisch an wie Christian schon schreibt, wusste ich auch nicht, muss ich mal die OPSler fragen, wie die das eigentlich machen. Wahrscheinlich ist Storage heute einfach zu günstig und die Abfragen immer schnell
Das selbe gilt übrigens für den ELK Stack, auch dieser bietet keine automatische Reduzierung der zeitlichen Auflösung. Natürlich kann man Abfragen machen, aber die Daten von vor 5 Jahren sind dann trotzdem noch in der selben Detailtiefe gespeichert und in der Summe macht dies die Anfragen langsam.

Interessant wäre übrigens auch die Loxone Daten einmalig zu importieren, so dass man potentiell nicht von 0 anfangen muss

[bdaenzer]

um alte daten zu löschen/archivieren/datenmenge im griff zu halten (und auch die performance) gibt es für den ELK stack eine komponente namens "curator".

https://www.elastic.co/blog/curator-tending-your-time-series-indices

man darf einfach nicht endlos füllen ohne wieder mal zu spülen... sonst geht's irgendwann an den speed und den speicherplatz. für die meisten smarthome themen dürfte aber nicht viel mehr als das letzte jahr interessant sein. sonst muss man einen separaten export für langzeitstorage / einzelne datenelemente machen.
was stimmt ist, man kann nicht einfach die daten "reduzieren". entweder stehen alle in der ganzen detailtiefe zur verfügung oder dann gar nicht.

http://logz.io/learn/complete-guide-elk-stack/