Ankündigung

Einklappen
Keine Ankündigung bisher.

SmartHome.py

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • callidomus
    hat ein Thema erstellt SmartHome.py

    SmartHome.py

    Hallo,

    ich habe soeben mein Steuerungsprojekt auf Sourceforge geladen.
    Es nennt sich SmartHome.py und basiert auf Python.
    Ich habe grossen Wert auf die einfache Programmierung der Logiken gelegt. Ein weiterer wichtiger Aspekt ist die einfache Erweiterbarkeit mit zusätzlichen Plugins.

    Es steht unter der GPLv3 und Copyright 2011 KNX-User-Forum e.V.

    Momentan gibt es vier Plugins (KNX, 1-Wire, UDP, Prowl) und weitere werden folgen. Als nächstes steht ein Visu-Plugin an.

    Ihr könnt es unter http://smarthome.sourceforge.net/ finden.

    Ich hoffe es nützt ein paar von euch. Bei Fragen oder Problemen könnt ihr euch gerne an mich wenden. Entweder per PN, diesem Thread oder im Sourceforge Bug-Tracking.

    Bis bald

    Marcus

    P.S. ja ich kennen das neue Wiregate-Framework. Ich habe schon vor 9 Monaten mit der Programmierung angefangen und bin von meinem Ansatz überzeugt.

  • 2ndsky
    antwortet
    Dann werde ich mir die Tage wohl Ubuntu in der Virtual Box aufziehen und ebenfalls vim verwenden (bin ich jetzt ja von der Arbeit gewohnt). Wie debuggst du?

    Einen Kommentar schreiben:


  • callidomus
    antwortet
    Hi Niko,
    Zitat von 2ndsky Beitrag anzeigen
    aber könnte man das nicht in einem Aufruf machen, Objekt zum Einhängen erstellen und die Subnodes einhängen?
    ja könnte man, ich wollte aber möglichst viel Node Logik in der lib/node.py haben.
    EDIT: den ersten Aufruf von add_node kann man sich wohl schenken...

    Zitat von 2ndsky Beitrag anzeigen
    Ich muss mir jetzt mal ne Entwicklungsumgebung für Python aufsetzen, damit ich das ganze bei Änderungen auch debuggen kann. Was nutzt du dafür? PythonEditors - PythonInfo Wiki gibt da ja einen guten Überblick. Ich brauche halt was für Mac, hätte jetzt Eclipse gesagt, was meinst du?
    Ich verwende folgende Entwicklungsumgebung: Mac - VirtualBox - Ubuntu 12.04 - Vim. Dadurch ist meine Entwicklungsumgebung nahezu identisch mit der Produktionsumgebung. An Deiner Stelle würde ich dann halt ein altes Debian nehmen.

    Bis bald

    Marcus

    Einen Kommentar schreiben:


  • 2ndsky
    antwortet
    Hi Marcus,

    Zitat von mknx Beitrag anzeigen
    damit die Subknoten (oder jetzt Subnodes) ein Objekt haben an das Sie sich hängen können.
    aber könnte man das nicht in einem Aufruf machen, Objekt zum Einhängen erstellen und die Subnodes einhängen?

    Zitat von mknx Beitrag anzeigen
    hmm, aus meiner Sicht lebt SH.py von den Nodes.
    Okay, habe bei erneutem drüber schauen gesehen, dass smarthome von nodes abgeleitet ist. Dann macht das ganze schon wieder mehr Sinn.

    Ich muss mir jetzt mal ne Entwicklungsumgebung für Python aufsetzen, damit ich das ganze bei Änderungen auch debuggen kann. Was nutzt du dafür? PythonEditors - PythonInfo Wiki gibt da ja einen guten Überblick. Ich brauche halt was für Mac, hätte jetzt Eclipse gesagt, was meinst du?

    Einen Kommentar schreiben:


  • callidomus
    antwortet
    Hi Makki,

    vielen Dank für das Angebot die SF-Infrastruktur unter Eurem Dach als Stiefkind zu nutzen.

    Bis bald

    Marcus

    Einen Kommentar schreiben:


  • makki
    antwortet
    Zitat von 2ndsky Beitrag anzeigen
    wir brauchen nur einen Platz, wo wir über sowas diskutieren können und natürlich eine Versionsverwaltung (evtl. kannst du mich auch bei SF mit aufnehmen - Username: wu-mc).
    Wenn Chris M nichts dagegen hat (was ich nicht glaube) ist dafür unter SF/openautomation Platz und Toleranz genug.. Ob das mein lieblingskind ist oder nicht, kann ich da durchaus zurückstellen

    Die Synergie von OSS ergibt sich primär aus Kooperation (ich schreibe DPT's von MH ab, fixe sie dort, ...), für Konkurrenz ist diese Nische (noch?) viel zu speziell..

    Makki

    Einen Kommentar schreiben:


  • callidomus
    antwortet
    Hi Niko,

    Zitat von 2ndsky Beitrag anzeigen
    Eine Anmerkung hätte ich z.B. schon, auch wenn es nur Schönheitskorrekturen sind. Die Klasse Knot würde ich unbedingt in Node umbenennen, da das einfach gebräuchlicher ist. Ich musste z.B. erstmal in die lib/Knot.py rein um zu sehen, was das sein soll
    Da ist was dran. Ich habe es bei mir geändert.

    Zitat von 2ndsky Beitrag anzeigen
    Gibts eigentlich das Beta Forum noch? Weil evtl. könnte die Diskussion hier in Richtungen abdriften, die den normalen User eher nicht interessieren. Wenn ja, könnte mir da jemand Rechte geben?
    Unsere Diskussion hat im Beta Forum (vom Wiregate) nichts zu suchen.
    Ich habe bei SF ein DevForum eröffnet, wo wir sowas diskutieren können.
    Weiterhin habe ich mal bei den Admins nachgefragt, ob wir hier ein Supportforum bekommen.

    Zitat von 2ndsky Beitrag anzeigen
    Vielleicht versteh ich noch nicht alle Besonderheiten von Python, aber warum rufst du in der Knot.py zweimal add_knot in der smarthome Klasse auf?
    damit die Subknoten (oder jetzt Subnodes) ein Objekt haben an das Sie sich hängen können.

    Zitat von 2ndsky Beitrag anzeigen
    Du übergibst hier den Typ, der Übergabeparameter wird aber in der Methode garnicht verwendet (du greifst immer auf self._type zu):
    Dieser 'Feature' ist bereinigt.

    Zitat von 2ndsky Beitrag anzeigen
    Da du ja nun Tools eingeführt hast, würde ich die fade Methode eher dort hin verschieben. Weil fade macht nur (zumindest sehe ich sonst noch keinen Anwendungsfall) bei Lampen sinn, es aber dann in einen Knoten einzubauen find ich falsch.
    ja, kannst Du gerne machen.

    Zitat von 2ndsky Beitrag anzeigen
    Des Weiteren finde ich die Verwaltung der Knoten in der Smarthome Klasse für den falschen Platz. Dadurch wird diese unnötig aufgebläht. Ich würde dort nur den root Knoten halten und beim Zugriff über den Pfad diesen anhand des Punktes splitten und dann jeweils über Zugriffsmethoden der Unterknoten den Baum hinabwandern. Dadurch sind die Klassen nicht so eng mit einander verbunden und man tut sich bei einem späteren Refactoring einfacher.
    hmm, aus meiner Sicht lebt SH.py von den Nodes.

    Zitat von 2ndsky Beitrag anzeigen
    Das sind jetzt mal ein paar Anregungen, die mir spontan aufgefallen sind. Wie bereits angeboten würde ich da gerne mitarbeiten, wir brauchen nur einen Platz, wo wir über sowas diskutieren können und natürlich eine Versionsverwaltung (evtl. kannst du mich auch bei SF mit aufnehmen - Username: wu-mc).
    Willkommen an Bord.

    Bis bald

    Marcus

    Einen Kommentar schreiben:


  • 2ndsky
    antwortet
    Vielleicht versteh ich noch nicht alle Besonderheiten von Python, aber warum rufst du in der Knot.py zweimal add_knot in der smarthome Klasse auf?

    Code:
     65                 smarthome.add_knot(sub_path, False)
     66                 sub_knot = Knot(smarthome, self, config[attr], sub_path)
     67                 vars(self)[attr] = sub_knot
     68                 smarthome.add_knot(sub_path, sub_knot)
    Weiter rufst du im Falle das "cache" gesetzt ist die _db_read Methode auf:

    Code:
    104         if self._cache:
    105             self._value = self._db_read(self._type)
    Du übergibst hier den Typ, der Übergabeparameter wird aber in der Methode garnicht verwendet (du greifst immer auf self._type zu):

    Code:
    222     def _db_read(self, typ=None):
    223         try:
    224             with open(self._sh._cache_dir + self._path, 'r') as f:
    225                 return cPickle.load(f)
    226         except IOError, e:
    227             logger.info("Could not read {0}{1}".format(self._sh._cache_dir, self._path))
    228             try:
    229                 return getattr(self, '_return_' + self._type)(0)
    230             except:
    231                 return False
    232         except EOFError, e:
    233             logger.info("{0}{1} is empty".format(self._sh._cache_dir, self._path))
    234             try:
    235                 return getattr(self, '_return_' + self._type)(0)
    236             except:
    237                 return False
    Da du ja nun Tools eingeführt hast, würde ich die fade Methode eher dort hin verschieben. Weil fade macht nur (zumindest sehe ich sonst noch keinen Anwendungsfall) bei Lampen sinn, es aber dann in einen Knoten einzubauen find ich falsch.

    Des Weiteren finde ich die Verwaltung der Knoten in der Smarthome Klasse für den falschen Platz. Dadurch wird diese unnötig aufgebläht. Ich würde dort nur den root Knoten halten und beim Zugriff über den Pfad diesen anhand des Punktes splitten und dann jeweils über Zugriffsmethoden der Unterknoten den Baum hinabwandern. Dadurch sind die Klassen nicht so eng mit einander verbunden und man tut sich bei einem späteren Refactoring einfacher.

    Das sind jetzt mal ein paar Anregungen, die mir spontan aufgefallen sind. Wie bereits angeboten würde ich da gerne mitarbeiten, wir brauchen nur einen Platz, wo wir über sowas diskutieren können und natürlich eine Versionsverwaltung (evtl. kannst du mich auch bei SF mit aufnehmen - Username: wu-mc).

    Einen Kommentar schreiben:


  • 2ndsky
    antwortet
    Hallo Marcus,

    danke für's Zusenden des Codes. Bin gerade noch am drüber schauen bevor ich das die nächsten Tage aufs Wiregate ziehe.

    Eine Anmerkung hätte ich z.B. schon, auch wenn es nur Schönheitskorrekturen sind. Die Klasse Knot würde ich unbedingt in Node umbenennen, da das einfach gebräuchlicher ist. Ich musste z.B. erstmal in die lib/Knot.py rein um zu sehen, was das sein soll
    Gibts eigentlich das Beta Forum noch? Weil evtl. könnte die Diskussion hier in Richtungen abdriften, die den normalen User eher nicht interessieren. Wenn ja, könnte mir da jemand Rechte geben?

    Einen Kommentar schreiben:


  • greentux
    antwortet
    Ja natürlich weiss ich es. Und es hat in der Tat auch seine Berechtigung. Daher sind dort aber auch nur die wirklich notwendigen Pakete drauf. Und selbst der Kernel besteht dann nur aus den Modulen, die wirklich gebraucht werden. Alles andere fehlt. Der Support ist dann überschaubarer.
    Wenn man aber das WG als offene Plattform verkauft, mit der man alles machen können soll, ists halt schwierig mit dem Spagat. Ich denke, das ist auch verständlich. Ohne das man das ankreuzen muss...

    Einen Kommentar schreiben:


  • makki
    antwortet
    ( ) Du weisst das auf den meisten SoHo-Routern und xDSL-Modems ein Linux 2.4 läuft?
    ( ) Nicht

    Makki

    Edit: Sorry für OT, aber es hat damit zu tun, insofern das SW auch benutzbar sein muss ohne sich mit Expertenwissen anzueignen - mein Credo: es geht auch ohne wenn man eben auf stabile Distributionen setzt..

    Einen Kommentar schreiben:


  • greentux
    antwortet
    "2 Jahre alte Plörre" klingt jetzt "gut".
    Da endete der Support vom Etch, welches 2007 das Licht der Welt erblickte.
    Die allermeisten Admins haben ihr RZ dann 2009 auf Lenny gezogen...
    Aber nun. Der Vorteil einer länger verfügbaren Hardwareplattform kommt hier voll zum tragen. Das passt schon.

    Die SW in der Firma muss auf der aktuellen + den 2 vergangenen Lenovo X/T Generationen laufen. Da ist man schnell bei einigen Komponenten ganz vorn im git dabei...

    Einen Kommentar schreiben:


  • makki
    antwortet
    Ich hätte natürlich zuerst 2.7 versucht (scheint bis auf ein paar glitches auch zu gehen..)

    Aber irgendwie erinnert mich die Diskussion gerade stark an
    Die Woche: Desktops und Birnen | heise open
    Dem Entwickler ists ja wurscht, ob das mit 2J alter "Plörre" geht, klassischer Fall von SEP
    Ich stehe mehr auf langzeit&stabil, aktuelles Debian-Stable ist 2.6.6, darüber ist für mich erstmal Pre-Alpha (allerdings egal, weil nichts auf dem WG auf Py basiert..)

    Makki

    Einen Kommentar schreiben:


  • panzaeron
    antwortet
    @Makki
    Ich denke sinnvoller wäre es die 2.7.3 zu backporten, wenn es die gäbe wäre es schon gut, momentan teste ich auf einem externen Rechner.

    @mknx
    Eine beliebig tiefe Hirachie ist ein echter Fortschritt, ein Splitten der Konfiguration bei der Visu würde ich mir auch wünschen. Bei linKNX geht das z.B. auch nicht, was ich als riesen Nachteil empfinde.

    Einen Kommentar schreiben:


  • makki
    antwortet
    Zitat von mknx Beitrag anzeigen
    Oder ist das nur aus Bequemlichkeit weil man sich keine Gedanken zum OS-Upgrade gemacht hat )?
    Eher schon, sonst hätt ich mir meine Distro selbstgestrickt und nicht Debian genommen, ne?

    Wir geben unseren Kunden nur sehr viel mehr Freiheiten als das üblich ist, das macht ein Dist-Upgrade jedoch ungleich schwieriger..
    Erschwerend kommt hinzu, das ohnehin 50% der relevanten SW selbstgebacken sind (eibd, linknx, wiregated, owfs, ...) weil upstream nicht oder nur sehr veraltet verfügbar.
    Solange kein zwingender Bedarf besteht - den ich nicht sehe - mache ich gerne Backports
    Schau mir das mit py2.6 nochmal an..

    Makki

    Einen Kommentar schreiben:

Lädt...
X