eems - easy energy monitoring system

  • Hallo Raspberry Pi Community,

    mit diesem Thread würden wir gerne uns sowie unser aktuelles Projekt vorstellen. Wir sind zwei Studenten in den letzten Zügen des Studiums der Gebäudetechnik. Im Verlauf der letzten Jahre haben wir uns mit unterschiedlichen Gewerken und technischen Anlagen beschäftigt. Dabei ist uns eine wichtige physikalische Größe immer wieder untergekommen, die Temperatur. Ob Büro- oder Privatgebäude, technische Anlagen (Heizung, Lüftung, Kühlung), industrielle Fertigungsbetriebe oder sonstige Anwendungsgebiete, überall ist es erforderlich Temperatur verlässlich zu messen. Aus diesem Grund haben wir vor einiger Zeit angefangen uns mit dem Thema Raspberry Pi auseinanderzusetzten. Dadurch sind über die letzten Jahre viele kleine Einzelprojekte entstanden, wobei auch häufig Temperatur gemessen wurde. Obwohl jedes Einzelprojekt individuell gestaltet war, wurden z.B. Skripte zum Auslesen der Temperatur immer wieder neu geschrieben. Dieser Anlass hat uns dazu bewegt ein „Stück Software“ zu entwickeln, mit dem der Ausleseprozess von Temperatursensoren effizient standardisiert und automatisiert wird. Sprich eine Anwendung, die immer wieder zum Einsatz kommen kann sobald Temperatursensoren im Spiel sind. In aktueller Version werden nur DS18B20 Sensoren unterstütz, da unserer Erfahrung nach dieser Sensortyp in den meisten Projekten, die Temperatur und Raspberry Pi verbinden, eingesetzt werden.

    Unsere Ziele zu Beginn des Projektes waren folgende:

    • Entwicklung einer stabilen, robusten und flexiblen Anwendung, die einfach zu bedienen ist und schnell zum Ziel führt (Hardware anschließen -> Programm starten [font="Wingdings"]->[/font] Ergebnisse auswerten)
    • Die Möglichkeit Sensoren nicht nur einmalig auszulesen, sondern mittels der Anwendung ein „Monitoring“ mit einem benutzerdefinierten Messintervall sowie einer Messdauer zu starten
    • Mehrere Temperatursensoren gleichzeitig zu betreiben
    • Ausgabe der Messwerte in ein gängiges Format
    • Detaillierte Aufzeichnung (logging) der Messvorgänge


    Bisher haben uns unsere Ziele zu folgenden Hauptfunktionen der Anwendung geführt:

    • Einfaches Auslesen aller angeschlossener Sensoren
    • Monitoring Funktion mit der Möglichkeit Messintervall und Messdauer zu bestimmen
    • Werte in einer .csv-Datei speichern
    • Auslesevorgänge detailliert loggen
    • Automatisches checken der Einstellungen vor dem Start des Monitoring
    • Alle Funktionen lassen sich entweder über das eigens entwickelte Skript oder direkt in Python über den Modulimport aufrufen


    Um die Möglichkeiten des Skripts noch einmal zusammenzufassen:
    Es prüft die notwendigen Voraussetzungen für die Verwendung von 1-wire Sensoren wie den DS18B20. Es ermöglicht das einmalige auslesen der Sensoren genauso wie das abfragen der Temperaturwerte über einen gewünschten Zeitraum in einem gewünschtem Intervall. Die Messwerte können in einer csv-Datei gespeichert werden und die notwendigen Prozesse können in einer log-Datei erfasst werden.

    Das ganze Projekt wurde auf GitHub entwickelt und unterliegt der MIT-Lizenz. Zudem ist das Packet auf PyPi hochgeladen und kann somit bequem über pip installiert werden. Zu guter Letzt wurde eine Dokumentation geschrieben, die auch auf PyPi zugänglich ist. Hier werden die Funktionen erklärt und ein kurzes Beispiel zeigt den Umgang mit der Software.

    Links:


    Unsere aktuelle ToDo-Liste für die nächsten Wochen/Monate des Projektes sieht folgendermaßen aus:

    • Logging und .csv Export effizienter gestalten (andere Dateiformate bzw. Komprimierung)
    • Reporting Funktion in Form von zusätzlicher Ausgabedatei (Mittelwerte, Min, Max, Median, Standardabweichung über Zeitintervalle)
    • PDF Zusammenfassung mit Auswertung und grafischer Darstellung
    • Hardware Tutorial


    Und jetzt kommt die große Frage, was möchten wir von euch? Die Anwendung befindet sich momentan in der ersten Beta-Phase und bedarf daher einiger User die sich bereit erklären würden die Anwendung zu testen, um sie auf die Punkte Fehler, Bedienbarkeit, Funktionen etc. zu untersuchen.

    Unsere Bitte an die Community wäre daher uns Antworten zu folgenden Punkten zu geben:

    • Allgemeines Feedback / Kritik(!)
    • Gewünschte zusätzliche Funktionen
    • Änderungswünsche an bestehenden Funktionen
    • Feedback zur Verständlichkeit der Dokumentation
    • Kommentare zum Code (nur für diejenigen die Lust haben so tief einzusteigen oder sich herausgefordert fühlen)
    • Rückmeldung zu den geplanten ToDo’s
    • Wunsch nach anderer Hardwareunterstützung
    • Jegliche sonstige konstruktive Kritik


    Vielen Dank an euch alle und viele Grüße,
    Henrik und Aurofree

  • Hallo,

    nach Überfliegen der Doku zwei Fragen:

    * Warum ist `__stop_read()` keine öffentliche Methode? Wenn sie rein intern ist, bräuchte man sie nicht in der Endanwender-Doku erwähnen. Außerdem macht es ja IMHO schon Sinn, dass man `start_read()` auch explizit und "offiziell" wieder stoppen kann.
    * IMHO ist die Doku zur ds18b20-Klasse mißverständlich, weil der Satz "On creation of the object a logger is added. All outputs are managed by the internal logger." im Gegensatz zum Default-Wert `log=None` steht. Jedenfalls, so wie ich es verstehe :)

    Und bei der ds18b20-Klasse würde ich `console=` auf `False` setzen. Grund: im "normalen" Betrieb braucht man das denke ich nicht. Das ist "nur" beim Testen praktisch.

    Zu den To-Do's:

    Zitat

    Logging und .csv Export effizienter gestalten (andere Dateiformate bzw. Komprimierung)


    Was ist denn daran "ineffizient"? Komprimierte Log-Files und CSV-Dateien sind IMHO unüblich bzw. kommen wenn bei Archivieren von älteren Daten ("log rotate") zum Einsatz.

    Zitat

    PDF Zusammenfassung mit Auswertung und grafischer Darstellung


    Welches Modul habt ihr dafür im Auge? Reportlab?

    Gruß, noisefloor


    Gruß, noisefloor

  • noisefloor:

    Zitat

    * Warum ist `__stop_read()` keine öffentliche Methode? Wenn sie rein intern ist, bräuchte man sie nicht in der Endanwender-Doku erwähnen. Außerdem macht es ja IMHO schon Sinn, dass man `start_read()` auch explizit und "offiziell" wieder stoppen kann.

    Da ist wohl etwas beim Nachziehen der Doku falsch gelaufen. Funktion ist jetzt nicht mehr öffentlich, da sich das Tool entweder selber nach Ablauf der *duration* oder über Ctrl-C beenden lässt. Außerdem würde sich die Funktion *__stop_read()* nicht innerhalb eines Python Skriptes aufrufen lassen, da die Funktion *monitor* (alt=start_read()) das Skript blockiert.

    Zitat

    * IMHO ist die Doku zur ds18b20-Klasse mißverständlich, weil der Satz "On creation of the object a logger is added. All outputs are managed by the internal logger." im Gegensatz zum Default-Wert `log=None` steht. Jedenfalls, so wie ich es verstehe :)

    Dokumentation wurde jetzt verständlicher formuliert. Aber danke für den Hinweis.

    Zitat

    Und bei der ds18b20-Klasse würde ich `console=` auf `False` setzen. Grund: im "normalen" Betrieb braucht man das denke ich nicht. Das ist "nur" beim Testen praktisch.

    Fanden wir gut den Hinweis, ist übernommen. Jetzt sind alle Parameter auf *None* und können bei Bedarf aktiviert werden.

    Zitat

    Welches Modul habt ihr dafür im Auge? Reportlab?

    PDF ist ganz weit hinten auf der ToDo Liste, haben wir noch nicht genau recherchiert, aber Reportlab schauen wir uns mal an, danke.

    @all:

    Update auf Version 0.1.0.2b1:

    • Changed main function names and adapted expected parameters
    • Documentation updated
    • Log file format changed from .log to .txt
    • Updated csv export file structure
    • Moved csv handling to separated module
  • Hallo,

    IMHO ist `check()`ein komischer Name für eine Klasse bzw. ein Objekt. Das Wort "check" verbindet man wohl eher mit einer konkreten Aktion und nicht als Sammelbegriff.

    Und auch `c.w1_modules()` und `c.w1_config()` beschreiben IMHO nicht, was passiert. Nach meine Verständnis der Doku wird da was geprüft? Dann wären Methodennamen wie `w1_modules_loaded()` (mit Rückageb True oder False) und `w1_config_loaded()` oder w1_configured()` wohl besser.
    So oder so würde ich im Beispiel in der Einsteiger-Doku direkt noch den mögliche Rückgabewert mit zeigen.

    zu http://pythonhosted.org/eems/MODULE.html:
    * w1_modules() ist nicht dokumentiert, dafür w1_config 2x :)
    * Welchen Sinn hat `quiet=None` bei w1_config? Die Methode ist ein expliziter check, ob etwas geladen ist oder nicht, d.h man will doch `True` oder `False` zurück haben. Die Methode macht mit `quiet=True` IMHO null Sinn.

    Gruß, noisefloor

  • noisefloor: Vielen Dank für deine vielen Rückmeldungen. Hier unser Statement :).

    IMHO ist `check()`ein komischer Name für eine Klasse bzw. ein Objekt. Das Wort "check" verbindet man wohl eher mit einer konkreten Aktion und nicht als Sammelbegriff.

    Und auch `c.w1_modules()` und `c.w1_config()` beschreiben IMHO nicht, was passiert. Nach meine Verständnis der Doku wird da was geprüft? Dann wären Methodennamen wie `w1_modules_loaded()` (mit Rückageb True oder False) und `w1_config_loaded()` oder w1_configured()` wohl besser.

    Werden wir uns drüber Gedanken machen, danke für die Anregung.

    So oder so würde ich im Beispiel in der Einsteiger-Doku direkt noch den mögliche Rückgabewert mit zeigen.

    Wird im nächsten Patch hinzugefügt.

    zu http://pythonhosted.org/eems/MODULE.html:
    * w1_modules() ist nicht dokumentiert, dafür w1_config 2x :)

    Ups :D , Dokumentation wird im nächsten Patch aktualisiert, danke für den Hinweis.

    * Welchen Sinn hat `quiet=None` bei w1_config? Die Methode ist ein expliziter check, ob etwas geladen ist oder nicht, d.h man will doch `True` oder `False` zurück haben. Die Methode macht mit `quiet=True` IMHO null Sinn.

    Der Parameter quiet wird im nächsten Patch aus der öffentlichen Funktion entfernt. Der dient eigentlich nur zu internen Zwecken.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!