Smarthome.py auf dem Wiregate installieren

[mknx]

2.6 würde auch langen.

Bis Bald

Marcus

[dschwert]

Zitat von 2ndsky Da laut makki Python ohnehin nicht verwendet wird, würde ich Stand heute eher das vorhandene Python mit 2.7 überschreiben.

Das würde ich nicht empfehlen, da viele andere Pakete ihrerseits Python verwenden und spätestens dann Probleme bekommen, wenn sie dann eine in C geschriebene Erweiterung nutzen.

Ich würde eher eine Parallelinstallation mit make altinstall statt make install empfehlen.
Ansonsten, falls das Kind schon in den Brunnen gefallen ist und es Probleme gibt, müssen die Links python bzw. python2 wieder auf die 2.5er-Version zurückgebogen werden.
Beim Start von Smarthome.py muß bei der Parallelinstallation dann halt explizit python2.7 aufgerufen werden.


Gruß,

Dietmar

[StefanW]

Mit Installationen von Python auf dem WG (wie auf jedem Linux) das nicht dem aus der Distro entspricht, sollte man vorsichtig sein. Wie der Vorschreiber schon anmerkte, viele Pakete nutzen das und die Abhängigkeiten sind nicht trivial.

Umgekehrt, wenn ich so fragen darf, was ist in Python 2.6 enthalten das es nicht auch in Python 2.5 gibt? Wir hatten eine Diskussion mit einem Python-Programmierer zu dem Thema und der meinte, eigentlich kann man mit 2.5 auch alles erreichen was man möchte.

lg

Stefan

[2ndsky]

Zitat von StefanW Umgekehrt, wenn ich so fragen darf, was ist in Python 2.6 enthalten das es nicht auch in Python 2.5 gibt? Wir hatten eine Diskussion mit einem Python-Programmierer zu dem Thema und der meinte, eigentlich kann man mit 2.5 auch alles erreichen was man möchte.

Man kann auch mit C alles erreichen was man möchte... warum gibt es also Python?

Manchmal liegt es nicht mal daran, das man als Programmierer die neuen Features einer Version unbedingt benutzen will als viel mehr daran, dass man Abhängigkeiten zu anderen Bibliotheken hat, die eben auf einer Mindestversion basieren. Klar kann man diese Abhängigkeiten auflösen indem man die Umsetzung selber macht, oder etwas backportet... aber da steigt dann der Aufwand für Verwaltung für solchen Crap dermaßen, dass man als Hobbyentwickler mehr mit backporten beschäftigt ist, als sich um die eigentlichen Sachen zu kümmern.

[StefanW]

Hallo Niko,

so allgemein war mir das schon klar, ich habe auch schlecht gefragt.

Was benötigt smarthome.py in Python 2.6 was nicht auch in 2.5 enthalten ist.

lg

Stefan

[2ndsky]

Zitat von StefanW Was benötigt smarthome.py in Python 2.6 was nicht auch in 2.5 enthalten ist.

Hier mal eine Auszug aus der Doku von Python:

Some significant new packages have been added to the standard library, such as the multiprocessing and json modules

smarthome.py verwendet zumindest das json Modul ganz sicher, ob es weitere Features von 2.6 braucht vermag ich nicht mit Sicherheit zu sagen. Da kann Marcus sicher mehr dazu sagen.

[mknx]

Hi Stefan,

Zitat von StefanW Was benötigt smarthome.py in Python 2.6 was nicht auch in 2.5 enthalten ist.

es gibt viele kleine neue Funktionen/Keywords die das Leben deutlich einfacher machen.
Natürlich könnte man das auch alles mit Python 1.1 oder 2.5 machen. Es wird halt aufwändiger und z.T. langsamer. Nachträglich Code auf eine Uralte Pythonversion downzugraden erfordert erheblichen Aufwand.

Es gibt auch ein paar syntaktische Änderungen die eingeführt wurden und ab 3.0 verpflichtend sind. Es wird z.B. string.format() sehr häufig verwendet. was in 2.5 nicht vorhanden ist.

Was spricht gegen eine parallele Installation von Python 2.6?

Bis bald

Marcus

[2ndsky]

Hallo an alle,

hier mal ein kleines Update: mittlerweile läuft smarthome.py auf einem ESXi Server in einem virtualisierten Ubuntu 12.04 LTS. Der wäre zwar eigentlich etwas oversized dafür, aber da der eh läuft habe ich es da drauf gepackt.

Zuvor hatte ich einige Probleme bzgl. des Speicherbedarfs. Das WG hat "nur" 256MB Speicher und nach 127 Tagen Uptime wurden davon allein über 70% vom wiregated.pl verwendet. Dadurch hängte sich das WG nach etwa zwei bis drei Tagen auf und es half nur den lighttpd und smarthome.py neuzustarten. Testweise habe ich auch mal das Wiregate neugestartet, dann war der Speicherverbrauch vom wiregated wieder im normalen Bereich und sh.py samt lighty liefen über Wochen hinweg ohne Probleme. Ich hätte mich jetzt mühsig evtl. mit makki und Stefan auf die Fehlersuche machen können, aber dazu hatte ich keine Lust und da seit Weihnachten ohnehin der ESXi Server läuft war es die für mich besser Alternative, da auf das Ubuntu noch andere Smarthome relevante Sachen drauf kommen sollen (Asterisk etc.).

Wenn sh.py auf einer Hardware mit geringem Stromverbrauch laufen soll würde ich lieber mal das Raspberry Pi Projekt von Markus abwarten... ansonsten kann ich zum Dauereinsatz auf'm WG wegen der gemachten Erfahrung eher nicht raten oder nur, wenn man bereit ist, da auf die Fehlersuche zu gehen.

[mknx]

Hi Niko,

das die Wiregate-Software so instabil ist hätte ich nicht gedacht.

Bis bald

Marcus

P.S. Du solltest Deine Signatur anpassen um die Wiregate-Benutzer nicht in den glauben zu versetzen sie könnten die Software, neben der WG-Software, installieren und benutzen. Verweise doch in dem ersten Beitrag in diesem Thread auf Deinen letzten.

P.P.S. Vielleicht schreibe ich in meine Signatur: stabiler Speicherverbrauch since V0.1?

P.P.P.S meine beiden ROT für den Pi sind unterwegs :-)))

[2ndsky]

Kann auch sein, dass ich öfters ein Update der WG Software machen sollte, damit diese stabiler läuft. Es wird zwar immer damit geworben, dass man etliche Sachen noch auf dem WG laufen lassen könnte, das kann ich allerdings nicht wirklich bestätigen.

sh.py kann ja auch 1Wire Fühler direkt, oder? Würde es dann reichen, den Busmaster vom Wiregate an den Rechner auf dem sh.py läuft zu stecken? Oder wie werden 1Wire Sensoren in sh.py integriert?

Zitat von mknx P.S. Du solltest Deine Signatur anpassen um die Wiregate-Benutzer nicht in den glauben zu versetzen sie könnten die Software, neben der WG-Software, installieren und benutzen. Verweise doch in dem ersten Beitrag in diesem Thread auf Deinen letzten.

Guter Punkt, ist geändert.