LoxBerry: Statistik Plugin - Diskussion

[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

[LoxFFB]

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

[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

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

[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]

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]

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?

[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

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

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

[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

[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

[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]

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