[wiregate] Wiregate und BIG DATA

[nipponichi]

Titel paßt nicht so ganz, aber ist griffig und hip .

Beim Wiregate fallen jede Menge interessante Daten an, die man langfristig auswerten könnte.
Aber leider werden die KNX-Bus-Logs nach geraumer Zeit überschrieben und die rrd-Werte verlieren nach einer Woche ihre 5-Minuten Genauigkeit.

Inzwischen exportiere ich die rrds nach text und sichere sie zusammen mit den eib-logs auf ein NAS.
Damit verliere ich nun keine Daten mehr, aber eine geeignete Aufbereitung und Auswertung steht damit noch aus.

Hat jemand die gleichen Gedanken, vielleicht schon ein sinnvolles Konzept oder Lösung?

Grüße, Manuel

[StefanW]

Hallo Manuel,

ja, es gibt dafür einen Bedarf und damit auch ein Konzept und sehr gute Lösungsvorschläge.

Genauer, es gibt eine Arbeitsgruppe dazu und wir sind Mitglied dieser Gruppe. Mehr kann ich dazu jetzt nicht sagen.

lg

Stefan

[makki]

Naja, kann man machen.. Bleibt nur die Frage: was interessiert mich am 30.08.2015 nachträglich die Temperatur vom 30.08.2013 exakt um 23:05 Uhr - und macht es Sinn dafür GB-weise Daten aufzuzeichen, die nie jemand anschaut weil der Mittelwert steht eh im RRD..

Makki

[FeqBuermoy]

Bleibt nur die Frage: was interessiert mich am 30.08.2015 nachträglich die Temperatur vom 30.08.2013 exakt um 23:05 Uhr

Da wundert sich jemand bei der Jahresabrechnung, warum soviel Heizernergie benötigt wird, und findet heraus, dass immer um 23:05 auf einmal die Temperatur sinkt, weil der Nachtwächter um diese Zeit auf seiner Tour jedesmal die Türe nicht schließt.

[makki]

Das steht auch in den gemittelten Daten..

Makki

[heckmannju]

wie ist den grob dir auflösung der älteren Daten?

[makki]

Guckst du hier: https://knx-user-forum.de/forum/supp...483#post227483

[StefanW]

Die Fragestellung galt einer "Big-Data" Auswertung / Anforderung für die Zukunft.

Bitte lasst uns dieses Thema nicht damit verwässern, was bei der Produkteinführung 2009 State-of-the-Art war.

Es gibt Anforderungen aus Kundenschichten, die gehen weit über die Notwendigkeiten des EFH hinaus - bzw. es gibt Forschungen, die es detaillierter brauchen. Daher arbeiten wir auch in einer renommierten Arbeitsgruppe an Konzepten und Möglichkeiten der Zukunft mit. Zur L&B 2016 gibt es mehr dazu.

Stefan

[makki]

Wenn man unter "BIG DATA" das nutzlose speichern von vielen sowieso ungenutzten Daten versteht, Ok. Das verstehen 5% zwar nicht, aber genau diese 5% werden auch nicht 2-3J später die Temperatur von 23:05h in 2013 abfragen wollen.
Ansonsten ist das RRD 2000 bis 2015 "State-of-the-Art" und das wird sich auch bis 2020 so nicht ändern..
Egal, macht mal "BIG DATA", irgendwie müssen die Hersteller von Speichermedien ja auch Geld verdienen

Makki

[FeqBuermoy]

Aber leider werden die KNX-Bus-Logs nach geraumer Zeit überschrieben und die rrd-Werte verlieren nach einer Woche ihre 5-Minuten Genauigkeit. Inzwischen exportiere ich die rrds nach text und sichere sie zusammen mit den eib-logs auf ein NAS.

Es macht Sinn, die Logdateien nicht ins Unendliche wachsen zu lassen. Es ist schon der richtige Weg, das Log für eine größere Auswertung zu exportieren. Nur sind Textdateien dazu nicht geeignet. Besser wäre es, ein Datenbankformat zu bemühen. Damit sind jede Art Auswertung möglich, auch die Daten selbst können so "on-the-fly" komprimiert werden und somit Speicherplatz sparen.

Wenn ich mal überschlägig rechne, kommen bei einer 5-Minutenauswertung 105120 Messwertpaare je Messstelle zusammen. Bei 2 Ziffern für die Temperatur und 12 Ziffern für das Datum plus Uhrzeit sind das rund 736 kByte im Jahr. Ein 2GByte Speicher fasst da 5434 Jahre pro Messstelle, oder realistischer, 543 Messstellen für 10 Jahre.

Ich fände es gut, wenn Logs mit Rohdaten an einen Logserver geschickt werden können, und die Auswertung weiteren, vom Loggenerator unabhängigen Werkzeugen überlassen wird. Damit kann jeder Anwender selbst entscheiden, wie er die Daten auswerten will, und welche Tools er dazu benutzen möchte.

[StefanW]

Sehr richtig, FeqBuermoy

der allergrößte Teil der anfallenden Daten lässt sich durchaus mit weit höherer zeitlicher Auflösung als 5 Minuten mit geringerem Speicheraufwand gegenüber RRD speichern - bei mehr Flexibilität in Abfrage und Auswertung.

Makki: Es geht hier um reale und häufige Kundenanforderungen, nicht darum ob Du das verstehst oder nicht. Für zynische Bemerkungen darüber wer was verstanden hat ist das nicht das richtige Forum.

lg

Stefan

[nipponichi]

makki: Man kann mehr als nur Temperatur aufzeichnen ... bei mir Stellwerte, Helligkeit, Anwesenheit, Luftfeuchte, Gasverbrauch, Stromverbrauch, KWL-Stufe, KWL-Wirkunggrad, Verschattung, Sonnenstand (ok, der ist immer berechenbar), ...
Bei Gas und Strom ist z.B. der jahreszeitige Unterschied interessant, aber auch innerhalb eines Tages. Kann man Standby-Verbräuche bestimmen und vergleichen, aber nur, wenn man eine sinnvoll kleine Auflösung hat. Es gibt eben auch sprunghafte Meßwerte, die per Mittellung unter den Tisch fallen, d.h. man hat effektiv gar keine sinnvollen Werte mehr! Nebenbei ist eine 25-Minutenauflösung schlecht zu handhaben, da 24 Std dadurch nicht glatt teilbar.

Im Moment fallen bei mir pro Jahr 100MB komprimierte Daten an. Aufbereitet wird das ein Bruchteil sein. Ist das wirklich viel?

[heckmannju]

Guckst du hier: https://knx-user-forum.de/forum/supp...483#post227483

Danke. Da schreibst du was das man es ändern kann. Muss man dazu Coding ändern oder ist das was wo man konfigurieren kann?

[heckmannju]

.....

[Hups]

Interessanter Ansatz! =)
Ist jetzt zwar nicht die primäre Aufgabe vom Wiregateserver, aber kann man die Daten nicht auch zur Steuerung nutzen?
Wärs möglich Luftfeuchtigkeit und Raumtemperatur als Sollwert am Wiregate einzustellen und das Wiregate steuert Heizung und Lüftung danach um das bestmögliche Ergebnis zu erzielen? Parameter hätte man ja alle: Außentemperatur und Feuchtigkeit, das Verhalten der Luft vor und nach dem Lüfter und die Änderung der Werte in den Räumen, vor und nach erfolgter Änderung. Fenster und Türkontakte zur Sicherheit, damit das Ergebnis nicht verfälscht wird.Ja ich weiß man braucht Plugin und Perlprogrammieren und und und. Aber sie ist nicht aus der Welt so eine Fantasie, oder?

SG,
Hups