SmartHome.py

[2ndsky]

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?

[callidomus]

Hi Niko,

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

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

[2ndsky]

Hi Marcus,

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?

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?

[callidomus]

Hi Makki,

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

Bis bald

Marcus

[makki]

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

[callidomus]

Hi Niko,

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.

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.

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.

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.

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.

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.

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

[2ndsky]

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?

 65                 [B]smarthome.add_knot(sub_path, False)[/B]
 66                 sub_knot = Knot(smarthome, self, config[attr], sub_path)
 67                 vars(self)[attr] = sub_knot
 68                 [B]smarthome.add_knot(sub_path, sub_knot)[/B]

Weiter rufst du im Falle das "cache" gesetzt ist die _db_read Methode auf:

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

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

[2ndsky]

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?

[greentux]

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

[makki]

( ) 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..

[greentux]

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

[makki]

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

[panzaeron]

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

[makki]

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

[callidomus]

Aber sowas von ernst

Wenn das "ernst" und wirklich notwendig (?) ist, versuche ich mal nen Backport.

Danke für das Angebot.

Die Frage ist: ist Python >2.5 wirklich notwendig oder nur aus bequemlichkeit/versehen? (Weil man die Abwärtskompatibilität nicht geprüft hat oder so )

Ich habe damals auf einer aktuellen Maschine mit 2.6 das entwickeln angefangen. Ich konnte ja nicht ahnen das man es zwei Jahre später mit einer noch älteren Version laufen lassen will.
Es gibt einige Funktionen in 2.6 die das Leben deutlich einfacher machen bzw. den Code wesentlich schlanker werden lassen. Ich glaube ich habe momentan keine 2.7 Funktionen eingebaut, aber ich entwickle (immer noch) auf einer aktuellen Maschine mit 2.7.

Wie sieht eigentlich der Upgrade-Pfad vom Wiregate aus? Wie lange packt Ihr es noch mit der alten Distri? Stellt doch mal auf Ubuntu LTS um, dann kannst Du Dir das lästige Backporten von ausgefallenen/aktuellen Ports und Sicherheitspatches sparen und hast trotzdem eine Umgebung die von vielen anderen auch getestet/genutzt wird.
Oder ist das nur aus Bequemlichkeit weil man sich keine Gedanken zum OS-Upgrade gemacht hat )?

Bis bald

Marcus

P.S. ich habe jahrelang für einen Appliance-Hersteller gearbeitet, ich weis was eine OS-Upgrade bedeuten kann.