Ankündigung

**SebastianFey** · 09.04.2011, 17:30

kannst du evtl noch ein paar sätze dazu schreiben?
was tut es?

**callidomus** · 09.04.2011, 18:51

Zitat von SebastianFey Beitrag anzeigen

was tut es?

Zuerst ist ein zentraler Speicherplatz für 'Items'. Diese Items werden in einem Baum organisiert.

Code:

wohnzimmer
    - licht
    - temperatur
    - fenster

Jedem dieser Items kann man Attribute zuweisen. Mit Hilfe der Plugins können diverse Schnittstellen (KNX, UDP, 1-Wire, ....) eingebunden werden. Dadurch kann man sehr einfach Brücken zwischen den Schnittstellen schlagen.

Folgende Config liest z.B. die Temperatur von einem 1-Wire Sensor und überträgt sie an die KNX GA 1/1/2.

Code:

[wohnzimmer]
    [[temperatur]]
        type = num
        knx_dpt = 9
        knx_ga = 1/1/2
        ow_id = 28.BBBBB20000 # see 1-Wire plugin
        ow_sensor = temperature # see 1-Wire plugin

Neben dieser Gateway-Funktion kann man sich relativ einfach mächtige Logiken bauen, ohne sich um die Details im Hintergrund zu kümmern.

Code:

if sh.wohnzimmer.fenster() == 'offen':
    sh.wohnzimmer.heizung(aus)

Ich habe auch sehr viel auf der Homepage dokumentiert.
Soweit alles klar?

Bis bald

Marcus

**henfri** · 10.04.2011, 00:00

Hallo,

sehr interessant. Danke dafür!

Ich kann es sicherlich nicht gut genug einschätzen. Aber ich sehe SmartHome.py als gute Ergänzung zur Comet Visu. (von dir als "Wiregate-Framework" bezeichnet (?)). Diese kann nämlich all das, was SmartHome.py kann nicht (und hat auch nach meinem Verständnis diese Ambition auch garnicht), während sie einen wesentlichen Punkt, der dir noch fehlt bereitstellt:

Roadmap

Visu: HTTP

Es wäre also zu überlegen, ob du diesen Punkt nicht überspringst und beim nächsten weitermachst.

Die Kombination aus SmartHome.py und CometVisu klingt für mich jedenfalls sehr attraktiv!

Nochmal danke für deine Arbeit und das Veröffentlichen.

Gruß,
Hendrik

**Chris M.** · 10.04.2011, 12:30

Zitat von henfri Beitrag anzeigen

Ich kann es sicherlich nicht gut genug einschätzen. Aber ich sehe SmartHome.py als gute Ergänzung zur Comet Visu. (von dir als "Wiregate-Framework" bezeichnet (?)).

Das "WireGate Framework" ist vermutlich SourceForge.net: LogicEngine - Open Automation

Zitat von henfri Beitrag anzeigen

Diese kann nämlich all das, was SmartHome.py kann nicht (und hat auch nach meinem Verständnis diese Ambition auch garnicht)

Richtig, die CometVisu ist eine reine Visualisierung und hat damit nichts mit einer Logik-Engine gemeinsam - und wird auch nie eine Logik-Engine enthalten. Sie kann aber leicht mit den verschiedensten Logik-Engines gemeinsam genutzt werden.

Was mir am SmartHome.py fehlt (und auch am o.g. "WireGate Framework"), ist jedoch der grafische Logik-Editor. Denn nur bei der Signalfluss basierten (bzw. hier wohl eher Eventfluss) Modellierung sehe ich ein Potential für breitere Anwendung.
Der ganze Rest ist für mich nur eine erweiterte Bibliothek zu einer Progammiersprache der persönlichen Präferenz und damit auf Leute beschränkt, die programmieren können. Das grafische ist zwar auch programmieren, aber die Einstiegshürde ist geringer, für Gelegenheitsanwender ist's besser und für Profis (die auch programmieren können) oftmals übersichtlicher.

**makki** · 10.04.2011, 17:05

Ohne sonstige Ausschweife, ein Hinweis: das ignorieren von Telegrammen vom (lokalen) eibd anhand der PA 0.0.0/1 halte ich für ziemlich bedenklich:
Diese könnten auch von anderen Anwendungen auf derselben Maschine, ETS, EibPC, Dreambox (oder sonstwas, das via KNXnet/IP darüber zugreift) oder gar einem zweiten eibd via TP kommen und trotzdem etwas bewirken wollen

Makki

**callidomus** · 10.04.2011, 19:20

Hi Hendrik,

danke erst einmal.

Zitat von henfri Beitrag anzeigen

Es wäre also zu überlegen, ob du diesen Punkt nicht überspringst und beim nächsten weitermachst.

Ganz so einfach ist es leider nicht. Man/ich braucht auf jeden Fall eine Verbindung zwischen Visu und SmartHome.py. Das ist im Endeffekt ein Comet-fähiges (S)CGI/Server. Welche Visu dann mit SmartHome.py spricht ist wahrscheinlich relativ egal. Hauptsache man kann halt long polling damit realisieren.
Ich möchte auch keine eigene Visu-Engine entwickeln (JavaScript). Evtl. kann ich die von ChrisM nehmen oder die von sencha (Sencha - Sencha Touch Overview - Mobile Web App Development for Android & iPhone | Sencha Touch | Products | Sencha).
Mal sehen Schritt für Schritt.

Ach ja das Wiregate-Framework (nicht Comet Visu) kann schon ein bisschen mehr als du vermutest, die können auch Werte umsetzen und wahrscheinlich noch mehr. Ich bin aber nicht so richtig durch den Code gestiegen.

Bis bald

Marcus

**callidomus** · 10.04.2011, 19:44

Hi Chris,

Zitat von Chris M. Beitrag anzeigen

Was mir am SmartHome.py fehlt (und auch am o.g. "WireGate Framework"), ist jedoch der grafische Logik-Editor. Denn nur bei der Signalfluss basierten (bzw. hier wohl eher Eventfluss) Modellierung sehe ich ein Potential für breitere Anwendung.

da gebe ich dir Recht, nur ohne stabile Basis von Null auf hundert ist halt ein bisschen viel (für mich). Naja, mal sehen was die Zeit so bringt. Ich bin echt gespannt wie sich euer Projekt weiter entwickelt.

Zitat von Chris M. Beitrag anzeigen

Das grafische ist zwar auch programmieren, aber die Einstiegshürde ist geringer, für Gelegenheitsanwender ist's besser und für Profis (die auch programmieren können) oftmals übersichtlicher.

hmm, mag vllt daran liegen das ich keinen HS habe, aber was ich da an Logiken gesehen habe fand ich nicht besonders übersichtlich und einfach zu verstehen.

Ich sehe eher die Installationshürden. Wenn jemand ein lauffähiges Setup (linux, eibd, owserver ...) realisiert, dann wird er auch das bisschen Python sprechen lernen bzw. die Logiken anpassen können. Das sieht man auch im Wiregate-Forum wenn dort Leute, die eigentlich keine Ahnung von Programmierung haben, selber Plugins schreiben/anpassen.

Daher finde ich eine Appliance für diese Zielgruppe der Mausschubser ;-) besser.
Ich sehe es auch als den eigentlichen Mehrwert den die Hersteller dieser Appliances bringen sollten, das die Enduser eine saubere GUI bekommen.

Bis bald

Marcus

**callidomus** · 10.04.2011, 19:51

Hi Makki,

Zitat von makki Beitrag anzeigen

Ohne sonstige Ausschweife, ein Hinweis: das ignorieren von Telegrammen vom (lokalen) eibd anhand der PA 0.0.0/1 halte ich für ziemlich bedenklich

danke für den Hinweis, das sehe ich auch so. Deswegen habe ich es dieses Verhalten auch in der Doku beschrieben. Ich sehe es aber auch als bedenklich an, wenn man Pakete dupliziert was bei euch anscheinend auch vorkommen kann. Da, bin ich mir aber nicht sicher.

Wenn ich z.B. eine 'dimme um 10%' reinbekommen und dann dann zweimal einen Dimm-Befehl an KNX übergebe. Verstehst du was ich meine, oder wo mein (und euer?) Problem liegt.

Bis bald

Marcus

**Chris M.** · 10.04.2011, 20:21