Posts by mobby

    Wenn du nur via VPN zugreifst brauchst du auch kein https. Sobald du aber auch ohne VPN auf den Server zugreifen kannst ist https unabdingbar. Am besten ein SSL/TLS Zertifikat bei Let's Encrypt holen. Würde auf jeden Fall nur mit Public Key Authentication über SSH auf den Server zugreifen. Hier sind noch einige Tipps wie man Server sicherer macht. Da ist auch ufw dabei, damit sprichst du iptables einfach an.

    Hey Jens,


    als Schnittstelle ist auf jeden Fall CalDAV, was co8 schon geschrieben hat, zu empfehlen. Sehr einfach und funktioniert super. Jetzt musst du nur noch einen Kalender finden, der das unterstützt. Hier mal ein JS Kalender, aber ob der CalDAV kann weiß ich nicht. Er hat zumindest die Google Kalender API, also könntest du vlt. mit CalDAV auf Google Kalender verlinken und dann einbinden. Egal wie, falls du was findest bin ich gespannt drauf.


    Alternativ könntest du auch direkt auf dein OwnCloud Kalender verweisen. Ich habe mein Rechte-Management z.B. so, dass ich extra User nur für meine CalDAV Dienste habe. Die können dann nur den Kalender anschauen und sonst nix.


    Gruß
    mobby

    Hey Leute, freue mich ja total, dass ihr meine Frage so ausgiebig erläutert, vor allem da sie vor 3 Jahren gestellt wurde [FACE WITH TEARS OF JOY].


    Sent from my SM-G925F using Tapatalk

    @meigrafd:


    Ich stimme dir vollkommen zu, dass es bei weitem bessere und schönere Wege gibt ein Python Program zu beenden. Mein Vorschlag war quick and dirty darauf ausgerichtet die Frage im Beispiel zu beantwerten.


    Quote

    Erstmal als KeyboardInterrupt...

    @Kornfeld:


    Das "try" und "except" muss um die "while" Schleife. In etwa so:


    Code
    1. try:
    2.    while True:
    3.        pass
    4. except KeyboardInterrupt:
    5.    print 'exit'

    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.

    Update auf Version 0.1.0.4b1:


    • Beginners Guide (Documentation)
    • Removed parameter check in object Temp()
    • Added console short commands -i and -d for interval and duration
    • Small bug fixes


    Update auf Version 0.1.0.3b1:


    • Add function to prepare system configurations for DS18B20 sensors
    • Bug fixes in eems console script

    noisefloor :


    Quote

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


    Quote

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


    Quote

    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.


    Quote

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

    Dann würde ich dir empfehlen dich grundlegend in Python einzuarbeiten. Davon hast du mehr, als dass wir dir einen fertigen Code liefern. Vorallem weil das was du brauchst zu den Basics gehört, die du sicher schnell lernst. Viel Erfolg!

    meigrafd : Hast recht mit dem get_ofen() am Anfang der Schleife, verpeilt. Aber sonst macht es das gleich wie meins, nur mit Variable anstatt Objekt. Ich würde das mittlere if weglassen und es mit else - pass abfangen, dann wäre es ganz korrekt.

    Ich habe mal auf dein Kommentar angepasst und gleich das Status-Objekt eingefügt. So vermeidest du jetzt die unnötigen Schaltzeiten und es sollte deine Anforderungen erfüllen. Anbei ist eine grafische Beschreibung fürs Verständnis. Hoffe es hilft.


    [code=php]#!/usr/bin/env python
    # -*- coding: utf-8 -*-



    from time import sleep



    class Status(object):
    def __init__(self, bol_status):
    self.status = bol_status


    def get_status(self):
    return self.status


    def set_status_on(self):
    self.status = True


    def set_status_off(self):
    self.status = False



    def get_ofen():
    # Hier kommt deine Temperatur her
    return 60


    # Grenzen
    top = 60
    bottom = 59


    # Status-Objekt setzen, heißt beim "Start" des Skripts ist Pumpe AUS (False)
    status = Status(False)


    while True:
    if get_ofen() > top and status.get_status() is False:
    print 'Pumpe an'
    # Über Objekt merken, dass Pumpe AN ist
    status.set_status_on()
    elif get_ofen() < bottom and status.get_status() is True:
    print 'Pumpe aus'
    # Über Objekt merken, dass Pumpe AUS ist
    status.set_status_off()
    sleep(1)



    [/php]