SmartHome.py

[2ndsky]

noch ne allgemeine Frage: in der smarthome.conf muss ich quasi für jede GA einen separaten Eintrag erstellen, sehe ich das richtig? Also z.B. bei Lampen die dimmbar sind brauche ich einen für schalten und einen für dimmen. Ebenso bei Jalousien einen für AUF/AB, einen für Position Behang und einen für Position Lamelle. Wird das nicht schnell etwas unübersichtlich?

Kannst du mal ne config von dir posten?

[callidomus]

Hi,

Ich bin gerade auf der Baustelle, heute Abend kann ich ausführlicher antworten und eine Konfiguration posten.

Mit 0.7 kann man beliebige (tiefe) Hierarchien bauen und nicht mehr nur zwei Ebenen. Weiterhin wird auch eine einfache Visu automatisch erzeugt.

Bis dann

Marcus

[2ndsky]

Mit 0.7 kann man beliebige (tiefe) Hierarchien bauen und nicht mehr nur zwei Ebenen. Weiterhin wird auch eine einfache Visu automatisch erzeugt.

Und das sagst du mir jetzt... hab gerade angefangen das für beliebig tiefe Hierarchien umzuschreiben

Weißt du schon, wann du die 0.7 releasen willst?
Besteht Interesse an einer Zusammenarbeit oder willst du das alleine pflegen?

[callidomus]

Wer viel fragt bekommt viele Antworten ;-)

Hi Niko,

jetzt aber richtig.

Habe Smarthome.py heute mal im Büro getestet und war recht angetan. Nun wollte ich es auf'm Wiregate installieren, was aber nicht ganz einfach ist. Da dort standardmäßig Python2.5 installiert ist und ein einfaches Update auf 2.6 nicht möglich, da nicht im Repo, hab ich 2.6 aus den sourcen parallel installiert.

Freut mich! Es scheint Dir ja echt gefallen zu haben wenn Du das auf Dich nimmst.
An Nachahmer: Ich würde generell gleich den Schritt zu 2.7 empfehlen. Momentan ist zwar 2.6 ausreichend aber das ist auch schon angezählt. Bei Ubuntu 12.10 wird 3.0 als default installiert.

noch ne allgemeine Frage: in der smarthome.conf muss ich quasi für jede GA einen separaten Eintrag erstellen, sehe ich das richtig? Also z.B. bei Lampen die dimmbar sind brauche ich einen für schalten und einen für dimmen. Ebenso bei Jalousien einen für AUF/AB, einen für Position Behang und einen für Position Lamelle. Wird das nicht schnell etwas unübersichtlich?

Das verstehe ich nicht ganz. Man kann viele GAs pro Item für unterschiedliche Aufgaben angeben (Init, Listen, Send, Reply..). Wenn aber man unterschiedliche Funktionen steuern möchte braucht man unterschiedliche Items.

Kannst du mal ne config von dir posten?

Anbei eine Config (0.7) von meiner Entwicklungsmaschine. Die Visu dazu packe ich in den Anhang.

lat = 49.48
lon = 9.59
elev = 177
tz = 'Europe/Berlin'


[dg]
    name = Dachgeschoss
    [[buero]]
        name = Büro
        [[[temp]]]
            type = num
            name = Temperatur
            cache = yes
            visu = div
        [[[hum]]]
            name = Luftfeuchtigkeit
            type = num
            cache = yes
        [[[dew]]]
            name = Taupunkt
            type = num
            eval_trigger = dg.buero.temp, dg.buero.hum
            eval = "sh.tools.dewpoint(sh.dg.buero.temp(), sh.dg.buero.hum())"
            visu = div
        [[[motion]]]
            name = Bewegung
            type = bool
            visu = toggle

[og]
    name = Obergeschoss
    [[schlafzimmer]]
        name = Schlafzimmer
        [[[temperature]]]
            name = Temperatur
            type = num
            visu = slider
    [[ankleide]]
        name = Ankleide
    [[kinderbad]]
        name = Kinderbad
    [[elternbad]]
        name = Elternbad
    [[kind1]]
        name = Kind 1
    [[kind2]]
        name = Kind 2
    [[flur]]
        name = Flur

[eg]
    name = Erdgeschoss
    [[wohnzimmer]]
        name = Wohnzimmer
        [[[temperature]]]
            name = Temperatur
            type = num
            visu = slider
    [[kueche]]
        name = Küche
    [[vorrat]]
        name = Vorratsraum
    [[abstell]]
        name = Abstellraum
    [[essen]]
        name = Essen
    [[eingang]]
        name = Eingang
    [[garderobe]]
        name = Garderobe
    [[wc]]
        name = WC
    [[flur]]
        name = Flur

[kg]
    name = Keller
    [[hauswirtschaft]]
        name = Hauswirtschaft
    [[technik]]
        name = Technik
    [[werkstatt]]
        name = Werkstatt
        [[[temperature]]]
            name = Temperatur
            type = num
            visu = slider

[aussen]
    name = Außenbereich
    [[garage]]
        name = Garage
    [[terasse]]
        name = Terasse
    [[wetter]]
        name = Wetter
        [[[temperature]]]
            name = Temperatur
            type = num
            visu = slider
        [[[strahlung]]]
            name = Strahlung
            type = num
            visu = slider

[haus]
    [[bewohnt]]
        type = bool
        eval = or
        eval_trigger = marcus.anwesend, frau.anwesend

[marcus]
    name = Marcus
    [[anwesend]]
        type = bool
        visu = toggle
    [[urlaub]]
        type = bool

[frau]
    [[anwesend]]
        type = bool

[autovisu]
    name = Visu Elemente
    [[text]]
        value = default text
        type = str
        visu = text
    [[textarea]]
        value = default text area
        type = str
        visu = textarea
    [[toggle]]
        value = True
        type = bool
        visu = toggle
    [[slider]]
        value = 40
        type = num
        visu = slider
    [[select]]
        value = 1
        type = str
        visu = select
        visu_opt = 1, 2, 3
    [[radio]]
        value = 3
        type = str
        visu = radio
        visu_opt = 1, 2, 3
    [[checkbox]]
        value = False
        type = bool
        visu = checkbox
    [[div]]
        value = default div
        type = str
        visu = div
    [[span]]
        value = default span
        type = str
        visu = span
    [[img]]
        value = /img/weather/30.png
        type = str
        visu = img
    [[dynamic_img]]
        value = True
        type = bool
        visu = img
        visu_img = /img/off.png, /img/on.png
    [[push]]
        value = True
        type = bool
        visu = push
        visu_img = /img/on.png, /img/on.png
    [[switch]]
        value = True
        type = bool
        visu = switch
        visu_img = /img/off.png, /img/on.png

Und ein KNX-Teil meiner Produktiv-Installation:

[led]
    type = bool
    knx_dpt = 1
    knx_listen = 1/1/4
    knx_send = 1/1/3
    knx_init = 1/1/4

Verständlich?

Weißt du schon, wann du die 0.7 releasen willst?

Es ist 'eigentlich' fertig. Ich muss aber noch testen und Dokumentation erstellen. Da ich momentan ein Haus renoviere komm ich aktuell leider nicht so schnell voran. Ich würde mal 1-2 Monate schätzen.

Besteht Interesse an einer Zusammenarbeit oder willst du das alleine pflegen?

Klar, Ich würde mich über eine Zusammenarbeit sehr freuen.
Es gibt auch noch einen anderen Entwickler der gerade angefangen hat sich in SH.py einzuarbeiten und sein erstes Plugin geschrieben hat.
Ich wollte eh mal ein SVN für den Code einrichten. Es würde sich anbieten das mit dem 0.7 Release zu kombinieren bzw. zum Beta-Test.

Bis bald

Marcus

[makki]

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

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 )

Makki

[2ndsky]

Hi Marcus,

Freut mich! Es scheint Dir ja echt gefallen zu haben wenn Du das auf Dich nimmst.

Habe dir ja am Münchner Stammtisch bei makki erzählt, dass ich noch nicht genau weiß wie ich Logiken realisieren soll. Nachdem ich jetzt beruflich ab und an mit Python zu tun habe ist das wesentlich interessanter für mich als Perl. Python ist für mich einfach schlüssiger. Hab mir dann deinen Code angesehen und gefallen daran gefunden

An Nachahmer: Ich würde generell gleich den Schritt zu 2.7 empfehlen. Momentan ist zwar 2.6 ausreichend aber das ist auch schon angezählt. Bei Ubuntu 12.10 wird 3.0 als default installiert.

Uff, ich dachte halt, weil auf der HP steht, dass es mit 2.6 getestet ist nehme ich auch einfach 2.6. Aber jetzt weiß ich ja wie es geht, da sollte auch 2.7 kein Problem mehr sein

Das verstehe ich nicht ganz. Man kann viele GAs pro Item für unterschiedliche Aufgaben angeben (Init, Listen, Send, Reply..). Wenn aber man unterschiedliche Funktionen steuern möchte braucht man unterschiedliche Items.

Das habe ich schon verstanden, je Item gebe ich den Typ an und über welche GAs der Wert geschrieben/gelesen etc. wird. Bei einer zweistufigen Hierarchie wie sie in 0.6 noch war, müsste man für eine Jalousie vier Items auf selber Ebene erstellen, also so:

['wohnen']
    [['jalousie_langzeit']]
        type = bool
        ...
    [['jalousie_kurzzeit']]
        type = bool
        ....
    [['jalousie_position']]
        type = num
        ...
    [['jalousie_lamelle']]
        type = num
        ...

Schöner wäre (was mit der mehrstufigen Hierarchie möglich sein sollte):

['wohnen']
    [['jalousie']]
        [[['langzeit']]]
            type = bool
            ...
        [[['kurzzeit']]]
            type = bool
            ...
        [[['position']]]
            type = num
            ...
        [[['lamelle']]]
            type = num
            ...

Damit ändert sich der Zugriff von sh.wohnen.jalousie_position() auf sh.wohnen.jalousie.position() was in meinen Augen besser ist. Auch Stockwerke (wie du sie ja in deiner neuen Konfig schon verwendest) sind natürlich sinnvoll für die Struktur.

Eine andere Möglichkeit wäre, dass man mit abgeleiteten Items arbeitet. Also es gibt die "primitiven" Items, bei denen der Typ angegeben wird wie bisher und zusätzlich gibt es spezielle Items wie z.B. Jalousie und dimmbare Lampen. Denn eine Jalousie hat immer Langzeit-, Kurzzeit-, Position- und Lamellen-GAs. Vorteil hier wäre, man könnte für die Visu gleich Widgets anhand des Typs angeben die dann eben in einem Widget das Dimmen und An/Aus Schalten erlauben.

Wegen der Unübersichtlichkeit: die Konfiguration ist zwar recht einfach, aber wird doch recht schnell ziemlich lang. Besser wäre, wenn man die Konfigurationsdatei auf mehrere aufteilen könnte (z.B. stockwerksweise), die man in der Hauptdatei lädt, ähnlich wie bei den Logiken.

Es ist 'eigentlich' fertig. Ich muss aber noch testen und Dokumentation erstellen. Da ich momentan ein Haus renoviere komm ich aktuell leider nicht so schnell voran. Ich würde mal 1-2 Monate schätzen.

Klar, Ich würde mich über eine Zusammenarbeit sehr freuen.
Es gibt auch noch einen anderen Entwickler der gerade angefangen hat sich in SH.py einzuarbeiten und sein erstes Plugin geschrieben hat.
Ich wollte eh mal ein SVN für den Code einrichten. Es würde sich anbieten das mit dem 0.7 Release zu kombinieren bzw. zum Beta-Test.

Eigentlich hast du ja bei SF schon ein Git Repo, nur leider liegt der Code da nicht drin bzw. wenn ich es auschecke bekomm ich einen leeren Ordner. Weil wenn die 0.7 eigentlich fertig ist wäre es doch praktisch, wenn ich mir das gleich ansehe und bei mir teste. Weil ich fange jetzt natürlich nicht an, meine ganze Konfig zweistufig hinzufrickeln um dann auf mehrstufig umzustellen.

Wenn dir das SVN Einrichten jetzt zu stressig ist, könntest du mir den jetzigen Code vielleicht schnell per Email schicken, dann kann ich wenigstens auf nem aktuellen Stand weiter machen und diffen kann ich es dann immer noch wenn du das Repo dann hast.

Als Plugin würd ich als erstes was für'n ekey schreiben. Das habe ich bisher auch in Perl und erkennt genau einen meiner Finger. Aber bevor ich das in Perl zusammen frickel damit auch meine Freundin mal keyless eintreten kann, mach ich das lieber in Python wo ich weiß was ich tue (es geht ja auch immerhin um die Eingangstür)

Beste Grüße
Niko

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

[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

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

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

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

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

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

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

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