SmartHome.py

[greentux]

Comet wäre toll.
Dazu wird aber ja auch schon eine Logik-Engine gebaut.

Ich finde den Ansatz zumindest interessant, erst die Engine und dann eine GUI zu bauen. Gleich einen Editor mitliefern zu wollen kostet einiges an Ressourcen.

@mknx: bist Du da allein am Start oder coded noch jemand mit?

[henfri]

Soweit verstanden?

Ja, danke

Momentan noch die CLI (Command Line Interface) per Telnet ;-).

;-))
Was sagt der WAF?

1. Sencha (HTML5/CSS UI-Framework das super aussieht) + Websocket Die Websocket-Anbindung an SmartHome.py habe ich im Labor fertig. Es fehlt aber noch die Sencha-Anbindung/Programmierung.
2. CometVisu Dort habe ich dies Zusammenhänge noch nicht so ganz geblickt bzw habe ich keine Ahnung wie man die Anbindung elegant bewerkstelligen könnte.
3. CommandFusion Dafür habe ich vor einem Jahr schon mal eine Schnittstelle gemacht, sollte sich ohne besonders viel Aufwand portieren lassen.

Comet wäre toll.
Dazu wird aber ja auch schon eine Logik-Engine gebaut.

Gruß,
Hendrik

[greentux]

pro cometVisu...
ich glaube, das würde passen.

[callidomus]

Schöne Idee!

Danke.

Uff.. Hier hast du mich verloren.
Kannst du das bitte erklären?

hmm, dazu müsste ich eh noch eine Anleitung schreiben bevor ich 0.3 veröffentliche. Ich versuch es noch mal kurz.

In meiner extensions.conf (von Asterisk) steht:

exten => _*XX,n,UserEvent(SCHLUESSELWORT,Source: QUELLE,Value: WERT)

In meiner logic.conf:

['AstAction']
    filename = 'astaction.py'
    ast_userevent = SCHLUESSELWORT

Jedes mal, wenn Asterisk diesen (User-)Event schickt, wird meine Logik (astaction.py) aufgerufen. In der Logik kann ich dann den 'trigger' abfragen.

print trigger['source'] # == QUELLE
print trigger['value'] # == WERT

Dadurch kann ich relativ einfach Befehle an meine Logik schicken.

Das hatte ich erst per UDP-Befehlen gemacht, da ich aber eh eine Schnittstelle zu der Asterisk-API hergestellt habe verwende ich diese.
Ist der direktere Weg und ich muss nicht mit Asterisk-System-Aufrufen zusätzliche Scripte starten.

Soweit verstanden?

Noch eine Frage:
Welche Visu nutzt du?

Momentan noch die CLI (Command Line Interface) per Telnet ;-). Es läuft bei mir aber auch erst im Labor. Eigentlich wollte ich schon die GUI entwickeln. Asterisk hat sich aber reingedrängt. Mal sehen was es wird. Es stehen zur Auswahl:

1. Sencha (HTML5/CSS UI-Framework das super aussieht) + Websocket Die Websocket-Anbindung an SmartHome.py habe ich im Labor fertig. Es fehlt aber noch die Sencha-Anbindung/Programmierung.
2. CometVisu Dort habe ich dies Zusammenhänge noch nicht so ganz geblickt bzw habe ich keine Ahnung wie man die Anbindung elegant bewerkstelligen könnte.
3. CommandFusion Dafür habe ich vor einem Jahr schon mal eine Schnittstelle gemacht, sollte sich ohne besonders viel Aufwand portieren lassen.

Bis bald

Marcus

[henfri]

zum einen monitored sie die einzelnen Asterisk-Channel. Damit kann ich z.B. einfach die Musik runterregeln wenn ich angerufen werde bzw. anrufe (nach Anruf wird sie wieder angehoben).

Schöne Idee!

Zum anderen kann man 'beliebige' Logiken triggern mit:

exten => _X.,n,UserEvent(Forbidden,Source: ${CALLERID(name)} (${CALLERID(num)}),Value: ${EXTEN})

Dieser Eintrag in der extensions.conf triggert jede Logik die auf 'Forbidden' hört und übergibt ihr als Source die CallerID und als Value die angerufene Nummer. Kann man natürlich beliebig erweitern.

Uff.. Hier hast du mich verloren.
Kannst du das bitte erklären?

Noch eine Frage:
Welche Visu nutzt du?

Gruß,
Hendrik

[callidomus]

Hi Hendrik,

was macht denn die Asterisk Erweiterung?

zum einen monitored sie die einzelnen Asterisk-Channel. Damit kann ich z.B. einfach die Musik runterregeln wenn ich angerufen werde bzw. anrufe (nach Anruf wird sie wieder angehoben).
Zum anderen kann man 'beliebige' Logiken triggern mit:

exten => _X.,n,UserEvent(Forbidden,Source: ${CALLERID(name)} (${CALLERID(num)}),Value: ${EXTEN})

Dieser Eintrag in der extensions.conf triggert jede Logik die auf 'Forbidden' hört und übergibt ihr als Source die CallerID und als Value die angerufene Nummer. Kann man natürlich beliebig erweitern. z.B. UserEvent(machdietuerauf,...
Ich verwende es z.B. für ein Telefonmenü mit:

exten => 1,1,UserEvent(Action,Source: ${CALLERID(name)}(${CALLERID(num)}),Value: LichtAn)
exten => 2,1,UserEvent(Action,Source: ${CALLERID(name)}(${CALLERID(num)}),Value: LichtAus)
....

In der Logic (die durch das Schlüsselwort 'Action' getriggert wird) frage ich dann z.B.

if trigger['value'] == 'LichtAus':
    sh.wohnzimmer.licht(0)

bis bald

Marcus

[henfri]

Hallo,

was macht denn die Asterisk Erweiterung?

Gruß,
Hendrik

[callidomus]

Hi Markus oder Matthias?,

wie ist denn smarthome.py im vergleich mit linknx einzuordnen?

ich habe mir linknx vor einem Jahr mal näher angeschaut...

- Linknx ist wahrscheinlich schneller bzw. Ressourcenfreundlicher
- Damals gab es eine Limitierung der Variablen auf max 14 ASCII, damit waren URLs oder ähnliches nicht dynamisch abzuspeichern (was ich benötigt hätte).
- Linknx ist aus meiner Sicht eher starr und sehr auf KNX fokussiert. SmartHome.py ist sehr flexibel und lässt sich beliebig und aus meiner Sicht einfach erweitern. KNX, 1-Wire, DMX, Asterisk (gerade im Test), ...
- SmartHome.py wird (aktiv) weiterentwickelt.
- Python ist mächtiger als Lua bzw. einfacher über Module zu erweitern

Man kann es ingesamt eher mit Misterhouse vergleichen. Misterhouse sah für mich aber nach Perl-Gefrikel aus. Und Perl ist nicht so meines.

Das nächste SmartHome.py Release wird die erwähnt Asterisk-Anbindung und die Umstellung der Thread-Architektur bringen. Bisher hat jede Logik einen eigenen Thread bekommen, das wird in Zukunft von ein paar Worker-Threads erledigt. Weiterhin kann man 'faden' also einen Wert schrittweise erhöhen oder reduzieren um sanfte Übergänge zu realisieren.

Alles klar? Oder hast du noch weitere Fragen?

Bis bald

Marcus

[greentux]

Hi Marcus,

wie ist denn smarthome.py im vergleich mit linknx einzuordnen? ich bin einer von denen, der schon noch mal ne xml datei schreiben kann bzw. auch python "lesen" kann
derzeit betreibe ich die comet visu (per xml config) auf dem WG und nutze ein paar Plugins. Nun steht an, entweder linknx als Logicengine zu nutzen oder aber "was anderes".

grüße

[callidomus]

Version 0.2

Hallo,

es gibt ein kleines Update mit ein paar Verbesserungen:
- Threshold: Schwellwertschalter für Items, damit die Logiken nur bei überschreiten der Schwellwerte getriggert werden.
- Offset: man kann einem Item einen Offset zuweisen. Damit lassen sich einfache Abweichungen oder Umrechnungen erledigen.
- DMX Plugin: naja DMX halt
- CLI Plugin: ein kleines Plugin das einen Telnet-Zugang zu SmartHome.py bietet um Werte auszulesen und optional zu setzen

Bzgl. KNX verstehe ich das Problem eigentlich nicht: Man verwendet tunlichst für setzen (Taster, Visu-Bedienung, Logik,..->Aktor) und Rückmeldung (Aktor-> Visu-Anzeige, aktualisierung von Stati [hörende GA]) einfach unterschiedliche GA's.
Wenn ein Anwender diese beiden zusammenlegt, wird er bei allen KNX-Geräten dasselbe Aha-Erlebniss lernen müssen o

Das habe ich mir zu Herzen genommen und abgeändert.

Mehr Informationen und der Download findet sich wieder unter:

SmartHome.py - Homepage

Viel Spaß am Gerät

Marcus

[makki]

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.

Bzgl. KNX verstehe ich das Problem eigentlich nicht: Man verwendet tunlichst für setzen (Taster, Visu-Bedienung, Logik,..->Aktor) und Rückmeldung (Aktor-> Visu-Anzeige, aktualisierung von Stati [hörende GA]) einfach unterschiedliche GA's.
Wenn ein Anwender diese beiden zusammenlegt, wird er bei allen KNX-Geräten dasselbe Aha-Erlebniss lernen müssen

Deswegen ist ja erstmal nichts "doppelt", der eibd refektiert nur - IMHO völlig richtig so* - alle Telegramme auf alle clients.
*Man stelle sich eine Multithreaded-Anwendung vor, hier schreibt die Visu oder Zeitschaltuhr, auf die eine Logik o.ä. in einem anderen Thread (auch) reagieren soll..

Makki

P.S.: Nein, die PL-Plugins sind keine Logikengine

[Chris M.]

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.

Dort habe ich schon mal ein Konzept für einen Web basierten GLE aufgesetzt - dem, wenn man's genau nimmt, eigentlich völlig egal ist, welche Engine dahinter steckt...
Evtl. ist das ja für Dich interessant. Code ist im SVN. Aber, wie gesagt, noch auf Konzept-Level.

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 hab auch keinen HS.
Was ich aber kenne ist Matlab/Simulink und ähnliche grafische Programmiersprachen. Und deren professioneller Einsatz um durchaus auch sicherheitskritische Software zu erzeugen. Da dort Simulink (bzw. ggf. TargetLink) durch einen Auto-Coder erst zu C gewandelt wird und dieses C durchaus mit per Hand geschriebenem C zusammen verwendet wird, kann ich, glaub ich, ganz gut den Unterschied zwischen grafisch und textueller Programmierung (zumindest im Kontext von Steuergeräten) vergleichen. Der Unterschied in der Verständlichkeit kann dramatisch sein (das gilt anders herum genau so - aber im Bereich der Regelungstechnik ist Signalflussbasiert typischer Weise besser)

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 ist der Unterschied zwischen einer Lösung für Bastler und einem für kommerzielle Zwecke geeignetem Tool. Aber, da Du das ja in erster Linie für Dich machst so wie für andere interessierte, habe ich Verständnis, wenn Dir ersteres reicht.

Das sieht man auch im Wiregate-Forum wenn dort Leute, die eigentlich keine Ahnung von Programmierung haben, selber Plugins schreiben/anpassen.

Wenn man ehrlich ist, sind die Plugins eine Notlösung. Wenn's nur bisschen komplexer werden soll, und z.B. ein Delay rein soll, wird's sehr aufwändig und ist für "Copy&Paste-Programmierer" nicht mehr geeignet. (Und mir ist's ehrlich gesagt zu blöd, daher beschäftige ich mich lieber mit der Weiterentwicklung als dass ich ein paar für mich sinnvolle Plugins schreibe...)

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.

Das sehe ich auch so. Nur ist der GLE nicht Bestandteil der GUI sondern der Logik-Engine. Das hängt damit zusammen das man ja eine grafische Syntax hat und nicht nur eine GUI zum Parameter-Verstellen (wie das "Programmieren" in der ETS, was, wenn man's genau nimmt, ja nur ein Applizieren ist)

Das alles unter einen Hut zu bringen und komfortabel bedienbar zu machen ist dann der Job für den Hersteller der Appliance. (Das ist auch der Grund warum ich keinen Editor für die CometVisu geschrieben habe. Aber bevor ElaboratedNetworks da was machen konnte hatte Netzkind den schon geschrieben... )

[callidomus]

Hi Makki,

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

[callidomus]

Hi Chris,

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.

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]

Hi Hendrik,

danke erst einmal.

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