Verlaufsdaten in eine Datenbank pumpen und diese dann graphisch darstellen

Ausgangssituation

Mit der neuen Beta kommt ja der tägliche Export der Verlaufsdaten via FTP, allerdings nur für die letzten 24h und nur für die Geräte, welche in diesen 24h geschaltet wurden, bzw. die Werte gemeldet haben, danach wird wohl im homee ohnehin komprimiert.

Siehe hier:

MIt dem FTP-Backup der Verläufe werden die Dateien im angegebenen Pfad in einer folgenden Struktur abgelegt

   Verzeichnis pro Datum
    - Gerät
    -- Values.csv (für alle Wertearten)

Idee

Wenn man jetzt mit einem täglich laufenden Skript diese Dateien nach dem Export in eine Datenbank pumpen würde (irgendwas leichtes ioT-orientiertes würde sich anbieten - Influx?) und diese Daten dann in einem Frontend (Grafana?) aufbereiten würde, hätte man eine Lösung in der alle Daten fortlaufend vorgehalten und analysiert werden können.

Ein solches Skript könnte man über homeean bereitstellen, genauso wie die notwendige Installation und Konfiguration der DB und des Frontends und ggf. auch eines vorkonfigurierten FTP-Paketes für den Datenempfang (all-in-one-Lösung).

Call for Action

Es braucht nur Leute mit entsprechendem Sachverstand, die sich dieser Sache annehmen.

Mir fallen da spontan einige ein, z.B.: @Gido @xenji @Baschtl

Ob und wie das mit einem Raspi überhaupt gelöst werden kann ist eine Sache die halt kommuniziert werden muss (Daten nur auf externe Platte, Mindestanforderung an den Raspi (3B+), Parallelinstallationen, usw.).

Gibt es Freiwillige?

1 „Gefällt mir“

Warum so kompliziert?
Warum befüllt homee nicht gleich direkt eine Datenbank? :thinking:

Weil die Wahrscheinlichkeit, dass so was zeitnah kommt etwa so hoch ist wie wenn Weihnachten und Ostern auf einen Tag fallen :wink:

Edit: Der Vollständigkeit halber Dein Feature-Vorschlag (der die Idee brachte):

2 „Gefällt mir“

Wenn man das von Anfang an unterstellt und kein Bedarf anmeldet, dann gebe ich dir Recht!

Der Aufwand für DB Schnittstelle dürfte nur unwesentlich größer sein als für die FTP.
Hätte man mich vor die Wahl gestellt ob DB oder FTP, hätte ich mich für DB entschieden.

Da sind wir uns einig - ich habe es nur schon lange aufgegeben davon auszugehen, dass Poweruser-Anforderungen zeitnah umgesetzt werden… Für die Zielgruppe des homees kannst Du halt die Kenntnisse eine DB aufzusetzen und zu maintainen nicht voraussetzen.

Es ist Dein Vorschlag gewesen so was zu bauen und Du setzt es ja schon ein, ggf. habe ich in der Liste oben jemanden vergessen? :wink:

Was fängt den ein normalo User mit dem FTP Export an? Ich verzeifle ja schon bereits, wenn ich mich durch die Tagesschnipsel durchkämpfen muss.
Eine Sicherung der Verlaufsdaten nur der Sicherung wegen?! :thinking:

1 „Gefällt mir“

Ich halte es für den Versuch uns eine Möglichkeit zu geben genau so was, wie oben beschrieben, zu bauen. Und ausserdem ist es ein Abfallprodukt des homee-Backups.

Mal eine kurze Zwischenfrage…

Verlaufsdaten sind ja ganz nett, aber was macht ihr damit genau bzw. welchen Benefit zieht ihr daraus.

1 „Gefällt mir“

Da hast Du meine volle Unterstützung!
Aber ich grabe nicht erst ein Loch um es dann wieder zu zuschütten!

Ich auch nicht - aber wir beide arbeite ja auch nicht für CA :wink:
(Wobei ich das den Jungs und dem Mädel auch nicht unterstelle - ich denke sie werfen uns einen Knochen hin und testen ob wir ihn fressen - hat ja zuletzt ganz gut geklappt die Community einzubinden um homee flexibler zu machen, ohne ihn vollständig öffnen zu müssen).

Ich kann nur von mir sprechen:

Auswerten und Visualisieren.

  • Temperaturverläufe mehrere Sensoren in einem Chart.
  • Luftfeuchtigkeits Entwicklung in Abhängigkeit der Temperatur
  • Ermittlung von Mittelwerten auf Tages/Wochen/Monatsbasis
  • Was man halt mit Daten so macht :grinning:

Wenn du das im Kleinen machen willst und mit den Daten “spielen” willst, könnte man PowerBI verwenden.

Damit kannst du wirklich tolle Dashboards erstellen und mit Datenschnitten, Clusteranalysen, Hichert-Grafiken toll und einfach arbeiten

  • korrektes Lüftungsverhalten der Räume kontrollieren (Lüftungsverhalten, Fenster auf/zu)

Finde die Idee sehr gut. Ich würde am liebsten die Dateien in eine MySQL auf meinem Webserver importieren und dann am liebsten eine Weboberfläche zur Darstellung. Aber Wunschdenken und Umsetzung sind da meist sehr weit auseinander :).

Wir müssen mal überlegen, was für die meisten User nützlich ist. Kaum einer wird sich ne Influx und ein Grafana selbst hosten wollen. Influx auf dem PI3 macht auch nicht viel Freude. Ich könnte mir ne reine Windows Desktop Lösung vorstellen für die ganz Unbedarften und eine CLI binary für Konvertierungen in z.B. SQL.

2 „Gefällt mir“

Warum nicht?

Mehrere Gruende:

Die I/O write performance liegt, selbst bei schnellen SD Cards, Treiber und Hardwarebedingt bei ca. 25 MB/s, welche sich alle Prozesse auf dem System teilen muessen. (vgl: https://www.reddit.com/r/raspberry_pi/comments/4a679u/raspberry_pi_3_sd_card_io_performance/)

Die I/O read performance liegt bei 4k reads eher im unterirdischen Bereich, d.h. I/O lastige tools wie Influx koennen dort nicht punkten. Aktuelle Benchmarks inkl. Read: https://www.jeffgeerling.com/blog/2018/raspberry-pi-microsd-card-performance-comparison-2018

Der Pi macht kein Hardware Offloading fuer I/O, d.h. Netzwerk und HDD muessen durch die CPU gebraten werden. Wenn du also Netzwerk IO fuer den ingress machst, Disk I/O fuer die Influx writes, Disk I/O fuer die Queries in z. B. Grafana und den Grafana Server noch per NodeJs auf der Kiste hosten willst, dann macht das, aus meiner Perspektive, weder Spass noch Sinn.

Konnte ich Deine Frage beantworten? Ich kenne deinen technischen Hintergrund nicht, daher hab ich jetzt mal den Mittelweg versucht. Wenn dir etwas unklar ist, bitte einfach nachfragen :wink:

2 „Gefällt mir“

Wäre grandios, wenn Du es Dir mal ansehen würdest…: Wie eine Lösung aussieht ist am Ende des Tages egal - nur End2End wäre die Anforderung (vom Import bis zum vorkonfigurierten Frontend).

3 „Gefällt mir“

Danke, auch wenn Ich vielleicht nicht alles Verstanden habe. :rofl:

Nen Pi mit einer SD-Karte zu betreiben, habe ich schon lange aufgegeben.
Aber wenn ich dich richtig verstehe, ist das nicht nur die SD Karte.

so sieht es aus :wink:

Auch wenn der ARM64 im Pi3 schon echt ne Verbesserung darstellt, ist es halt immer noch kein “workhorse”. Ich fahre meine Haus IT mit dem Tierchen hier: https://www.hpe.com/de/de/product-catalog/servers/proliant-servers/pip.hpe-proliant-microserver-gen10.1009955118.html

Auch wenn der, zugegebenermassen, overpowered ist, kann der halt alles was ich so an pers. Anspruechen stelle. Ich denke mal mit nem kleinen Intel Atom board oder nem klassischen Intel Pentium micro ATX kommt man da gut zu Rande.

@hblaschka Ich denk mal drueber nach, aber ich muss erst mein Proxy Detection Projekt fertig machen. Danach kann ich mich voll und ganz dem hier widmen :wink:

1 „Gefällt mir“

Sowas wie das hier wuerde wahrscheinlich reichen, auch wenn ich dann pers. ne USB 3.0 SSD dran packen wuerde. https://www.amazon.de/Intel-NUC-BOXNUC6CAYH-Ordenador-CELERON/dp/B01MSZTD8N/ref=sr_1_5?s=ce-de&ie=UTF8&qid=1532811557&sr=1-5&keywords=intel+Atom

Bitte nicht als Kaufempfehlung interpretieren, ist nur ein Beispiel!

1 „Gefällt mir“