Datensammlung über die Zeit

Hey Rouven,

ich hab da ne coole Idee. A brauch ich zeug um das Dashboard zu fülle, B macht's grad Spaß und C wär's einfach cool;)

Wie Zeichen für nen Zeitfenster, sagen wir ne Stunde auf (in $Abständen) wie laut es war (Durchschnitt über Stepwindow) und zeigen das als schönen Graph in der WebUI an. Am besten 2 Graphen, einen für die Lautstärke und einen für die Sensitivität.

Kann könnte dazu z.B. das d3 Framework benutzen. Wäre doch bestimmt Fancy ;)

Kann man auch noch viel mehr Statischen machen wenn man bock drauf hat. Wie lange an und wann, usw. Son Bar Chart über die 7 Wochentage wann sie wie oft an war usw.

Voll Dafür!

Check mal www.chartjs.org und www.plot.ly/javascript . Letzteres setzt auf d3 auf.

Gefällt mir. D3 is denk echt Overkill.

Jetzt müssen wir uns noch überlegen, welche Daten wir sammeln möchten und wie. Folgende Vorschläge

• Lautstärke über die letzten X Minuten
• Wann die Ampel an und aus war aufgeteilt auf die Wochentage im Durchschnitt. Eventuell auch umstellbar über die Zeiträume letzte Woche / Monat / Jahr
• Sensitivität über Zeit
• Durchschnittliche Sensitivitätseinstellung verteilt auf Uhrzeit am Tag

Die Daten sollten denke ich auf jeden Fall auf der Python Komponente gesammelt werden oder? Man sollte denke ich auch ne Datenbank für nehmen oder. Die kann man vielleicht auch direkt vom Web Interface aus ansprechen.

Hab mir überlegt, dass es da verschiedene Bereiche geben könnte, z.B.

• Lautstärke

  • Lautstärkegraph über die letzten Stunde
  • Durchschnittslautstärke

• Alarm

  • Durchschnittliche Anzahl an Alarmen pro Tag / Stunde
  • Alarme gesamt (Alle / Automatisch / Manuell)

• Nutzung

  • Durchschnittliche Nutzungsdauer an den jeweiligen Wochentagen
  • Nutzungsdauer gesamt

Usw. Mir fällt sicherlich noch mehr ein. Ich mach mich die Tage eventuell mal daran das Datenkrakenmodul zu basteln.

Hier ne kleine Quickskizze wie ein Dashboard mit mehr Infos aussehen könnte

added feature js-component labels

added discussion label

Hab ich da Datenbank gehört? ( ͡° ͜ʖ ͡°)

Also ich hab noch nie explizit probiert, wie eine DB auf dem Pi performed, aber ich lass mal meine Rest-Expertise da. Zunächst mal kann man die Daten, die hier anfallen, zwei Kategorien zuordnen: 1. Zeitreihen (die Lautstärke pro Zeit) und 2. Events (die ausgelösten Alarme bzw. An- und Ausschalten).

Vorneweg, das klappt natürlich alles auch mit sqlite, Postgres, oder you name it, aber vielleicht gibt's ja die ein oder andere Gelegenheit zum Spielen ;)

Eine Alternative wäre Influx, das ist eine Timeseries-Datenbank in Go geschrieben und die hat nach 10k eingefügten Tupeln einen Memoryfootprint von handlichen 30MB im RAM (also man könnte die auf einem Pi durchaus laufen lassen). Laut db-engines.com kann Influx sowohl C als auch D, was für instabile Systeme nice to have ist. Außerdem kann man solche aggregierten Werte über die Zeit sehr angenehm querien, etwa so:

select mean(value) from decibell where time >= '2017-06-10' and time < '2017-06-11' group by time(10m)

Damit bekommt man für den entsprechenden Tag alle Werte in 10min-Intervallen. Außerdem gibt es Nutzerrechte und eine HTTP-Schnittstelle, so dass man z.B. einen Nutzer machen kann, der nur lesen darf (der könnte dann vom Frontend benutzt werden, oder von der Campus-App, oder was auch immer ).

Hey Manu,

cool, dass du dich einklinkst.

Das klingt schon mal ziemlich gut was du erwähnt hast. Auch die Influx DB klingt interessant. Du hast ja am meisten Ahnung von sowas.

Mit C und D meinst du die Sprachen denke ich oder? Ich glaube @r_bauer11 stimmt mir zu, wenn ich sage, dass es cool wäre wenn das alles in Python ginge. Wir haben in diesem Projekt jetzt schon Python und JavaScript (plus HTML, SASS/CSS, jQuery usw) und dann käme mit C oder gar GO eine dritte Sprache hinzu, die man können muss, wenn man das Projekt maintaint.

Gibt es da auch Python Anbindungen zu InfluxDB?

Generell was für Tabellen würdest du denn wählen für die verschiedenen Daten.

Wir sollten denke ich sowieso erst mal sammeln und spezifizieren, was genau wir alles haben möchten.

Ich denke aber auch, dass das WebInterface nicht direkt mit der Lärmampel reden muss um an die Daten zu kommen. Ne 3. Komponente die über den IPC Socket zuhört, die Daten sammelt und per API bereit stellt, so in etwa hätte ich mir das vorgestellt. Dann kann das WebInterface einfach entweder direkt mit der DB reden oder per WebSockets mit dem Node Server, der dann ne Anfrage an die Datenbank macht.

Ansonsten: hättest du denn Lust dich ins Projekt einzuklinken oder möchtest einfach nur beraten? Auf jeden Fall schonmal danke :)

In meinem Kopf hat es mehr Sinn ergeben :D

Mit C und D meine ich Consistency und Durability, also in dem Anwendungsfall: Wenn da ein Datum an die DB geschrieben wurde, dann wird es irgendwo sinnvoll gespeichert. Im Vergleich dazu, wenn du alles in Python in einer Liste lassen würdest, und die alle paar Minuten als JSON wegspeichern würdest, müsstest du noch sonderfälle einbauen für den Fall, dass jemand im ungünstigsten Moment dem Pi den Strom kappt.

Mit Go wollte ich auch garnicht auf die Sprache hinweisen, die man benutzen müsste, sondern eher, dass dann keine weitere Runtime auf dem Pi laufen müsste (im Gegensatz zu Node o.ä.) Die Python-library sieht ziemlich einfach zu benutzen aus, ist wahrscheinlich auch nur ein dünner Layer über HTTP.

Was Daten angeht, wird ja wahrscheinlich sowas anfallen:

time stamp	loudness	sensitivity
Mo, 10:05	5	40
Mo, 10:06	5	40
Mo, 10:07	9	60
Mo, 10:08	3	60

für die Messung bzw. Einstellung (ich würde die Sensitivität auch als "Messung" interpretieren, so viel mehr zu speichern ist das auch nicht).

Und die Alarme als

time stamp	sensitivity
Mo, 10:06:90.586724	40

Hier ist denke ich die Sensivität beim Auslösen interessant.

Ich glaub, für das Projekt wäre es besser, wenn ich nicht mitmisch, hab eh zu wenig Zeit, so dass ich da eher bremsen würde. Aber random Input verteil ich gern ;)

Prinzipiell finde ich deine Datenarchitektur ziemlich gut, sehe allerdings einen kleinen Knackpunkt. Die Lautstärke wird ja etwa alle halbe Sekunde von der Lärmampel gespamt. Die Sensitivität allerdings wird vergleichsweise nur sehr selten geändert, vielleicht sogar den ganzen Tag gar nicht.

Da würde man doch im Vergleich einen ziemlich großen Datenoverhead verursachen, die Sensitivität ist ein float, also 32 bit pro Messung. Oder kann InfluxDB irgendwas cooles um redundante Daten zu komprimieren?

Wenn man die Sensitivität natürlich nur dann wegspeichert, wenn sie geändert wird, kann man sie zum Zeitpunkt eines Alarms natürlich nur interpolieren und ich vermute die query nach dem Durchschnitt wird anspruchsvoller.

Ansonsten wollten wir ja noch aufzeichnen, wann die Ampel an und aus war und wie lange. Meine erste naive Idee war einfach die An- und Ausschaltzeitpunkte mit zu speichern, aber vielleicht gibt es da ja etwas besseres.

Datenbank Server

Folgende Möglichkeiten

1. Extra Python Komponente

Diese hört über den IPC Socket zu und schreibt munter Dinge weg. Dazu stellt sie ne API bereit um angefragt zu werden.

2. NodeJs

Der sowieso schon laufende NodeJs server, der ja jegliche Kommunikation mitbekommt, könnte das auch direkt übernehmen. würde uns quasi eine weitere Komponente sparen, wäre aber vielleicht eine unschönere Trennung (oder eben keine) der Module.

Es gibt auch ein NodeJs InfluxDB Modul

Queryanfragen

Auch hier sollte man sich erstmal überlegen wie man das ganze umsetzen möchte

* Man sendet direkte Queries in "InfluxDB Sprache"
* Das Datenbankmodul macht die Queries intern und stellt nach außen ne simplere API bereit

Ich bin hier für letzteres.

Query direkt vom Webinterface zur DB

Man könnte direkt vom Browser aus ohne Umwege die Datenbank anfragen

Query über NodeJs Webserver

Das Webinterface stellt ne Query über WebSockets an den NodeJs Server und dieser stellt dann die Query an die Datenbank. Hat den Vorteil, dass man die Datenbank überhaupt nicht mit dem Arsch ins Internet hängen muss

Auch hier bin ich für letzteres.

Sorry, dass es so lange geworden ist, bin aber auch eure Meinungen und Vorschläge gespannt :)

Ja, ich glaub, gerade die Lautstärke ist ein komplizierter... Wenn die alle halbe Sekunde gespamt wird, bedeutet das, dass alle halbe Sekunde punktuell gemessen wird, oder sagt die Lärmampel alle halbe Sekunde "in der letzten halben Sekunde war es in etwa fünf laut?"

Andererseits, wenn ich so drüber nachdenke, sollte das schon klein genug aufgelöst sein. Influx kann komprimieren, wie hoffentlich jede andere Timeseries-DB hoffentlich auch, ich meine, die machen Delta-compression, dann würden halt ein Haufen 0en gespeichert, wenn sich nichts ändert.

Aber du hast schon recht, wenn das sooo einen großen Unterschied zwischen Sensitivitätsanpassung und Lautstärkemessungen gibt, dann wäre das sinnvoller, die beiden zu trennen.

Naja man könnte schon die Dinger zusammen speichern und die Lautstärke halt absolut belassen. So sieht man, wie du sagst, den Zusammenhang direkt.

Was schlägst du denn vor, wie man das mit An- und Ausschalte, bzw trocken wie lange das Ding läuft machen sollte? Einfach die An- und Ausschaltzeitpunkte Wegschreiben?

@r_bauer11 wie sollen wir generell vorgehen? Sollen wir uns jemanden suchen, der Bock auf Datenbankenzeug hat und sich quasi um diese 3. Komponente kümmert? Oder sollen wir beide das machen?

Zaunei und Sebastian (Schumb) haben wohl sehr schlechte Erfahrungen mit InfluxDB gemacht und raten meter so Prometheus oder Graphite.